From nobody Thu Jan 1 02:24:10 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608D31A039B; Thu, 1 Jan 2015 02:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OItj_4m-YyAe; Thu, 1 Jan 2015 02:20:54 -0800 (PST) Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id C75AB1A0383; Thu, 1 Jan 2015 02:20:53 -0800 (PST) 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 1Y6cs7-00023l-mq; Thu, 01 Jan 2015 10:20:51 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Y6cs6-0001xi-G6; Thu, 01 Jan 2015 10:20:51 +0000 Message-ID: <54A51F93.2060000@ninebynine.org> Date: Thu, 01 Jan 2015 10:21:07 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: dcrocker@bbiw.net, Stian Soiland-Reyes References: <54A41D6C.9010501@ninebynine.org> <54A45FBD.1070701@dcrocker.net> In-Reply-To: <54A45FBD.1070701@dcrocker.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/d4ixoGrq-_z7rRAfZUrrFSv3msk Cc: arcmedia@ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] Proposed charter for arcmedia X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 10:20:57 -0000 On 31/12/2014 20:42, Dave Crocker wrote: > Archive formats are used to aggregate multiple files and other data > into a single object, often with data compression and/or confidentiality > protection (encryption). This may be enough to address the point in an email I just sent (about scope re "archive" vs "multiple-file" format)? #g -- From nobody Thu Jan 1 04:42:44 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2421A1B64 for ; Thu, 1 Jan 2015 04:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.828 X-Spam-Level: X-Spam-Status: No, score=0.828 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FRT_ADOBE2=2.455, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqJc_wpZgYnK for ; Thu, 1 Jan 2015 04:42:39 -0800 (PST) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823F21A1B60 for ; Thu, 1 Jan 2015 04:42:39 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id v10so8878698qac.11 for ; Thu, 01 Jan 2015 04:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=WtZazc5Dw+dH6B6ame4YysuNKauf7ez2TDiCt37xStE=; b=Y+0qltiMLmzGhvzpoGEAhrb3ffXFXPtKE0Nvb3Mt/ISS9mzkbqGYxC2G+u4RvSyuzQ +mf9FjfpUxd5e4CIr/HEE8lwKugVjs42RWSjecoJEgzk2mWLk9BNw6E4WDFdYlMCjAqN GrysnnlLrbNTd6hTcaWV61qP+EhygLxGFZW1tCcgtslRjmqofZHdn0Fj4E5zhNsi4U+v KRANmSP1QMjFwOV9v+TYuNmTgSP6LnFi+RlF43f6dxTD9IR0rJqSk864s2PqwYw7ZwMB hX+yDUfFJXRyeksFamhS9gKCNntAiFad07N2ZQm/mPMb3lePSEhojJIMo3GpPTko8lmW /D8A== MIME-Version: 1.0 X-Received: by 10.229.130.65 with SMTP id r1mr116583529qcs.16.1420116158767; Thu, 01 Jan 2015 04:42:38 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.86.163 with HTTP; Thu, 1 Jan 2015 04:42:38 -0800 (PST) In-Reply-To: References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> Date: Thu, 1 Jan 2015 22:42:38 +1000 X-Google-Sender-Auth: p_n__EQM1YtJd3jALn7bfh7Ckco Message-ID: From: Matthew Kerwin To: Larry Masinter Content-Type: multipart/alternative; boundary=001a1133d79a2f0546050b968f71 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZHQROIvOmDY3WvCwxV0JNTpFmk4 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 12:42:42 -0000 --001a1133d79a2f0546050b968f71 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the comments; responses inline. On 10 December 2014 at 05:54, Larry Masinter wrote: > =E2=80=8B=E2=80=8B > > > First comment: > > Please align with the special processing for =E2=80=9Cfile:=E2=80=9D in: > https://specs.webplatform.org/url/webspecs/develop/ > > > That spec (developed in sync with WHATWG URL) focuses on > > parsing and processing of base + relative, when the scheme > > (or base scheme) is =E2=80=9Cfile:=E2=80=9D, while the kerwin-file-schem= e > talks more about mapping between local file paths and =E2=80=9Cfile:=E2= =80=9D > > IRIs (URLs). > > But the overlap is significant, and I hope could be eliminated, > if the direction of moving the webplatform.org spec to > obsolete 3987 is accepted. > > I'm not sure how to approach this request. Do you have any specific details about what's not in alignment, or could be better? Or are you suggesting I hold off doing anything until the webplatform.org draft matures some more? (I refer to that big red box that says "...the parsing rules in this section have not enjoyed wide review, and therefore are more likely to be subject to change than other parts of this specification") I guess I could add support for backslashes. I suspect that would end up in a non-normative appendix, along with the "|" drive letter separator (as suggested in an earlier message, and currently being worked into the next draft.) Second comment: > > > > You describe the relationship between local file names > and =E2=80=98file:=E2=80=99 URLS for =E2=80=9CUNIX-like=E2=80=9D, =E2=80= =9CDOS- or Windows-based=E2=80=9D > and =E2=80=9CVMS Files-11=E2=80=9D. These categories aren=E2=80=99t preci= se or > exhaustive, and file system processing of file names can > vary depending on version, language pack installed in OS, > as well as network protocol (Nfs?). > *=E2=80=8B=E2=80=8B* > > I would rather see a more extensible organization of > the specification by establishing a template, and then > > separately documenting, on a file-system by file-system > basis, how to translate and match, based not on the > URI but on the parsed components resulting from > URL-parsing. This would allow new or different file > systems to be documented. > > That makes sense, and is an appealing suggestion. I will experiment with this, and see if I can come up with a new version that incorporates it. Third comment: > > > > The translation between file names and URLs and things > like them happen in several specs: > > > > content-disposition for file download, multipart/form-data > for file upload, by common HTTP servers, when packaging files > > together into archive types as being discussed by those proposing > > a new =E2=80=98archive=E2=80=99 top level media type. > > > > It would be beneficial if we converge these, as it reduces > interoperability > to have incompatible methods of translation for local files names dependi= ng > on the categorization. > > I've had a quick look at some of the specs (notably RFC 2388, 6266, 5987), and while I agree that we don't want to have too many string-to-filename subsystems, I don't really see what approach to take to unifiy them, or what it would really buy us. For the most part, everything either says "decode percent-encoded UTF-8" or doesn't say anything (implying ASCII/ISO-8859-1?) -- how they then map to the local file system is never touched. =E2=80=8BCheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a1133d79a2f0546050b968f71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the comments; responses inline.
<= div class=3D"gmail_default" style=3D"font-family:georgia,serif;color:rgb(7,= 55,99)">

On 10 December 2014 at 05:54, Larry Masinter <masinter@adobe.com>= wrote:

=E2=80=8B= =E2=80=8B
=C2=A0

First comment:

Please align with the special processing for= =E2=80=9Cfile:=E2=80=9D in:
https://specs.webplatform.org/url/webspecs/develop/


That spec (developed in sync with WHATWG URL= ) focuses on

parsing and processing of base + relative, w= hen the scheme

(or base scheme) is=C2=A0 =E2=80=9Cfile:=E2= =80=9D, while the kerwin-file-scheme
talks more about mapping between local file paths and =E2=80=9Cfile:=E2=80= =9D

IRIs (URLs).


But the overlap is significant, and I hope c= ould be eliminated,
if the direction of moving the webplatform.org spec to
obsolete 3987 is accepted.


I'm not sure how to approach this request. Do you have any = specific details about what's not in alignment, or could be better? Or = are you suggesting I hold off doing anything until the webplatform.org draft matures some more? (I refer to tha= t big red box that says "...the parsing rules in this section have not= enjoyed wide review, and therefore are more likely to be subject to change= than other parts of this specification")
<= br>
I guess I could add support for backslashes. I suspect th= at would end up in a non-normative appendix, along with the "|" d= rive letter separator (as suggested in an earlier message, and currently be= ing worked into the next draft.)


Second comment:

=C2=A0

You describe the relationship between local = file names
and =E2=80=98file:=E2=80=99 URLS for =E2=80=9CUNIX-like=E2=80=9D, =E2=80=9C= DOS- or Windows-based=E2=80=9D
and =E2=80=9CVMS Files-11=E2=80=9D. These categories aren=E2=80=99t precise= or
exhaustive, and file system processing of file names can
vary depending on version, language pack installed in OS,
as well as network protocol (Nfs?).

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

I would rather see a more extensible organiz= ation of
the specification by establishing a template, and then=

separately documenting, on a file-system by = file-system
basis, how to translate and match, based not on the
URI but on the parsed components resulting from
URL-parsing. This would allow new or different file
systems to be documented.


That makes sense,= and is an appealing suggestion. I will experiment with this, and see if I = can come up with a new version that incorporates it.


Third comment:

=C2=A0

The translation between file names and URLs = and things
like them happen in several specs:

=C2=A0

content-disposition for file download, multi= part/form-data
for file upload, by common HTTP servers, when packaging files=

together into archive types as being discuss= ed by those proposing

a new =E2=80=98archive=E2=80=99 top level me= dia type.

=C2=A0

It would be beneficial if we converge these,= as it reduces interoperability
to have incompatible methods of translation for local files names depending=
on the categorization.

I've had a quick look at so= me of the specs (notably RFC 2388, 6266, 5987), and while I agree that we d= on't want to have too many string-to-filename subsystems, I don't r= eally see what approach to take to unifiy them, or what it would really buy= us. For the most part, everything either says "decode percent-encoded= UTF-8" or doesn't say anything (implying ASCII/ISO-8859-1?) -- ho= w they then map to the local file system is never touched.

=E2=80=8BCheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.= net.au/
--001a1133d79a2f0546050b968f71-- From nobody Thu Jan 1 06:21:26 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BFB1A1B56 for ; Thu, 1 Jan 2015 06:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.445 X-Spam-Level: X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWGJURmcJGc8 for ; Thu, 1 Jan 2015 06:21:23 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.226]) by ietfa.amsl.com (Postfix) with ESMTP id 91A401A1B3D for ; Thu, 1 Jan 2015 06:21:23 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:37918] helo=rubix) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 53/DA-31322-2E755A45; Thu, 01 Jan 2015 14:21:23 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 6A4ED140BC9; Thu, 1 Jan 2015 09:21:21 -0500 (EST) Message-ID: <54A557E1.6050502@intertwingly.net> Date: Thu, 01 Jan 2015 09:21:21 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin , Larry Masinter References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/D7-cn_64liB0hv6vvNDRHjwXIXA Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 14:21:25 -0000 On 01/01/2015 07:42 AM, Matthew Kerwin wrote: > Thanks for the comments; responses inline. > > On 10 December 2014 at 05:54, Larry Masinter > wrote: > > First comment: > ____ > > Please align with the special processing for “file:” in: > https://specs.webplatform.org/url/webspecs/develop/____ > > That spec (developed in sync with WHATWG URL) focuses on ____ > parsing and processing of base + relative, when the scheme____ > (or base scheme) is “file:”, while the kerwin-file-scheme > talks more about mapping between local file paths and “file:”____ > IRIs (URLs). ____ > > But the overlap is significant, and I hope could be eliminated, > if the direction of moving the webplatform.org > spec to > obsolete 3987 is accepted. > > I'm not sure how to approach this request. Do you have any specific > details about what's not in alignment, or could be better? Or are you > suggesting I hold off doing anything until the webplatform.org > draft matures some more? (I refer to that big > red box that says "...the parsing rules in this section have not enjoyed > wide review, and therefore are more likely to be subject to change than > other parts of this specification") A few concrete examples are here: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13511.html It is my hope that by comparing notes we can converge. > I guess I could add support for backslashes. I suspect that would end up > in a non-normative appendix, along with the "|" drive letter separator > (as suggested in an earlier message, and currently being worked into the > next draft.) I don't understand the thought process here. The current Internet-Draft takes care to document a select few browser specific syntaxes, but many others (including the ones you mention above) are not included. What is the selection criteria you are using? - Sam Ruby From nobody Thu Jan 1 07:57:38 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D871A1BF2 for ; Thu, 1 Jan 2015 07:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wywmp5_hzZyZ for ; Thu, 1 Jan 2015 07:57:35 -0800 (PST) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id C30861A0102 for ; Thu, 1 Jan 2015 07:57:35 -0800 (PST) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Y6i7w-0000rG-hM; Thu, 01 Jan 2015 15:57:32 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Y6i7w-0007Mt-DQ; Thu, 01 Jan 2015 15:57:32 +0000 Message-ID: <54A56E7C.5010605@ninebynine.org> Date: Thu, 01 Jan 2015 15:57:48 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/DpHaKTioB6zy4QjXK497c8cFaAA Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 15:57:38 -0000 Matthew, I've finally been prompted to read through your https://tools.ietf.org/html/draft-kerwin-file-scheme-13. I think it's great that this is being tackled (again), and I'm hoping that there will be enough pragmatism this time round to achieve consensus on something that's an improvement over the status quo, even if not perfect. My comments follow... Section 2: windows-path I'm pretty sure I've come across '/c:/rest-of-path' as a mapping of Windows file paths (I'm not sure where; I may even have used it myself. It makes some logical sense to me in that on Windows (non-UNC-naming) the drive letters are effectively the top-level directories in a single-root file system.) But that would subsumed by 'path-absolute'. [Later] I see you have this covered as an example, and more. Section 2: Inclusion of "|" As others have raised, there's an question of how to deal with common extensions to normal URI syntax, and separation of a preferred core for file: URI syntax from documentation of common variations. If possible, my preference would be to treat non-conformance with RFC3986, like this, as a common variation. I think 'core' file URIs should preferably be fully RFC3986 conformant so that existing generic parsers will handle them. [Later] I see you have this covered too. I think the document might be clearer in its intent if at the start of section 2, and in the syntax productions, it were more clearly signaled that the syntax described here includes commonly-used forms that go beyond RFC3986 syntax. Section 2: local vs non-local See below. I think this is a non-relevant distinction. e.g. Is a remote file system mounted on a Unix-style mount point supposed to include an authority? Section 3: methods on file URIs I'm not sure I agree that translation to filename is the *only* operation that can be done using a file: URI. And I have concerns about use of the term "method" here, which is strongly suggestive of HTTP "methods". Specifically, dereferencing: I have frequently used APIs that retrieve the entity referenced by a URI, including file: URIs. Indeed, in much of my code, this is central to unifying web and local file access. I think retrieval is an operation that is very naturally performed on a file URI, with results broadly equivalent to an HTTP GET. Some analogue to HTTP PUT is also conceivable. I think the issue here is not that the nature of operations that can be performed is restricted, but the details of how to perform them, which will vary from system to system. You also say "The local file system API can only be used if the file URI has a blank (or absent) authority and the path, when transformed to the local system's conventions, is not a UNC string." A common case I've come across is where the authority is "localhost", in which case it seems reasonable to allow local file access based the file: URI. More generally, it seems to me that the difference between local and remote files (with or without host) is in the mechanism that might be used to access the file. In some cases, it may be the same, by virtue of being handled by the underlying system's file system. And in some cases, a filename that appears to have no host may in fact be remote (cf. remote file system, mounted on Unix-like file system). I think that trying to make this distinction raises more questions than it answers. Section 3.1 (esp step 4): I'm a bit confused by the intent here. I think it's reasonably clear that file://example.org/c:/path/segments file:///c:/path/segments would be expected, but what about: file:/c:/path/segments vs file:c:/path/segments I think you prefer the latter. But I think it would be more consistent, and would avoid potential ambiguities in relative reference resolution, to prefer the former; i.e. to consider that drives are like top-level sub-directories of a root "/". I think this section could also be thereby simplified a little. Section 3.3, steps 5, 6: I think it is necessary to say something about %-escaping here. I've been bitten in the past by doing roughly what you describe here, with filenames that happen to contain (say) '#' characters. Section 6: Can you please include a full registration template for the file: scheme here. cf. https://tools.ietf.org/html/rfc4395#section-5.4 (Many of the fields will just refer to other sections of the document) ... Again, thanks for tackling this. #g -- From nobody Thu Jan 1 08:17:07 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE39D1A1BF8 for ; Thu, 1 Jan 2015 08:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.145 X-Spam-Level: X-Spam-Status: No, score=-3.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, GB_I_LETTER=-2, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPe-4m1sdXiO for ; Thu, 1 Jan 2015 08:17:03 -0800 (PST) Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) by ietfa.amsl.com (Postfix) with ESMTP id 314BC1A1BF5 for ; Thu, 1 Jan 2015 08:17:03 -0800 (PST) Received: from smtp5.mail.ox.ac.uk ([163.1.2.207]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Y6iQm-0007Rn-qz; Thu, 01 Jan 2015 16:17:00 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Y6iQm-000493-GS; Thu, 01 Jan 2015 16:17:00 +0000 Message-ID: <54A5730C.8040501@ninebynine.org> Date: Thu, 01 Jan 2015 16:17:16 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin , Larry Masinter References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/1ioAAZIfGsvtpDGBkc6FnqI3N9Q Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 16:17:06 -0000 On 01/01/2015 12:42, Matthew Kerwin wrote: > Thanks for the comments; responses inline. > > > On 10 December 2014 at 05:54, Larry Masinter wrote: > >> ​​ >> >> >> First comment: >> >> Please align with the special processing for “file:” in: >> https://specs.webplatform.org/url/webspecs/develop/ >> >> >> That spec (developed in sync with WHATWG URL) focuses on >> >> parsing and processing of base + relative, when the scheme >> >> (or base scheme) is “file:”, while the kerwin-file-scheme >> talks more about mapping between local file paths and “file:” >> >> IRIs (URLs). >> >> But the overlap is significant, and I hope could be eliminated, >> if the direction of moving the webplatform.org spec to >> obsolete 3987 is accepted. >> >> I'm not sure how to approach this request. Do you have any specific > details about what's not in alignment, or could be better? Or are you > suggesting I hold off doing anything until the webplatform.org draft > matures some more? (I refer to that big red box that says "...the parsing > rules in this section have not enjoyed wide review, and therefore are more > likely to be subject to change than other parts of this specification") > > I guess I could add support for backslashes. I suspect that would end up in > a non-normative appendix, along with the "|" drive letter separator (as > suggested in an earlier message, and currently being worked into the next > draft.) For some reason, I didn't see Larry's original comment. Probably overwhelmed. But I've just looked at https://specs.webplatform.org/url/webspecs/develop/ and: (a) noticed the same issue that Matthew just noted about the "big red box". (b) The syntax diagram appears to go against RFC3986 by excluding URIs of the form: file:/// corresponding to a blank reg-name for the authority host field: authority = [ userinfo "@" ] host [ ":" port ] host = IP-literal / IPv4address / reg-name reg-name = *( unreserved / pct-encoded / sub-delims ) (excerpted from https://tools.ietf.org/html/rfc3986#appendix-A) This is a form I use extensively in my code, and it's explicitly discussed in the Wikipedia entry for file: URIs, so I guess I'm not alone in this - http://en.wikipedia.org/wiki/File_URI_scheme) > Second comment: >> >> >> >> You describe the relationship between local file names >> and ‘file:’ URLS for “UNIX-like”, “DOS- or Windows-based” >> and “VMS Files-11”. These categories aren’t precise or >> exhaustive, and file system processing of file names can >> vary depending on version, language pack installed in OS, >> as well as network protocol (Nfs?). >> *​​* >> >> I would rather see a more extensible organization of >> the specification by establishing a template, and then >> >> separately documenting, on a file-system by file-system >> basis, how to translate and match, based not on the >> URI but on the parsed components resulting from >> URL-parsing. This would allow new or different file >> systems to be documented. >> >> That makes sense, and is an appealing suggestion. I will experiment with > this, and see if I can come up with a new version that incorporates it. +1 But I'll also note that for practical use on modern systems, the similarity with Unix file naming is really useful. Python's I/O libraries interpret "/" in filenames as directory path separators, even on Windows. This means that I can (and do) use relative path names as relative references that work with respect to a file: URI base, or (say) an HTTP base URI. This helps me to unify accessing both local and web resources. Probably this consideration has no place in the file: scheme specification ... just sayin'. And it doesn't really help with more exotic file systems like VMS - but surely, these are a tiny minority presence on the web these days, so I'm not sure how much concern is justified here. > > Third comment: >> >> >> >> The translation between file names and URLs and things >> like them happen in several specs: >> >> >> >> content-disposition for file download, multipart/form-data >> for file upload, by common HTTP servers, when packaging files >> >> together into archive types as being discussed by those proposing >> >> a new ‘archive’ top level media type. >> >> >> >> It would be beneficial if we converge these, as it reduces >> interoperability >> to have incompatible methods of translation for local files names depending >> on the categorization. >> >> > I've had a quick look at some of the specs (notably RFC 2388, 6266, 5987), > and while I agree that we don't want to have too many string-to-filename > subsystems, I don't really see what approach to take to unifiy them, or > what it would really buy us. For the most part, everything either says > "decode percent-encoded UTF-8" or doesn't say anything (implying > ASCII/ISO-8859-1?) -- how they then map to the local file system is never > touched. I think this also relates to my comment above about the value of being able to unify local file and web resource accessing. I think unifying URIs and Unix-style path names is a useful start, and maybe add extra information for selected other file systems (notably Windows). IMO, having a clear story for Unix/Linux and Windows would address the vast majority of actual systems for which this might be an issue. ... W.r.t. the 'archive' media type that Larry mentions. There may be value in having a common fragment syntax that allows reference to files within an archive. And it would maker sense (to me) if such a syntax could re-use elements a of the URI path syntax and be interpreted in a way that is similar to file: URI paths. For more background on this, see http://w3ctag.github.io/packaging-on-the-web/#fragment-identifiers, specifically the 'url=...' option. Specifically, consider that a directory tree is to be packaged as an archive. Each file in that tree has a relative reference w.r.t. the base of that tree, which when resolved would be a file: URI. It would be convenient if those relative references can also be used as part of fragement identifier referring to the same file within the packaged archive. What I think this all points to is having a uniform representation of paths within a file: URI that is amenable to common RFC3986-style relative reference resolution in a variety of scenarios. I don't think there's any need to call out all these cases explicitly, but to take them in to account when considering design options. #g -- From nobody Thu Jan 1 08:30:44 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2931A00E8 for ; Thu, 1 Jan 2015 08:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.745 X-Spam-Level: X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdHjcEkuBtau for ; Thu, 1 Jan 2015 08:30:39 -0800 (PST) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 514341A00E2 for ; Thu, 1 Jan 2015 08:30:39 -0800 (PST) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Y6idy-0003C8-gj; Thu, 01 Jan 2015 16:30:38 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Y6idy-0004zT-JQ; Thu, 01 Jan 2015 16:30:38 +0000 Message-ID: <54A5763C.5060203@ninebynine.org> Date: Thu, 01 Jan 2015 16:30:52 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Matthew Kerwin References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/o-2UqieFjTk02pQXuuTRfbjNI4U Cc: IETF Apps Discuss , Larry Masinter Subject: Re: [apps-discuss] Call for Adoption: draft-kerwin-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 16:30:41 -0000 On 01/01/2015 06:37, Murray S. Kucherawy wrote: > The BCP for registering schemes appears not to require an RFC, only Expert > Review. As reviewer, I look for significant support or implementation if the scheme is destined for permanent registration. Specifically, from https://tools.ietf.org/html/rfc4395#section-2: New URI schemes SHOULD have clear utility to the broad Internet community, beyond that available with already registered URI schemes. ... a URI scheme definition itself MUST be clear as to how it is expected to function. In practice, I would take publication as an IETF-stream RFC, especially standards-track, as providing a strong indication that a level of consensus or usage exists. Without that, I expect to have other evidence of widespread support/use. In the past, I have pushed back against permanent registrations from the independent stream, as it lacks the same level of community support or conviction. I would prefer to see an individual (non-WG) IETF-stream submission. But in all this, I'm open to discussion, especially with IESG members who may be able to garner evidence of support that I'm not seeing. In the case of file:, I have no doubt that the scheme is both widely supported and widely used. The problems with the current specification have been widely discussed, over a long period. But I would have reservations about permanent registration if there is no clear community consensus about how the scheme may be used or is expected to function. #g -- > On Wed, Dec 31, 2014 at 8:51 PM, Matthew Kerwin > wrote: > >> On 21 December 2014 at 05:55, Larry Masinter wrote: >> >>>> This opens a call for adoption for draft-kerwin-file-scheme, to be >>> processed by APPSAWG. >>> >>> I don't think apps area should take up kerwin-file-scheme as an >>> independent work item, not because the work isn't important but because >>> apps-discuss is too congested to manage the discussion (no responses to my >>> Dec 9 comments >>> https://www.ietf.org/mail-archive/web/apps-discuss/current/msg13462.html >>> ). In general, APPSAWG shouldn't take up URL-scheme permanent >>> registrations? Or should it? This should be addressed in the scheme >>> registration BCP. >>> >>> >> Sorry for not responding sooner, I've been a bit overwhelmed with real >> life, and there's quite a back-log of comments and messages to aggregate >> and process. >> >> Regarding adoption of URL schemes by this WG, what alternatives would you >> propose? I could instead try to make it an individual submission, but this >> particular scheme has a lot of political and emotional history, and there >> seems to be more and more work involved with developing the spec, so I'd >> rather have much more buy-in through the whole process (such as you get >> from a working group). I don't think it's big enough to warrant spinning up >> its own WG, and I'm not aware of any others that would be more appropriate >> than here. >> > > The BCP for registering schemes appears not to require an RFC, only Expert > Review. > > The guideline I've had in mind both for schemes and media types is this: If > there's a lot of development work to be done on the format of what's to be > registered, or if Standards Track status seems to be worthwhile or even > necessary, then a working group (this one or a new one) makes sense. On > the other hand, if it's mostly just documenting and then registering > something already quite well understood, I think the independent stream is > worth considering. Even better: If the required documentation could simply > be included in the registration template, then just do that, and then > there's no need to produce an RFC through any stream. > > An individual submission requires AD sponsorship, and I don't think this > has been shopped to any ADs yet (has it?). > > All that said, one of the earlier threads about this work certainly made me > think there's a non-trivial number of issues that need attention before > this one could be done right, so working group attention (this or a new > one) is warranted. If we want to spin off a WG for it, that's for Barry to > consider (anyone feel like writing a charter?). > > All THAT said, Larry's earlier message (URI cited above) does still need a > reply, I believe. If this draft does get adopted, that will be necessary > before we can progress the document. > > -MSK > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Thu Jan 1 09:04:20 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4633F1A0123 for ; Thu, 1 Jan 2015 09:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_YucQUrfw9c for ; Thu, 1 Jan 2015 09:04:17 -0800 (PST) Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDA81A0092 for ; Thu, 1 Jan 2015 09:04:17 -0800 (PST) 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 1Y6jAU-0004y1-me; Thu, 01 Jan 2015 17:04:14 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Y6jAT-0000HB-Fo; Thu, 01 Jan 2015 17:04:14 +0000 Message-ID: <54A57E1D.90503@ninebynine.org> Date: Thu, 01 Jan 2015 17:04:29 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A56E7C.5010605@ninebynine.org> In-Reply-To: <54A56E7C.5010605@ninebynine.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/AFSFaw-3cEJZ9Nafs0K-2k-OTLM Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 17:04:19 -0000 [Further to my previous, below...] Oops. My bad. Of course, per RFC 3986, c:/foo/bar is an absolute URI with scheme "c". The relative reference form would need to be: ./c:/foo/bar or c%3A/foo/bar But this raises a different, albeit less compelling, reason to prefer file:/c:/foo/bar to avoid mistakes of trying to treat c:/foo/bar as a reference relative to file:// rather than an absolute URI. #g -- On 01/01/2015 15:57, Graham Klyne wrote: > Consider that I have a relative reference: > > c:/foo/bar > > to be resolved against base URI: > > file: > > the result is > > file:c:/foo/bar > > But if it is to be resolved against a base URI: > > file:d:/ > > What should be the resolved URI? Per RFC3986, it would be > > file:d:/c:/foo/bar > > which doesn't make sense if c:, d: are interpreted as Windows drive letters. > > You can't tell here if the reference starting with "c:..." is intended to be an > absolute or relative path. RFC3986 says relative. So there's no way to know if > the desired result above should be > > file:c:/foo/bar > > If the leading "/" is always included, this ambiguity can be resolved > consistently with RFC3986. i.e. > > c:/foo/bar is a relative path > /c:/foo/bar is absolute path From nobody Thu Jan 1 09:20:38 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846331A0164 for ; Thu, 1 Jan 2015 09:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxAvTMjEydKJ for ; Thu, 1 Jan 2015 09:20:36 -0800 (PST) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F244F1A010A for ; Thu, 1 Jan 2015 09:20:35 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id b13so23243452wgh.4 for ; Thu, 01 Jan 2015 09:20:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gw9dklUAQ21YPrGe7DEcTxBppaU4dF0TYF9Vr8WMmJc=; b=a9cr9UqBnoSWTtwRvVSkY4mBQ3rmiU9eqzpJqwriOIZpIAlYoh1/ftaS4Cz4KQcJNs 4Zsn0u27iSJ/Ri3zDaI+TNE7vcoQ05hQ+WA48OhZYzbecYClo0k5LOB/a1kAnHYQEcKK inCqJ9I6HPtTgHjLIdI7A4RYmk4pzUm60IQ64HQhuRPNnA0vocVW3NctzisgG06ss2tg rGcwQVJF8qCmyio4XK8DJKohvd/qb7RzjqxRE2eEdEyFmAqmY3VWxkmiyuonFxPRkxkb q/UgTt24SNKMcJUoVnqZ623BFmvDa61FjeXy6SD/ajsDFZHtgs92Qvzkrtm/BSaJg+AL r1MA== MIME-Version: 1.0 X-Received: by 10.180.91.36 with SMTP id cb4mr123544950wib.30.1420132834744; Thu, 01 Jan 2015 09:20:34 -0800 (PST) Received: by 10.27.204.198 with HTTP; Thu, 1 Jan 2015 09:20:34 -0800 (PST) In-Reply-To: <54A5763C.5060203@ninebynine.org> References: <54A5763C.5060203@ninebynine.org> Date: Thu, 1 Jan 2015 09:20:34 -0800 Message-ID: From: "Murray S. Kucherawy" To: Graham Klyne Content-Type: multipart/alternative; boundary=f46d043d6711261ed1050b9a7184 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XU8NvEDQcuHEOAdL5V4FevWznuc Cc: IETF Apps Discuss , Larry Masinter Subject: Re: [apps-discuss] Call for Adoption: draft-kerwin-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 17:20:37 -0000 --f46d043d6711261ed1050b9a7184 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 1, 2015 at 8:30 AM, Graham Klyne wrote: > In the case of file:, I have no doubt that the scheme is both widely > supported and widely used. The problems with the current specification > have been widely discussed, over a long period. But I would have > reservations about permanent registration if there is no clear community > consensus about how the scheme may be used or is expected to function. > Thanks for chiming in, Graham. Can I take this to mean that as wide adoption increases, your expectation of community discussion and possibly even RFC publication also increase? Such guidance would be useful in deciding which way to guide these thing in the future, especially since there's been such a surge in them lately. -MSK --f46d043d6711261ed1050b9a7184 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 1, 2015 at 8:30 AM, Graham Klyne <gk@ninebyni= ne.org> wrote:
In the case of file:, I have no d= oubt that the scheme is both widely supported and widely used.=C2=A0 The pr= oblems with the current specification have been widely discussed, over a lo= ng period.=C2=A0 But I would have reservations about permanent registration= if there is no clear community consensus about how the scheme may be used = or is expected to function.

Thanks for = chiming in, Graham.

Can I take this to mean that as wide = adoption increases, your expectation of community discussion and possibly e= ven RFC publication also increase?=C2=A0 Such guidance would be useful in d= eciding which way to guide these thing in the future, especially since ther= e's been such a surge in them lately.

-MSK
<= /div>
--f46d043d6711261ed1050b9a7184-- From nobody Thu Jan 1 09:29:05 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137D51A0222 for ; Thu, 1 Jan 2015 09:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, GB_I_LETTER=-2, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTOgD0o4wZ3y for ; Thu, 1 Jan 2015 09:29:02 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.229]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE9D1A01D5 for ; Thu, 1 Jan 2015 09:29:02 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:54388] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 1E/CE-12631-DD385A45; Thu, 01 Jan 2015 17:29:02 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 3145C140CEF; Thu, 1 Jan 2015 12:29:01 -0500 (EST) Message-ID: <54A583DD.9010602@intertwingly.net> Date: Thu, 01 Jan 2015 12:29:01 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Graham Klyne References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> In-Reply-To: <54A5730C.8040501@ninebynine.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZyJtLN0Y1vRSY_y--uEJ9ZYZAig Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 17:29:04 -0000 On 01/01/2015 11:17 AM, Graham Klyne wrote: > On 01/01/2015 12:42, Matthew Kerwin wrote: >> Thanks for the comments; responses inline. >> >> On 10 December 2014 at 05:54, Larry Masinter wrote: >> >>> First comment: >>> >>> Please align with the special processing for “file:” in: >>> https://specs.webplatform.org/url/webspecs/develop/ >>> >>> That spec (developed in sync with WHATWG URL) focuses on >>> >>> parsing and processing of base + relative, when the scheme >>> >>> (or base scheme) is “file:”, while the kerwin-file-scheme >>> talks more about mapping between local file paths and “file:” >>> >>> IRIs (URLs). >>> >>> But the overlap is significant, and I hope could be eliminated, >>> if the direction of moving the webplatform.org spec to >>> obsolete 3987 is accepted. >>> >>> I'm not sure how to approach this request. Do you have any specific >> details about what's not in alignment, or could be better? Or are you >> suggesting I hold off doing anything until the webplatform.org draft >> matures some more? (I refer to that big red box that says "...the parsing >> rules in this section have not enjoyed wide review, and therefore are >> more >> likely to be subject to change than other parts of this specification") >> >> I guess I could add support for backslashes. I suspect that would end >> up in >> a non-normative appendix, along with the "|" drive letter separator (as >> suggested in an earlier message, and currently being worked into the next >> draft.) > > For some reason, I didn't see Larry's original comment. Probably > overwhelmed. But I've just looked at > https://specs.webplatform.org/url/webspecs/develop/ and: > > (a) noticed the same issue that Matthew just noted about the "big red box". I added that big red box. I encourage you to follow the following links: http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0526.html https://mailarchive.ietf.org/arch/msg/apps-discuss/KyxFLw2FCwv7CSpiWAmLr8Ha7vc It is my hope that by working together I can feel confident enough to remove that red box. As it is, I don't feel that either spec matches widely deployed applications. > (b) The syntax diagram appears to go against RFC3986 by excluding URIs > of the form: > > file:/// > > corresponding to a blank reg-name for the authority host field: > > authority = [ userinfo "@" ] host [ ":" port ] > > host = IP-literal / IPv4address / reg-name > > reg-name = *( unreserved / pct-encoded / sub-delims ) > > (excerpted from https://tools.ietf.org/html/rfc3986#appendix-A) > > This is a form I use extensively in my code, and it's explicitly > discussed in the Wikipedia entry for file: URIs, so I guess I'm not > alone in this - http://en.wikipedia.org/wiki/File_URI_scheme) Why do you come the conclusion that it excludes such URIs? Authority can consist of solely a host: https://specs.webplatform.org/url/webspecs/develop/#authority And a host can be an empty string: https://specs.webplatform.org/url/webspecs/develop/#host Additionally, there is a reference implementation and test results: https://url.spec.whatwg.org/interop/test-results/ An example with an empty authority field: https://url.spec.whatwg.org/interop/test-results/48db81fd23 - Sam Ruby From nobody Thu Jan 1 10:01:37 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951F01A0231 for ; Thu, 1 Jan 2015 10:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clKLMRehgarp for ; Thu, 1 Jan 2015 10:01:35 -0800 (PST) Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id E77FF1A020D for ; Thu, 1 Jan 2015 10:01:34 -0800 (PST) Received: from smtp5.mail.ox.ac.uk ([163.1.2.207]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Y6k3x-0000Dc-nF; Thu, 01 Jan 2015 18:01:33 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Y6k3x-0005vS-GI; Thu, 01 Jan 2015 18:01:33 +0000 Message-ID: <54A58B8C.1020504@ninebynine.org> Date: Thu, 01 Jan 2015 18:01:48 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <54A5763C.5060203@ninebynine.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7DgVxh1HZzu0eynS573PYnjuz-Y Cc: IETF Apps Discuss , Larry Masinter Subject: Re: [apps-discuss] Call for Adoption: draft-kerwin-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 18:01:36 -0000 On 01/01/2015 17:20, Murray S. Kucherawy wrote: > On Thu, Jan 1, 2015 at 8:30 AM, Graham Klyne wrote: > >> In the case of file:, I have no doubt that the scheme is both widely >> supported and widely used. The problems with the current specification >> have been widely discussed, over a long period. But I would have >> reservations about permanent registration if there is no clear community >> consensus about how the scheme may be used or is expected to function. >> > > Thanks for chiming in, Graham. > > Can I take this to mean that as wide adoption increases, your expectation > of community discussion and possibly even RFC publication also increase? > Such guidance would be useful in deciding which way to guide these thing in > the future, especially since there's been such a surge in them lately. Murray, I don't think adoption is in question (if I understand correctly what you mean by "adoption"). I come across file: URIs quite often, if (by their nature) in localized contexts. The main concern I see is that past attempts to better document the file: URI scheme have failed to coalesce sufficient consensus about what such a document should say (and not say). I am optimistic that we have a good chance of achieving consensus for some RFC publication based on the current draft (which draws from the previous work). My sense is that most of the active participants in the current debate would see a less-than-perfect document as preferable to no document at all. Exactly what form that publication should take is less clear: app-wg or individual submission (IETF stream) both seem OK to me. For me, the real value in moving towards a consensus specification for file: URIs is that it would provide a common file naming framework for software libraries that unify local and web access to resources. The capability is substantially achievable today based on the available and informal specifications, but there are a number of problematic edge cases (like Windows drive letters) that can cause interop problems. We may not resolve all of these problems to everyone's satisfaction, but I'm hopeful we can make some progress in the right direction. HTH. #g -- From nobody Thu Jan 1 10:15:45 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959A81A212A for ; Thu, 1 Jan 2015 10:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.61 X-Spam-Level: X-Spam-Status: No, score=-4.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyLggbjCxehx for ; Thu, 1 Jan 2015 10:15:42 -0800 (PST) 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 70BF81A03AB for ; Thu, 1 Jan 2015 10:15:41 -0800 (PST) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y6kHV-000Inn-87; Thu, 01 Jan 2015 13:15:33 -0500 Date: Thu, 01 Jan 2015 13:15:32 -0500 From: John C Klensin To: Graham Klyne , "Murray S. Kucherawy" Message-ID: <7C8B88E445D0C503F738E99A@[192.168.1.128]> In-Reply-To: <54A58B8C.1020504@ninebynine.org> References: <54A5763C.5060203@ninebynine.org> <54A58B8C.1020504@ninebynine.org> 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: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0aWyoqZhquddW4NjUmXFEOjdNOs Cc: IETF Apps Discuss , Larry Masinter Subject: Re: [apps-discuss] Call for Adoption: draft-kerwin-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 18:15:43 -0000 --On Thursday, 01 January, 2015 18:01 +0000 Graham Klyne wrote: >... > For me, the real value in moving towards a consensus > specification for file: URIs is that it would provide a common > file naming framework for software libraries that unify local > and web access to resources. The capability is substantially > achievable today based on the available and informal > specifications, but there are a number of problematic edge > cases (like Windows drive letters) that can cause interop > problems. Of course, the more we move in the direction of what sounds to me like a desire to use "file:" to reference resources that may be either local or remote ("web access"), potentially with multiple web locations, the closer we get to "file:" meeting the design criteria of persistence and location-independence that characterize URNs. I'm not commenting right now on whether I think that would be good or bad (not sure I even have an opinion given how widely things that appear to be URIs with a scheme of "file" are used), but these waters are muddy already and I think that, if we decide to muddy them further, it should be with our eyes open. john From nobody Thu Jan 1 10:17:07 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439D71A004B for ; Thu, 1 Jan 2015 10:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxM8ROLAc50A for ; Thu, 1 Jan 2015 10:17:03 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2031A0040 for ; Thu, 1 Jan 2015 10:17:02 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id em10so26771278wid.11 for ; Thu, 01 Jan 2015 10:17:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p9E1atmjO64FP23peu8MTDN/QEMQp3d42/392RohqhQ=; b=dL29IWhPVQ0Y6cJH4XJ/JB+ejIUb87CG+jUT3ksL40uzWAAwzMYpvhaqpm5AC4XEAI jiWkpYTIYqvxD60dXI+770DwDOOcl8ATVgaFjzR04XuVOKDB1Hr1PdWjSVnAxNW1PSnj 4Ztq3xBlA6S8X/c6ly3zoNp49UEdxppGbrEfC4rrSiFp9cUE1dZkcrcPy1pTveqn39GU JgHRrjV1RJk7/7eykFt8wpUTO8trjok0eJ9rRqJkwuKRziFJvB1XpFu9IPrsj1b0uykA 818qX+zH5eZ2C1A9MJ/Tiv1CeXz2JF4bWxwlZG8s3g88U0tOyg4tfWNK5hwGkwsOqoTn UIxg== MIME-Version: 1.0 X-Received: by 10.180.75.199 with SMTP id e7mr127758659wiw.21.1420136220882; Thu, 01 Jan 2015 10:17:00 -0800 (PST) Received: by 10.27.204.198 with HTTP; Thu, 1 Jan 2015 10:17:00 -0800 (PST) In-Reply-To: <54A58B8C.1020504@ninebynine.org> References: <54A5763C.5060203@ninebynine.org> <54A58B8C.1020504@ninebynine.org> Date: Thu, 1 Jan 2015 10:17:00 -0800 Message-ID: From: "Murray S. Kucherawy" To: Graham Klyne Content-Type: multipart/alternative; boundary=f46d04389577fa7ccf050b9b3adf Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/RIjZKSMs5yqB2zXIgqvas92txXE Cc: IETF Apps Discuss , Larry Masinter Subject: Re: [apps-discuss] Call for Adoption: draft-kerwin-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 18:17:04 -0000 --f46d04389577fa7ccf050b9b3adf Content-Type: text/plain; charset=UTF-8 On Thu, Jan 1, 2015 at 10:01 AM, Graham Klyne wrote: > On 01/01/2015 17:20, Murray S. Kucherawy wrote: > >> >> Can I take this to mean that as wide adoption increases, your expectation >> of community discussion and possibly even RFC publication also increase? >> Such guidance would be useful in deciding which way to guide these thing >> in >> the future, especially since there's been such a surge in them lately. >> > > Murray, > > I don't think adoption is in question (if I understand correctly what you > mean by "adoption"). I come across file: URIs quite often, if (by their > nature) in localized contexts. The main concern I see is that past > attempts to better document the file: URI scheme have failed to coalesce > sufficient consensus about what such a document should say (and not say). > [...] > Actually, my question was more general, and not specific to this particular document. I'll rephrase: Can I take this to mean that, as wide adoption of a given a scheme (or media type, though I know that's not what you review) increases, your expectation of community discussion and possibly even RFC publication defining that scheme also increases? -MSK --f46d04389577fa7ccf050b9b3adf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 1, 2015 at 10:01 AM, Graham Klyne <gk@ninebyn= ine.org> wrote:
On 01/01/2015 17:20, Murray S. Kucherawy wrote:

Can I take this to mean that as wide adoption increases, your expectation of community discussion and possibly even RFC publication also increase? Such guidance would be useful in deciding which way to guide these thing in=
the future, especially since there's been such a surge in them lately.<= br>

Murray,

I don't think adoption is in question (if I understand correctly what y= ou mean by "adoption").=C2=A0 I come across file: URIs quite ofte= n, if (by their nature) in localized contexts.=C2=A0 The main concern I see= is that past attempts to better document the file: URI scheme have failed = to coalesce sufficient consensus about what such a document should say (and= not say).
[...]

Actually, my questi= on was more general, and not specific to this particular document.=C2=A0 I&= #39;ll rephrase:

Can I take this to mean that, as wide ad= option of a given a scheme (or media type, though I know that's not wha= t you review) increases, your expectation of community discussion and possi= bly even RFC publication defining that scheme also increases?

=
-MSK
--f46d04389577fa7ccf050b9b3adf-- From nobody Thu Jan 1 10:47:35 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58521A03B3 for ; Thu, 1 Jan 2015 10:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8unr7ZbBhX8 for ; Thu, 1 Jan 2015 10:47:31 -0800 (PST) Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) by ietfa.amsl.com (Postfix) with ESMTP id B62F81A037A for ; Thu, 1 Jan 2015 10:47:31 -0800 (PST) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Y6kmP-0004ne-fC; Thu, 01 Jan 2015 18:47:29 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Y6kmP-0001sX-ES; Thu, 01 Jan 2015 18:47:29 +0000 Message-ID: <54A59651.4060306@ninebynine.org> Date: Thu, 01 Jan 2015 18:47:45 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> In-Reply-To: <54A583DD.9010602@intertwingly.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/c_ZZYSrS-V-uJ8xAtpeWobfmbM8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 18:47:34 -0000 On 01/01/2015 17:29, Sam Ruby wrote: >> For some reason, I didn't see Larry's original comment. Probably >> overwhelmed. But I've just looked at >> https://specs.webplatform.org/url/webspecs/develop/ and: >> >> (a) noticed the same issue that Matthew just noted about the "big red box". > > I added that big red box. I encourage you to follow the following links: Sam, Thanks for the links. My thoughts in response... > > http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0526.html That message appears to be concerned primarily with web browser APIs. While an important constituency, they are not the only one. My own work, which informs my personal interest in this, is more concerned with web server based applications, which might be characterized as "middleware" - i.e. acting as both web servers and clients. With reference to the final comment in that email, I think it would be great if we can agree a form of file: URI usage that works for everyone, so that the URL parsing spec doesn't have to say anything specific about file: URIs. > > https://mailarchive.ietf.org/arch/msg/apps-discuss/KyxFLw2FCwv7CSpiWAmLr8Ha7vc > This raises two points for me: 1. 'file: should be seen as an "escape hatch"'. I disagree. For me, the value of file: URIs is to provide a file naming structure that can be used in libraries that unify local and web access to resources. So I think it's important that file: URIs follow common URI syntax and resolution mechanisms, even if their interpretation for the purposes of dereferencing, etc., is defined locally. (This is not to impose "normative statements on OS vendors for their own software" - unless the vendors choose to use URIs natively for file naming.) 2. Use of vendor-specific documentation I agree with this, specifically: "The right way ... is to write the RFC in such a way that OS-specific variations are not required for RFC-compliance in the first place" So it's clear to me that there are aspects of file: URI handling that are local-context dependent (e.g. how to actually dereference). But I think other activities (such as relative reference resolution should be possible without regard to the underlying file system implementation - and this is the level of commonality that a file: URI scheme RFC should aim to provide. > It is my hope that by working together I can feel confident enough to remove > that red box. As it is, I don't feel that either spec matches widely deployed > applications. > Fair enough. Which suggests to me that focusing on a single focused spec and aligning around that might be a productive way to tackle this. >> (b) The syntax diagram appears to go against RFC3986 by excluding URIs >> of the form: >> >> file:/// >> >> corresponding to a blank reg-name for the authority host field: >> >> authority = [ userinfo "@" ] host [ ":" port ] >> >> host = IP-literal / IPv4address / reg-name >> >> reg-name = *( unreserved / pct-encoded / sub-delims ) >> >> (excerpted from https://tools.ietf.org/html/rfc3986#appendix-A) >> >> This is a form I use extensively in my code, and it's explicitly >> discussed in the Wikipedia entry for file: URIs, so I guess I'm not >> alone in this - http://en.wikipedia.org/wiki/File_URI_scheme) > > Why do you come the conclusion that it excludes such URIs? Authority can > consist of solely a host: > > https://specs.webplatform.org/url/webspecs/develop/#authority > > And a host can be an empty string: > > https://specs.webplatform.org/url/webspecs/develop/#host Sorry, I didn't follow through. I saw "host" with no bypass track, and was incorrectly assuming that "host" could not be empty. I'm happy to accept your assurance that file:/// is allowed in your syntax, and to withdraw that particular comment. #g -- > > Additionally, there is a reference implementation and test results: > > https://url.spec.whatwg.org/interop/test-results/ > > An example with an empty authority field: > > https://url.spec.whatwg.org/interop/test-results/48db81fd23 > > - Sam Ruby > From nobody Thu Jan 1 11:08:29 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9C61A0470 for ; Thu, 1 Jan 2015 11:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CV8CpFhVtUHM for ; Thu, 1 Jan 2015 11:08:24 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.230]) by ietfa.amsl.com (Postfix) with ESMTP id D29381A0636 for ; Thu, 1 Jan 2015 11:08:23 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:65202] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 8F/11-12631-62B95A45; Thu, 01 Jan 2015 19:08:23 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 72DB4140CEF; Thu, 1 Jan 2015 14:08:22 -0500 (EST) Message-ID: <54A59B26.5000408@intertwingly.net> Date: Thu, 01 Jan 2015 14:08:22 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Graham Klyne References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> In-Reply-To: <54A59651.4060306@ninebynine.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/F_fITEpzeV6ORNI17s69ZyBQNDY Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 19:08:26 -0000 On 01/01/2015 01:47 PM, Graham Klyne wrote: > On 01/01/2015 17:29, Sam Ruby wrote: >>> For some reason, I didn't see Larry's original comment. Probably >>> overwhelmed. But I've just looked at >>> https://specs.webplatform.org/url/webspecs/develop/ and: >>> >>> (a) noticed the same issue that Matthew just noted about the "big red >>> box". >> >> I added that big red box. I encourage you to follow the following links: > > Sam, > > Thanks for the links. My thoughts in response... > >> >> http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0526.html > > That message appears to be concerned primarily with web browser APIs. > While an important constituency, they are not the only one. My own > work, which informs my personal interest in this, is more concerned with > web server based applications, which might be characterized as > "middleware" - i.e. acting as both web servers and clients. There are multiple, valid, points of view. My intent was not to pose that link in isolation. > With reference to the final comment in that email, I think it would be > great if we can agree a form of file: URI usage that works for everyone, > so that the URL parsing spec doesn't have to say anything specific about > file: URIs. That would indeed be a great outcome. >> https://mailarchive.ietf.org/arch/msg/apps-discuss/KyxFLw2FCwv7CSpiWAmLr8Ha7vc > > This raises two points for me: > > 1. 'file: should be seen as an "escape hatch"'. > > I disagree. For me, the value of file: URIs is to provide a file naming > structure that can be used in libraries that unify local and web access > to resources. So I think it's important that file: URIs follow common > URI syntax and resolution mechanisms, even if their interpretation for > the purposes of dereferencing, etc., is defined locally. > > (This is not to impose "normative statements on OS vendors for their own > software" - unless the vendors choose to use URIs natively for file > naming.) I'll contrast "can be used in libraries that..." (immediately above), and "works for everyone" (previous point). If the intent of draft-kerwin-file-scheme is only to be valid in a subset of libraries, then it should say so. If it is intended to also match other user agent behaviors (e.g. browsers), then we collectively have considerably more work to do. > 2. Use of vendor-specific documentation > > I agree with this, specifically: "The right way ... is to write the RFC > in such a way that OS-specific variations are not required for > RFC-compliance in the first place" > > So it's clear to me that there are aspects of file: URI handling that > are local-context dependent (e.g. how to actually dereference). But I > think other activities (such as relative reference resolution should be > possible without regard to the underlying file system implementation - > and this is the level of commonality that a file: URI scheme RFC should > aim to provide. I'll note that draft-kerwin-file-scheme includes such constructs as windows-path and unc-path. >> It is my hope that by working together I can feel confident enough to >> remove >> that red box. As it is, I don't feel that either spec matches widely >> deployed >> applications. > > Fair enough. Which suggests to me that focusing on a single focused > spec and aligning around that might be a productive way to tackle this. What I am focused on is the following question: what should a "URI.parse" method do? In some ways that question is more general (in that is isn't file: scheme specific). In some ways that question is more focused (in that it doesn't attempt to describe the operating system specific interpretations of the results). > - Sam Ruby From nobody Thu Jan 1 13:08:24 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE481A1A88 for ; Thu, 1 Jan 2015 13:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdcBGMDbIF70 for ; Thu, 1 Jan 2015 13:08:21 -0800 (PST) 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 BCA521A1A6B for ; Thu, 1 Jan 2015 13:08:20 -0800 (PST) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y6myh-000J7Z-CZ; Thu, 01 Jan 2015 16:08:19 -0500 Date: Thu, 01 Jan 2015 16:08:18 -0500 From: John C Klensin To: Nick Matavka , apps-discuss@ietf.org Message-ID: <075D7793E42A501B9B9A014D@P5> 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: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/pv8vXhG-ytzCZtqpU5U8yeVPl5s Subject: Re: [apps-discuss] Gopher updated spec X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 21:08:22 -0000 --On Wednesday, 31 December, 2014 20:44 -0500 Nick Matavka wrote: > I made a few rather substantial edits to that gopher spec, for > the dinosaurs that still care. It is available on > piratepad.net/gopher > > If there are any conflicts or fixes, please do not hesitate to > inform me because I would like to fast track this through the > indie submissions stream. Speaking as a dinosaur who hasn't determined if he should care or not, (1) I will not read this spec or attempt to comment in any substantive way until there is a posted I-D in the archives. References to private copies of documents don't count. (2) I don't know what opinions you might be able to get informally, but the Independent Submission Editor is not allowed to consider a document unless it has been posted as an I-D. If there is such a thing as an "indie submissions stream fast track, I'm not aware of it and I've served in one advisory function or another to the function that is now the ISE for significantly more than 20 years. You might also want to have a discussion with the Chairs of this WG and/or the Apps ADs as to whether this WG is an appropriate forum for something you intend to send to the ISE (I don't have an opinion on that, but the question should be asked). (3) I hope that, when there is a document, the motivation for publishing it is extremely clear. Unless you can point to Gopher implementations in active use or plans to deploy new ones, that may be difficult. I would personally welcome such developments --I think we lost some functionality when the HTTP/HTTPS web swept away both Gopher and WAIS -- but that belief has shown no signs of getting traction in the community. It the goal is just to publish a complete description of a long-unused protocol, I suggest that IEEE Internet, ACM Communications, or something similar might be much better publication venues than the RFC Series, but I'm not the ISE and would not presume to speak for him. regards, john From nobody Thu Jan 1 13:48:09 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E5B1A1AFF for ; Thu, 1 Jan 2015 13:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.512 X-Spam-Level: X-Spam-Status: No, score=-0.512 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFwq85WmtcEp for ; Thu, 1 Jan 2015 13:48:07 -0800 (PST) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (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 6B99E1A1AF6 for ; Thu, 1 Jan 2015 13:48:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by orthanc.ca (8.14.7/8.14.7) with ESMTP id t01Lm3L1004615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2015 13:48:04 -0800 (PST) (envelope-from lyndon@orthanc.ca) Date: Thu, 1 Jan 2015 13:48:03 -0800 (PST) From: Lyndon Nerenberg To: John C Klensin In-Reply-To: <075D7793E42A501B9B9A014D@P5> Message-ID: References: <075D7793E42A501B9B9A014D@P5> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-LlAG0HYklpJLteVii2eIZvaEkQ Cc: Nick Matavka , apps-discuss@ietf.org Subject: Re: [apps-discuss] Gopher updated spec X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 21:48:08 -0000 > (3) I hope that, when there is a document, the motivation for > publishing it is extremely clear. Unless you can point to > Gopher implementations in active use or plans to deploy new > ones, that may be difficult. I would personally welcome such > developments --I think we lost some functionality when the > HTTP/HTTPS web swept away both Gopher and WAIS -- but that > belief has shown no signs of getting traction in the community. Gopher played an important, if brief, role in the evolution of the Internet, and it should be documented for that reason alone. There is also some educational value to it (as you hint at above), by showing that simple protocols can support powerful applications. Certainly this is worthy of an Informational RFC. --lyndon From nobody Thu Jan 1 14:03:16 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3461A1B05 for ; Thu, 1 Jan 2015 14:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLnZJ7JClXGR for ; Thu, 1 Jan 2015 14:03:12 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA271A1ADB for ; Thu, 1 Jan 2015 14:03:11 -0800 (PST) Received: internal info suppressed Date: Thu, 1 Jan 2015 23:03:07 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: John C Klensin In-Reply-To: <075D7793E42A501B9B9A014D@P5> Message-ID: References: <075D7793E42A501B9B9A014D@P5> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1420149788; bh=lwUCNLkAQMtd7WxyQpD27WlvCSTRyeB13eyEK8eq7g8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=HoOf/adnYTZIAASMnFK2/ikS4XpqGL6/KkcD2OboKwGpCJ+Hd8mLTR0iO1GuMDvdj fBoFZa4WMHl9eLd+Hic9pM3WTWjJVvDtW8pC4UuAcdpRafOpsyArlga2duAYbVhZP0 TAvpaTqLKNoVHz+5e49PCzjeI/sXBgLEmW/1K6Tg= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/HPZ4lxXkRJfMt60G0cwloQhsA8U Cc: Nick Matavka , apps-discuss@ietf.org Subject: Re: [apps-discuss] Gopher updated spec X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 22:03:14 -0000 Also speaking as a survived dinosaur, I was indeed expecting an official I-D submission after Nick first message, and not yet another private posted document. I-D can have many versions, thus it makes no sense not to use them in the formal way. If the goal is to document a "still existing practice" with undocumented extensions, we also have the "Informational" series, which is NOT a standard at all, but helps for suc documentation purpouses. So, Nick... let us know how you intend to proceed... I of course fully second John's message below. On Thu, 1 Jan 2015, John C Klensin wrote: > > > --On Wednesday, 31 December, 2014 20:44 -0500 Nick Matavka > wrote: > >> I made a few rather substantial edits to that gopher spec, for >> the dinosaurs that still care. It is available on >> piratepad.net/gopher >> >> If there are any conflicts or fixes, please do not hesitate to >> inform me because I would like to fast track this through the >> indie submissions stream. > > Speaking as a dinosaur who hasn't determined if he should care > or not, > > (1) I will not read this spec or attempt to comment in any > substantive way until there is a posted I-D in the archives. > References to private copies of documents don't count. > > (2) I don't know what opinions you might be able to get > informally, but the Independent Submission Editor is not allowed > to consider a document unless it has been posted as an I-D. If > there is such a thing as an "indie submissions stream fast > track, I'm not aware of it and I've served in one advisory > function or another to the function that is now the ISE for > significantly more than 20 years. You might also want to have a > discussion with the Chairs of this WG and/or the Apps ADs as to > whether this WG is an appropriate forum for something you intend > to send to the ISE (I don't have an opinion on that, but the > question should be asked). > > (3) I hope that, when there is a document, the motivation for > publishing it is extremely clear. Unless you can point to > Gopher implementations in active use or plans to deploy new > ones, that may be difficult. I would personally welcome such > developments --I think we lost some functionality when the > HTTP/HTTPS web swept away both Gopher and WAIS -- but that > belief has shown no signs of getting traction in the community. > > It the goal is just to publish a complete description of a > long-unused protocol, I suggest that IEEE Internet, ACM > Communications, or something similar might be much better > publication venues than the RFC Series, but I'm not the ISE and > would not presume to speak for him. > > regards, > john > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Thu Jan 1 14:03:48 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A60F1A1B15 for ; Thu, 1 Jan 2015 14:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kykPFEnNx6Lm for ; Thu, 1 Jan 2015 14:03:46 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA3F1A1B13 for ; Thu, 1 Jan 2015 14:03:46 -0800 (PST) Received: from [172.29.105.22] (wsip-72-214-58-13.sd.sd.cox.net [72.214.58.13]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t01M3eYR012024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 Jan 2015 14:03:43 -0800 Message-ID: <54A5C434.6080806@dcrocker.net> Date: Thu, 01 Jan 2015 14:03:32 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Lyndon Nerenberg References: <075D7793E42A501B9B9A014D@P5> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 01 Jan 2015 14:03:44 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/swGXVhQU406vfI_NN4nK8MYOyCs Cc: Nick Matavka , apps-discuss@ietf.org Subject: Re: [apps-discuss] Gopher updated spec X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 01 Jan 2015 22:03:47 -0000 On 1/1/2015 1:48 PM, Lyndon Nerenberg wrote: > Gopher played an important, if brief, role in the evolution of the > Internet, and it should be documented for that reason alone. There is > also some educational value to it (as you hint at above), by showing > that simple protocols can support powerful applications. Certainly this > is worthy of an Informational RFC. +1. In fact, gopher was the first wide-spread, user-friendly publishing mechanism, after the long-standing and un-friendly anonymous FTP. It preceded web use significantly and for a time, there was real competition between gopher and web. At the time, only html documents could be published for the web, while gopher was text based. So it was easier to publish through gopher, albeit documents weren't as pretty. My own realization of what the net would become was in 1990 -- the web had essentially no deployment yet -- when demonstrating gopher to a class of AT&T folk and we landed on a page in Wellington NZ showing their town council minutes for the week before. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jan 1 14:16:44 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25991A1A2C for ; Thu, 1 Jan 2015 14:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBANMHNsSHdE for ; Thu, 1 Jan 2015 14:16:39 -0800 (PST) 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 6EFC81A1AF8 for ; Thu, 1 Jan 2015 14:16:39 -0800 (PST) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Y6o2n-000JGb-6W; Thu, 01 Jan 2015 17:16:37 -0500 Date: Thu, 01 Jan 2015 17:16:36 -0500 From: John C Klensin To: Lyndon Nerenberg Message-ID: In-Reply-To: References: <075D7793E42A501B9B9A014D@P5> 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: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7TmGI0KTu5L7pMzOtMtjO96jPxU Cc: Nick Matavka , apps-discuss@ietf.org Subject: Re: [apps-discuss] Gopher updated spec X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 22:16:42 -0000 --On Thursday, 01 January, 2015 13:48 -0800 Lyndon Nerenberg wrote: >> (3) I hope that, when there is a document, the motivation for >> publishing it is extremely clear. Unless you can point to >> Gopher implementations in active use or plans to deploy new >> ones, that may be difficult. I would personally welcome such >> developments --I think we lost some functionality when the >> HTTP/HTTPS web swept away both Gopher and WAIS -- but that >> belief has shown no signs of getting traction in the >> community. > > Gopher played an important, if brief, role in the evolution of > the Internet, and it should be documented for that reason > alone. There is also some educational value to it (as you > hint at above), by showing that simple protocols can support > powerful applications. Certainly this is worthy of an > Informational RFC. It is precisely because of that historical record that I'd prefer to see a careful description of the protocol --as it existed and was used --published for a broader audience than the usual browsers of the RFC series. On the other hand, if the intent is to describe new implementations or ways that Gopher could be made better, the IETF audience is probably the right one. But, again, if an independent submission is planned, this would be up to the ISE... after an I-D is posted. john From nobody Thu Jan 1 15:26:14 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D901A854D for ; Thu, 1 Jan 2015 15:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnv_qGUnw9o5 for ; Thu, 1 Jan 2015 15:26:11 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 894E21A86E2 for ; Thu, 1 Jan 2015 15:26:10 -0800 (PST) Received: from [192.168.123.151] (unknown [23.241.1.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CA8BC22E25F; Thu, 1 Jan 2015 18:26:08 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <54A4200C.2040706@ninebynine.org> Date: Thu, 1 Jan 2015 15:26:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <21F9EC2D-2F87-4278-A139-F4C19F93CE2B@seantek.com> References: <20141228232409.13727.85741.idtracker@ietfa.amsl.com> <54A11093.1010100@seantek.com> <54A4200C.2040706@ninebynine.org> To: Graham Klyne X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/S-w-Hnwwe2UFPtjty6w-kZHVoYI Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] New Version Notification for draft-seantek-text-markdown-use-cases-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jan 2015 23:26:12 -0000 Hello, On Dec 31, 2014, at 8:10 AM, Graham Klyne wrote: > Hi, >=20 > I took a quick skim. I'm not sure I find the background rationale = especially useful, and haven't reviewed it in detail (but I've no = objection to it - as if that mattered!). Ok. Well, it hasn=92t changed much (actually not at all) from past = revisions. >=20 > In the sections on the various markdown flavours/variants, I think it = might be helpful to provide separate links for format documentation vs = implementations. I had the impression that links provided were for one = or the other or maybe both, according to what is at hand. Mainly, for = implementations, I think it could be helpful to call out (a) available = implementations that can be used locally, and (b) public systems that do = useful things with specific markdown flavors. The links in the References field are to the documentation of the syntax = for the variant. Frequently, the only documentation about the variant is = in documentation accompanying the primary implementation (e.g., pandoc =3D= README section called pandoc=92s markdown). The prior registration template distinguished between syntax = documentation and extant implementations. There was a lot of pushback on = draft-03 that the whole thing was too complicated. (I deemed the = objection legitimate on grounds that if the registration process is too = cumbersome, people who want to interoperate with a variant will not = bother to register at all.) I tried to simplify the template as much as = possible; this is the result. I don=92t see a principled distinction between (a) and (b). Sure, pandoc = is shipped as a command-line tool [a]; =93GitHub Flavored Markdown=94 is = used by github.com, which is a web app dingus [b]. But anyone can stick = a web service front-end onto pandoc (there are examples out there; = consider Authorea for example). MarkdownPad, a local editor, implements = GFM. Therefore the fact that there are implementations on either side of = the client-server divide doesn=92t really impact the registration. >=20 > (Does this also suggest a tweak to the registration template?) Yes, see text-markdown-05 for the new registration template, which has = been drastically simplified. (In particular look at the diff between = draft-03 and draft-04.) Sean= From nobody Thu Jan 1 18:46:37 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0131A86DE for ; Thu, 1 Jan 2015 18:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGg7Anxvcvx5 for ; Thu, 1 Jan 2015 18:46:32 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0650.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:650]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 478421A8546 for ; Thu, 1 Jan 2015 18:46:32 -0800 (PST) Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) with Microsoft SMTP Server (TLS) id 15.1.49.12; Fri, 2 Jan 2015 02:46:09 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) by DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) with mapi id 15.01.0049.002; Fri, 2 Jan 2015 02:46:09 +0000 From: Larry Masinter To: IETF Apps Discuss Thread-Topic: uri-scheme-reg rules for updating a permanent scheme Thread-Index: AdAmMYDqvV5bH5t4Q8KLR84gqoNEnQ== Date: Fri, 2 Jan 2015 02:46:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:9:8380:992:2ccd:f6f9:7143:5215] authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB0960; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB0960; x-forefront-prvs: 0444EB1997 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(33656002)(101416001)(2656002)(110136001)(230783001)(99396003)(19580395003)(50986999)(54356999)(54206007)(4396001)(31966008)(46102003)(107886001)(21056001)(87936001)(99286002)(92566001)(54606007)(120916001)(64706001)(74316001)(68736005)(450100001)(62966003)(2900100001)(97736003)(20776003)(40100003)(122556002)(77156002)(102836002)(229853001)(107046002)(86362001)(15975445007)(76576001)(106356001)(105586002)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0960; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2015 02:46:08.3123 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB0960 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3gKWCLI41fjCRGCfe5dgpNkGADc Subject: [apps-discuss] uri-scheme-reg rules for updating a permanent scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jan 2015 02:46:35 -0000 SW4gdGFsa2luZyBhYm91dCBrZXJ3aW4tZmlsZS1zY2hlbWUsIGl0IHdhcyBjbGFpbWVkOg0KPiBU aGUgQkNQIGZvciByZWdpc3RlcmluZyBzY2hlbWVzIGFwcGVhcnMgbm90IHRvIHJlcXVpcmUgYW4g UkZDLCBvbmx5IEV4cGVydCBSZXZpZXcuDQoNCmJ1dA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1hcHBzYXdnLXVyaS1zY2hlbWUtcmVnLTAzI3NlY3Rpb24tNy4zDQoNCiAg IFJlZ2lzdHJhdGlvbnMgY2FuIGJlIHVwZGF0ZWQgaW4gdGhlIHJlZ2lzdHJ5IGJ5IHRoZSBzYW1l IG1lY2hhbmlzbSBhcw0KICAgcmVxdWlyZWQgZm9yIGFuIGluaXRpYWwgcmVnaXN0cmF0aW9uLiAg SW4gY2FzZXMgd2hlcmUgdGhlIG9yaWdpbmFsDQogICBkZWZpbml0aW9uIG9mIHRoZSBzY2hlbWUg aXMgY29udGFpbmVkIGluIGFuIElFU0ctYXBwcm92ZWQgZG9jdW1lbnQsDQogICB1cGRhdGUgb2Yg dGhlIHNwZWNpZmljYXRpb24gYWxzbyByZXF1aXJlcyBJRVNHIGFwcHJvdmFsLg0KDQpJRVNHIGFw cHJvdmFsICh1c3VhbGx5KSBoYXBwZW5zIGJ5IGFwcHJvdmFsIG9mIHNvbWV0aGluZyBmb3IgcHVi bGljYXRpb24gYXMgYW4gUkZDLg0KU2hvdWxkIHRoaXMgYmUgbW9yZSBleHBsaWNpdD8gSG93IGVs c2UgY291bGQgc29tZW9uZSBhc2sgZm9yIElFU0cgYXBwcm92YWw/DQoNClNob3VsZG4ndCB0aGVy ZSBiZSBndWlkZWxpbmVzIGZvciB1cGRhdGVzIHRvIGEgcmVnaXN0cmF0aW9uIHRoYXQNCnRhbGtz IGFib3V0IHJldmlldyBhZ2FpbnN0IHdpZGVseSBkZXBsb3llZCBpbXBsZW1lbnRhdGlvbnM/DQoN CkZvciBleGFtcGxlLCByZXF1aXJlbWVudHMgdGhhdCB1cGRhdGVzIFNIT1VMRA0KKiAgc2lnbmlm aWNhbnRseSBpbXByb3ZlIHRoZSBtYXRjaCB3aXRoIGRlcGxveWVkIGltcGxlbWVudGF0aW9ucywg YW5kL29yDQoqICBub3RlLCBhcyBhbiBpbnRlcm9wZXJhYmlsaXR5IGNvbnNpZGVyYXRpb24sIHdp ZGUgZGVwbG95bWVudHMNCiAgICB0aGF0IGRvbid0IG1hdGNoLCBhbmQNCiogaGF2ZSBldmlkZW5j ZSBvZiByZXZpZXcgYnkgdGhvc2UgcmVzcG9uc2libGUgZm9yICB3aXRoDQogICB1cGRhdGVzIHRv IGN1cnJlbnQgaW1wbGVtZW50YXRpb25zLCB3aXRoIGNvbmZpZGVuY2UgdGhhdA0KICAgdGhleSB3 aWxsIGNvbmZvcm0gdG8gdGhlIG5ldyBzcGVjLg0KDQpMYXJyeQ0KLS0NCmh0dHA6Ly9sYXJyeS5t YXNpbnRlci5uZXQNCiANCg== From nobody Thu Jan 1 23:29:19 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570FA1A0069 for ; Thu, 1 Jan 2015 23:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2u8Fjsx_WDe for ; Thu, 1 Jan 2015 23:29:16 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB0C1A006C for ; Thu, 1 Jan 2015 23:29:15 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 80DE832E54D; Fri, 2 Jan 2015 16:28:30 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 171e_5711_2d254798_6da3_45b7_956b_018fcb3d1ade; Fri, 02 Jan 2015 16:28:30 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id BDED0BF4CC; Fri, 2 Jan 2015 16:28:29 +0900 (JST) Message-ID: <54A648A0.9080509@it.aoyama.ac.jp> Date: Fri, 02 Jan 2015 16:28:32 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John C Klensin , Graham Klyne , "Murray S. Kucherawy" References: <54A5763C.5060203@ninebynine.org> <54A58B8C.1020504@ninebynine.org> <7C8B88E445D0C503F738E99A@[192.168.1.128]> In-Reply-To: <7C8B88E445D0C503F738E99A@[192.168.1.128]> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/w7GgYW146t77RDqgsVj0mdt2Mz4 Cc: IETF Apps Discuss , Larry Masinter Subject: Re: [apps-discuss] Call for Adoption: draft-kerwin-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jan 2015 07:29:18 -0000 Hello John, On 2015/01/02 03:15, John C Klensin wrote: > > > --On Thursday, 01 January, 2015 18:01 +0000 Graham Klyne > wrote: > >> ... >> For me, the real value in moving towards a consensus >> specification for file: URIs is that it would provide a common >> file naming framework for software libraries that unify local >> and web access to resources. The capability is substantially >> achievable today based on the available and informal >> specifications, but there are a number of problematic edge >> cases (like Windows drive letters) that can cause interop >> problems. > > Of course, the more we move in the direction of what sounds to > me like a desire to use "file:" to reference resources that may > be either local or remote ("web access"), I'll let Graham confirm (or deny) this, but it seems to me that you are misunderstanding him. I think he is speaking about URIs in general providing the framework, with http/s: for web access and file: for local access. Regards, Martin. potentially with > multiple web locations, the closer we get to "file:" meeting the > design criteria of persistence and location-independence that > characterize URNs. > > I'm not commenting right now on whether I think that would be > good or bad (not sure I even have an opinion given how widely > things that appear to be URIs with a scheme of "file" are used), > but these waters are muddy already and I think that, if we > decide to muddy them further, it should be with our eyes open. > > john > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Fri Jan 2 01:26:49 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4014D1A0111 for ; Fri, 2 Jan 2015 01:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDYwyqiZX78I for ; Fri, 2 Jan 2015 01:26:39 -0800 (PST) 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 A35161A0041 for ; Fri, 2 Jan 2015 01:26:38 -0800 (PST) Received: from [192.168.2.121] ([93.217.73.238]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MMk99-1YCDy106Ot-008dJ1; Fri, 02 Jan 2015 10:26:26 +0100 Message-ID: <54A6643B.50208@gmx.de> Date: Fri, 02 Jan 2015 10:26:19 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , Graham Klyne References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> In-Reply-To: <54A59B26.5000408@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:3Ppwe8VuVZUYvCH+dXt24ymvd568JQnHrkIcvPYy3vbIr71HJ7g 0LFYEKV06kc1obFMzuIU1PRuF2JX390peTAsJ+7HJXSrYcV1L2Pdkcqura6wZVXn6TxRQF6 8APoCt3mQDdl6guk4SKPSK8UaPPn3Ci6jn44jaIGQ0vcMmxHP6LNnqbo+5EUGi4sxAwfvHu fa7jHNTfNOf8r1OdONKCQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ECJJPwv9g9iRnM4_O0dMss3jvpI Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jan 2015 09:26:45 -0000 On 2015-01-01 20:08, Sam Ruby wrote: > ... > Here is a filtered list of test results that only considers RFC 3986 > valid URI references as inputs: > > https://url.spec.whatwg.org/interop/test-results/?filter=valid > ... Checking the first test : "http://example\t.\norg" This is not a valid URI reference. I understand that this is work-in-progress, but please do not pretend we have a large set of valid URI tests that expose problems when in fact we do not. Best regards, Julian From nobody Fri Jan 2 01:47:02 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3D71A0275 for ; Fri, 2 Jan 2015 01:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLNpxRo2GZEI for ; Fri, 2 Jan 2015 01:46:59 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.225]) by ietfa.amsl.com (Postfix) with ESMTP id 40A831A0250 for ; Fri, 2 Jan 2015 01:46:59 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:61962] helo=rubix) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 8C/D5-31322-21966A45; Fri, 02 Jan 2015 09:46:58 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id CA675140169; Fri, 2 Jan 2015 04:46:57 -0500 (EST) Message-ID: <54A66911.7000403@intertwingly.net> Date: Fri, 02 Jan 2015 04:46:57 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Julian Reschke References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> <54A6643B.50208@gmx.de> In-Reply-To: <54A6643B.50208@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/GlJlL469EntOPZ64USEc4SDwk7Q Cc: Graham Klyne , apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jan 2015 09:47:00 -0000 On 01/02/2015 04:26 AM, Julian Reschke wrote: > On 2015-01-01 20:08, Sam Ruby wrote: >> ... >> Here is a filtered list of test results that only considers RFC 3986 >> valid URI references as inputs: >> >> https://url.spec.whatwg.org/interop/test-results/?filter=valid >> ... > > Checking the first test > : > > "http://example\t.\norg" > > This is not a valid URI reference. > > I understand that this is work-in-progress, but please do not pretend we > have a large set of valid URI tests that expose problems when in fact we > do not. I'm not seeing what you are seeing. If you go to the following page: https://url.spec.whatwg.org/interop/test-results/ Test '0' is indeed the test you are describing. Selecting 'showing only valid URI references', filters out that line, showing only tests 1, 2, 7, 8, 9, ... The filter used can be found here: https://gist.github.com/think49/770087 Patches welcome. > Best regards, Julian - Sam Ruby From nobody Fri Jan 2 01:49:13 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7695B1A0275 for ; Fri, 2 Jan 2015 01:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzMopB2eLaKl for ; Fri, 2 Jan 2015 01:49:09 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 A398F1A0270 for ; Fri, 2 Jan 2015 01:49:08 -0800 (PST) Received: from [192.168.2.121] ([93.217.73.238]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lm3H7-1XYC411xuD-00Zk9e; Fri, 02 Jan 2015 10:48:56 +0100 Message-ID: <54A66982.6070401@gmx.de> Date: Fri, 02 Jan 2015 10:48:50 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> <54A6643B.50208@gmx.de> <54A66911.7000403@intertwingly.net> In-Reply-To: <54A66911.7000403@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:O9Fwyx0OJcOCmN/QpyWT8m1LOF4h5aaCdvemzm8dL+qYVLmxLwq V+6HkZhaOSFuj+A1KUs6VK/sj1cBuDCx9/HbD7VA8oKCc4c4Hkd5drbAJXYhuey1lTWmJ4M vfvl/pmByE2qL2eAWjheS8FITzyQBYrUlVubWJrfPwc/Vwt6z88QsiC3eHaqmu6NSTqrmJv Lc2URK6BQATERXEenEpww== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/isHNPi7WT6kAvNrI6l50fV6lo9g Cc: Graham Klyne , apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jan 2015 09:49:10 -0000 On 2015-01-02 10:46, Sam Ruby wrote: > > > On 01/02/2015 04:26 AM, Julian Reschke wrote: >> On 2015-01-01 20:08, Sam Ruby wrote: >>> ... >>> Here is a filtered list of test results that only considers RFC 3986 >>> valid URI references as inputs: >>> >>> https://url.spec.whatwg.org/interop/test-results/?filter=valid >>> ... >> >> Checking the first test >> : >> >> >> "http://example\t.\norg" >> >> This is not a valid URI reference. >> >> I understand that this is work-in-progress, but please do not pretend we >> have a large set of valid URI tests that expose problems when in fact we >> do not. > > I'm not seeing what you are seeing. > > If you go to the following page: > > https://url.spec.whatwg.org/interop/test-results/ > > Test '0' is indeed the test you are describing. > > Selecting 'showing only valid URI references', filters out that line, > showing only tests 1, 2, 7, 8, 9, ... > > The filter used can be found here: > > https://gist.github.com/think49/770087 > > Patches welcome. > >> Best regards, Julian > > - Sam Ruby Indeed; it was a caching problem (Firefox had previous results in the cache). Best regards, Julian From nobody Fri Jan 2 02:01:45 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC6B1A0338 for ; Fri, 2 Jan 2015 02:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0veZU4-nAspI for ; Fri, 2 Jan 2015 02:01:40 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 9AC041A0270 for ; Fri, 2 Jan 2015 02:01:39 -0800 (PST) Received: from [192.168.2.121] ([93.217.73.238]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LxPAo-1XmgE71GRu-016tAV; Fri, 02 Jan 2015 11:01:29 +0100 Message-ID: <54A66C73.7000508@gmx.de> Date: Fri, 02 Jan 2015 11:01:23 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , Graham Klyne References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> In-Reply-To: <54A59B26.5000408@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:HG43U0sCyA9qovv39o5sQmWtQAqx/Tr0+ivG5ZqyA4XEnUgcfPB 00yjWfwhVXKP9H7XF38FdMgRnbz5CHgb86RO2z09j6lo37nij5gXhXzLMOKWjB5S6+dPuh3 DkanjdtKrpx9hcscqWoaqAn4giuuem6Ar4PxvQRZKgYknLNUT5rDkyoAjSDM50zEm23/6pJ 9ezQcK8IalpFMpe8YoNDw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Dk0eoKimWtYaYGBjUkp2s-8QotE Cc: apps-discuss@ietf.org Subject: [apps-discuss] URI parsing tests: userinfo handling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jan 2015 10:01:42 -0000 On 2015-01-01 20:08, Sam Ruby wrote: > ... > I have evidence that RFC 3986 doesn't match a variety of user agent > behavior. Agents that aren't limited to browsers, but also to libraries > that are used by what you would consider "middleware". > > Here is a filtered list of test results that only considers RFC 3986 > valid URI references as inputs: > > https://url.spec.whatwg.org/interop/test-results/?filter=valid > ... So I'm now looking at the first valid entry with UA differences: which tests: http://user:pass@foo:21/bar;par?b#c This one is valid per the RFC 3986 ABNF and it contains a "userinfo" component. RFC 3986: "...Use of the format "user:password" in the userinfo field is deprecated. Applications should not render as clear text any data after the first colon (":") character found within a userinfo subcomponent unless the data after the colon is the empty string (indicating no password). Applications may choose to ignore or reject such data when it is received as part of a reference and should reject the storage of such data in unencrypted form. The passing of authentication information in clear text has proven to be a security risk in almost every case where it has been used...." -- RFC 7230: "The URI generic syntax for authority also includes a deprecated userinfo subcomponent ([RFC3986], Section 3.2.1) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, even though such usage might expose a user identifier or password. A sender MUST NOT generate the userinfo subcomponent (and its "@" delimiter) when an "http" URI reference is generated within a message as a request target or header field value. Before making use of an "http" URI reference received from an untrusted source, a recipient SHOULD parse for userinfo and treat its presence as an error; it is likely being used to obscure the authority for the sake of phishing attacks." -- Looking at the test results suggests that a) only the Python implementation is really broken (it probably follows RFC 2396 which treated params as a separate component; Firefox had a similar problem until a few years ago; but that was fixed by me) b) IE gets away with treating the presence of userinfo as an error; it probably would be a good idea if other UAs followed that example. Best regards, Julian From nobody Fri Jan 2 02:43:44 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8154B1A1A2E for ; Fri, 2 Jan 2015 02:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxgzZAe2I8ub for ; Fri, 2 Jan 2015 02:43:38 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.231]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3D31A1A28 for ; Fri, 2 Jan 2015 02:43:38 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:65308] helo=rubix) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 3F/DE-31322-95676A45; Fri, 02 Jan 2015 10:43:37 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 2B03F140169; Fri, 2 Jan 2015 05:43:37 -0500 (EST) Message-ID: <54A67659.1070207@intertwingly.net> Date: Fri, 02 Jan 2015 05:43:37 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Julian Reschke , Graham Klyne References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> <54A66C73.7000508@gmx.de> In-Reply-To: <54A66C73.7000508@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_8P93Df70eHcB8sMzzHCWQ-qITU Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] URI parsing tests: userinfo handling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jan 2015 10:43:40 -0000 On 01/02/2015 05:01 AM, Julian Reschke wrote: > On 2015-01-01 20:08, Sam Ruby wrote: > > ... > > I have evidence that RFC 3986 doesn't match a variety of user agent >> behavior. Agents that aren't limited to browsers, but also to libraries >> that are used by what you would consider "middleware". >> >> Here is a filtered list of test results that only considers RFC 3986 >> valid URI references as inputs: >> >> https://url.spec.whatwg.org/interop/test-results/?filter=valid >> ... > > > So I'm now looking at the first valid entry with UA differences: > > > > which tests: > > http://user:pass@foo:21/bar;par?b#c > > This one is valid per the RFC 3986 ABNF and it contains a "userinfo" > component. > > RFC 3986: > > "...Use of the format "user:password" in the userinfo field is > deprecated. Applications should not render as clear text any data after > the first colon (":") character found within a userinfo subcomponent > unless the data after the colon is the empty string (indicating no > password). Applications may choose to ignore or reject such data when it > is received as part of a reference and should reject the storage of such > data in unencrypted form. The passing of authentication information in > clear text has proven to be a security risk in almost every case where > it has been used...." -- > > > RFC 7230: > > "The URI generic syntax for authority also includes a deprecated > userinfo subcomponent ([RFC3986], Section 3.2.1) for including user > authentication information in the URI. Some implementations make use of > the userinfo component for internal configuration of authentication > information, such as within command invocation options, configuration > files, or bookmark lists, even though such usage might expose a user > identifier or password. A sender MUST NOT generate the userinfo > subcomponent (and its "@" delimiter) when an "http" URI reference is > generated within a message as a request target or header field value. > Before making use of an "http" URI reference received from an untrusted > source, a recipient SHOULD parse for userinfo and treat its presence as > an error; it is likely being used to obscure the authority for the sake > of phishing attacks." -- > > > Looking at the test results suggests that > > a) only the Python implementation is really broken (it probably follows > RFC 2396 which treated params as a separate component; Firefox had a > similar problem until a few years ago; but that was fixed by me) FWIW, there was a problem with my script that captured test results, I wasn't capturing username and password, and this is now fixed: https://github.com/webspecs/url/commit/72b286722209771b4a18a53a3493c20e88d95736 But that is likely separate from what you are commenting on, namely the problem with an incomplete pathname. For Firefox, I had to visit the following page and then hit refresh before the data would show up in test-results page: https://url.spec.whatwg.org/interop/useragent-results/python > b) IE gets away with treating the presence of userinfo as an error; it > probably would be a good idea if other UAs followed that example. Thanks! This is exactly the type of discussion I am looking for. Please continue! There is an open bug on this issue: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27516 I've added a link to your message in that bug, and indicated that at a minimum, such usage should be considered a conformance error. On the test results page, you can filter by conforming URLs. This is a proper subset of set of URIs that are valid per the RFC 3986 ABNF. It is my hope that we can work together to define a set of conformance criteria which defines a set of URLs for which there is reasonable interop; even if that means changing specifications or implementations. > Best regards, Julian - Sam Ruby From nobody Fri Jan 2 04:20:20 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86B01A1A54 for ; Fri, 2 Jan 2015 04:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBYIihJUiSrz for ; Fri, 2 Jan 2015 04:20:16 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 1672F1A1A52 for ; Fri, 2 Jan 2015 04:20:16 -0800 (PST) Received: from [192.168.1.194] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LuJDv-1XfD0s45jD-011gcW; Fri, 02 Jan 2015 13:20:06 +0100 Message-ID: <54A68CEE.1060701@gmx.de> Date: Fri, 02 Jan 2015 13:19:58 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , Graham Klyne References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> <54A66C73.7000508@gmx.de> <54A67659.1070207@intertwingly.net> In-Reply-To: <54A67659.1070207@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:cVbCjwx8SF3DWHTzqvY/lNdmNfbsZOwfQcywt3CCp8AytpdkZ9X m4NYAQoNT8ZHxlmL25hgkQgDLe78h25+wWHGRaCwolGIpfbMK7yI65hqBa4WIx/JDLfWVkI 4Se1VlY5xr7KTNGSNLG5S9LOHzkRs4qRs0gHuOli7iqKlkW+cTDPFJKhpUOtOGy12y1aFXc fV6rP6CwYiLtQHljMiAWw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JO94Zw9piG648wy7ZLFELte5LgQ Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] URI parsing tests: userinfo handling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jan 2015 12:20:18 -0000 On 2015-01-02 11:43, Sam Ruby wrote: > On 01/02/2015 05:01 AM, Julian Reschke wrote: >> On 2015-01-01 20:08, Sam Ruby wrote: >> > ... >> > I have evidence that RFC 3986 doesn't match a variety of user agent >>> behavior. Agents that aren't limited to browsers, but also to libraries >>> that are used by what you would consider "middleware". >>> >>> Here is a filtered list of test results that only considers RFC 3986 >>> valid URI references as inputs: >>> >>> https://url.spec.whatwg.org/interop/test-results/?filter=valid >>> ... >> >> >> So I'm now looking at the first valid entry with UA differences: >> >> >> >> >> which tests: >> >> http://user:pass@foo:21/bar;par?b#c >> >> This one is valid per the RFC 3986 ABNF and it contains a "userinfo" >> component. >> >> RFC 3986: >> >> "...Use of the format "user:password" in the userinfo field is >> deprecated. Applications should not render as clear text any data after >> the first colon (":") character found within a userinfo subcomponent >> unless the data after the colon is the empty string (indicating no >> password). Applications may choose to ignore or reject such data when it >> is received as part of a reference and should reject the storage of such >> data in unencrypted form. The passing of authentication information in >> clear text has proven to be a security risk in almost every case where >> it has been used...." -- >> >> >> RFC 7230: >> >> "The URI generic syntax for authority also includes a deprecated >> userinfo subcomponent ([RFC3986], Section 3.2.1) for including user >> authentication information in the URI. Some implementations make use of >> the userinfo component for internal configuration of authentication >> information, such as within command invocation options, configuration >> files, or bookmark lists, even though such usage might expose a user >> identifier or password. A sender MUST NOT generate the userinfo >> subcomponent (and its "@" delimiter) when an "http" URI reference is >> generated within a message as a request target or header field value. >> Before making use of an "http" URI reference received from an untrusted >> source, a recipient SHOULD parse for userinfo and treat its presence as >> an error; it is likely being used to obscure the authority for the sake >> of phishing attacks." -- >> >> >> Looking at the test results suggests that >> >> a) only the Python implementation is really broken (it probably follows >> RFC 2396 which treated params as a separate component; Firefox had a >> similar problem until a few years ago; but that was fixed by me) > > FWIW, there was a problem with my script that captured test results, I > wasn't capturing username and password, and this is now fixed: > > https://github.com/webspecs/url/commit/72b286722209771b4a18a53a3493c20e88d95736 > > > But that is likely separate from what you are commenting on, namely the > problem with an incomplete pathname. > ... FWIW, it could also be an incorrect use of Python's urllib.parse () which is documented to extract the last path segment's parameter as a separate component. So test code will need to properly reconstruct the path with that information. > ... Best regards, Julian From nobody Fri Jan 2 05:18:09 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258211A1B79 for ; Fri, 2 Jan 2015 05:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPqDpBT_RYY9 for ; Fri, 2 Jan 2015 05:18:05 -0800 (PST) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB471A1B67 for ; Fri, 2 Jan 2015 05:18:05 -0800 (PST) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Y7279-0004O2-gh; Fri, 02 Jan 2015 13:18:03 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Y7279-0001Fb-Jc; Fri, 02 Jan 2015 13:18:03 +0000 Message-ID: <54A69A9C.8000504@ninebynine.org> Date: Fri, 02 Jan 2015 13:18:20 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John C Klensin , "Murray S. Kucherawy" References: <54A5763C.5060203@ninebynine.org> <54A58B8C.1020504@ninebynine.org> <7C8B88E445D0C503F738E99A@[192.168.1.128]> In-Reply-To: <7C8B88E445D0C503F738E99A@[192.168.1.128]> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/5n5qPn6ytDbhZhf05uOX_YOPfqI Cc: IETF Apps Discuss , Larry Masinter Subject: Re: [apps-discuss] Call for Adoption: draft-kerwin-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jan 2015 13:18:07 -0000 On 01/01/2015 18:15, John C Klensin wrote: > > > --On Thursday, 01 January, 2015 18:01 +0000 Graham Klyne > wrote: > >> ... >> For me, the real value in moving towards a consensus >> specification for file: URIs is that it would provide a common >> file naming framework for software libraries that unify local >> and web access to resources. The capability is substantially >> achievable today based on the available and informal >> specifications, but there are a number of problematic edge >> cases (like Windows drive letters) that can cause interop >> problems. > > Of course, the more we move in the direction of what sounds to > me like a desire to use "file:" to reference resources that may > be either local or remote ("web access"), potentially with > multiple web locations, the closer we get to "file:" meeting the > design criteria of persistence and location-independence that > characterize URNs. Hmmm. I'm not sure I see this. I think file: URIs are still location dependent, but the location may depend on the context of use rather than the URI string alone. (To clarify: I have used file: for local resources and http: for remote resources, so not expecting to use file: for both.) What I was referring to was writing software that can handle local and remote resources through a common interface, using URIs as an over-arching scheme for referencing both. I've worked on applications that using implementation of this idea over the past couple of years, so its not a new capability - just not (yet) very portable. #g -- > > I'm not commenting right now on whether I think that would be > good or bad (not sure I even have an opinion given how widely > things that appear to be URIs with a scheme of "file" are used), > but these waters are muddy already and I think that, if we > decide to muddy them further, it should be with our eyes open. > > john > From nobody Fri Jan 2 05:30:16 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CF01A8750; Fri, 2 Jan 2015 05:30:14 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gThXZzqoxftp; Fri, 2 Jan 2015 05:30:13 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 4AA941A1B43; Fri, 2 Jan 2015 05:30:13 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DF63222E265; Fri, 2 Jan 2015 08:30:11 -0500 (EST) Message-ID: <54A69D2D.3010309@seantek.com> Date: Fri, 02 Jan 2015 05:29:17 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: arcmedia@ietf.org, IETF Apps Discuss References: <54A41D6C.9010501@ninebynine.org> <54A45FBD.1070701@dcrocker.net> In-Reply-To: <54A45FBD.1070701@dcrocker.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6Er3Hgp4ySwNevwlSxMbLNBzvcI Subject: Re: [apps-discuss] [arcmedia] Proposed charter for arcmedia X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jan 2015 13:30:15 -0000 Hello all and Happy New Year. Sorry that I didn't respond to this thread = earlier--a lot going on with the holidays. I looked at=20 just=20 now, which I assume is the latest. On 12/31/2014 12:42 PM, Dave Crocker wrote: >> its initial input. It will specify rules for registering subtypes >> under that new top-level type. All of the usual things will be >> considered, including type suffixes, fragment identifiers, and >> internationalization. > Replace sentence with: > > The rules will at least include consideration of type suffixes, > fragment identifiers, and internationalization. Yes, please include this text. (It's not in yet.) With all respect to the W3C TAG work, I find the TAG stuff inapposite.=20 Perhaps it should be considered, but it should carry less weight than=20 formats that already exist and are in widespread use. These formats inclu= de: ZIP TAR family RAR SIT (StuffIt) 7-Zip / LZMA Disk-Image Formats, including DMG, ISO 9660, WIM, VMDK I think that at least a couple more formats should be mentioned by name; = ISO 9660 for example (seeing as how it is an SDO-based format). I understand the point of TAG, but it doesn't seem much different in=20 spirit, scope, or technical details to MHTML=20 =20 , except maybe the fragment=20 identifier stuff. In any event, TAG packages and MHTML are not *file*=20 archive formats per-se; they are ways of bundling web content (with the=20 headers and URI references) into one stream, much like message/rfc822.=20 It would seem more appropriate for TAG packages to be classified under=20 message/* or multipart/*. Indeed it looks completely feasible to fold=20 TAG packages into RFC 2557 and RFC 2387 (multipart/related) with=20 Content-Type: multipart/related; type=3D"text/w3c-package-directory". The= =20 root part would just be a flat text file with separators, basically=20 being the directory of the parts (since one complaint about the ZIP=20 format is that the directory is at the end). If the boundary parameter=20 requirement of "multipart"is too burdensome (a dubious assertion IMO),=20 the format can be classified with message/* instead. The statement "No other work is in scope for this working group" is not=20 necessary IMO. If it is not in the approved charter, is is out-of-scope=20 by definition. Cheers, Sean From nobody Fri Jan 2 05:31:33 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2009C1A1B43 for ; Fri, 2 Jan 2015 05:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzYe9cILaInS for ; Fri, 2 Jan 2015 05:31:30 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.230]) by ietfa.amsl.com (Postfix) with ESMTP id 17F0A1A0399 for ; Fri, 2 Jan 2015 05:31:30 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:11070] helo=rubix) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 5A/AB-27763-1BD96A45; Fri, 02 Jan 2015 13:31:29 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id A4732140D1E; Fri, 2 Jan 2015 08:31:28 -0500 (EST) Message-ID: <54A69DB0.7010001@intertwingly.net> Date: Fri, 02 Jan 2015 08:31:28 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Julian Reschke , Graham Klyne References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> <54A66C73.7000508@gmx.de> <54A67659.1070207@intertwingly.net> <54A68CEE.1060701@gmx.de> In-Reply-To: <54A68CEE.1060701@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mje69RTUFyeiC_H9eOf-3_0SMXQ Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] URI parsing tests: userinfo handling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jan 2015 13:31:32 -0000 On 01/02/2015 07:19 AM, Julian Reschke wrote: > On 2015-01-02 11:43, Sam Ruby wrote: >> On 01/02/2015 05:01 AM, Julian Reschke wrote: >>> On 2015-01-01 20:08, Sam Ruby wrote: >>> > ... >>> > I have evidence that RFC 3986 doesn't match a variety of user agent >>>> behavior. Agents that aren't limited to browsers, but also to >>>> libraries >>>> that are used by what you would consider "middleware". >>>> >>>> Here is a filtered list of test results that only considers RFC 3986 >>>> valid URI references as inputs: >>>> >>>> https://url.spec.whatwg.org/interop/test-results/?filter=valid >>>> ... >>> >>> >>> So I'm now looking at the first valid entry with UA differences: >>> >>> >>> >>> >>> >>> which tests: >>> >>> http://user:pass@foo:21/bar;par?b#c >>> >>> This one is valid per the RFC 3986 ABNF and it contains a "userinfo" >>> component. >>> >>> RFC 3986: >>> >>> "...Use of the format "user:password" in the userinfo field is >>> deprecated. Applications should not render as clear text any data after >>> the first colon (":") character found within a userinfo subcomponent >>> unless the data after the colon is the empty string (indicating no >>> password). Applications may choose to ignore or reject such data when it >>> is received as part of a reference and should reject the storage of such >>> data in unencrypted form. The passing of authentication information in >>> clear text has proven to be a security risk in almost every case where >>> it has been used...." -- >>> >>> >>> RFC 7230: >>> >>> "The URI generic syntax for authority also includes a deprecated >>> userinfo subcomponent ([RFC3986], Section 3.2.1) for including user >>> authentication information in the URI. Some implementations make use of >>> the userinfo component for internal configuration of authentication >>> information, such as within command invocation options, configuration >>> files, or bookmark lists, even though such usage might expose a user >>> identifier or password. A sender MUST NOT generate the userinfo >>> subcomponent (and its "@" delimiter) when an "http" URI reference is >>> generated within a message as a request target or header field value. >>> Before making use of an "http" URI reference received from an untrusted >>> source, a recipient SHOULD parse for userinfo and treat its presence as >>> an error; it is likely being used to obscure the authority for the sake >>> of phishing attacks." -- >>> >>> >>> Looking at the test results suggests that >>> >>> a) only the Python implementation is really broken (it probably follows >>> RFC 2396 which treated params as a separate component; Firefox had a >>> similar problem until a few years ago; but that was fixed by me) >> >> FWIW, there was a problem with my script that captured test results, I >> wasn't capturing username and password, and this is now fixed: >> >> https://github.com/webspecs/url/commit/72b286722209771b4a18a53a3493c20e88d95736 >> >> But that is likely separate from what you are commenting on, namely the >> problem with an incomplete pathname. >> ... > > FWIW, it could also be an incorrect use of Python's urllib.parse > () which is > documented to extract the last path segment's parameter as a separate > component. So test code will need to properly reconstruct the path with > that information. I'm inclined to think otherwise as Python's implementation treats the ';' as a delimiter and not a part of the path. As an example, the following two calls produce identical results: urlparse('http://foo/a/b') urlparse('http://foo/a/b;') - Sam Ruby From nobody Fri Jan 2 05:44:57 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE461A86EC for ; Fri, 2 Jan 2015 05:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUbcv29SXZSa for ; Fri, 2 Jan 2015 05:44:53 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 1924D1A3BA6 for ; Fri, 2 Jan 2015 05:44:52 -0800 (PST) Received: from [192.168.1.194] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M1WHV-1Xrr824B33-00tQAy; Fri, 02 Jan 2015 14:44:40 +0100 Message-ID: <54A6A0C0.4020405@gmx.de> Date: Fri, 02 Jan 2015 14:44:32 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , Graham Klyne References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> <54A66C73.7000508@gmx.de> <54A67659.1070207@intertwingly.net> <54A68CEE.1060701@gmx.de> <54A69DB0.7010001@intertwingly.net> In-Reply-To: <54A69DB0.7010001@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:v93X9m7MlldMdOB27vERQ/r0o3rwRJ4sN4RNHH+auN8h1nnd3gs lw6cxMKtFn+6RDEpLNQrIT/sp8fRF1ERFs1L6NudY8FSMFtdYeS0JlNqQ5yNT0FfkzPtv64 KM6PiyNPMk+6b9eh3Uz9ssR+9LYj5qUf+MC+SCqZCkbHSzMaxC5vEys+JYS+KFR2+W8Leb3 63ymivRNHybaAFOEF/STg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/eH-nmGX493KyeJ0l32k_99djXBU Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] URI parsing tests: userinfo handling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jan 2015 13:44:55 -0000 On 2015-01-02 14:31, Sam Ruby wrote: > > > On 01/02/2015 07:19 AM, Julian Reschke wrote: >> On 2015-01-02 11:43, Sam Ruby wrote: >>> On 01/02/2015 05:01 AM, Julian Reschke wrote: >>>> On 2015-01-01 20:08, Sam Ruby wrote: >>>> > ... >>>> > I have evidence that RFC 3986 doesn't match a variety of user agent >>>>> behavior. Agents that aren't limited to browsers, but also to >>>>> libraries >>>>> that are used by what you would consider "middleware". >>>>> >>>>> Here is a filtered list of test results that only considers RFC 3986 >>>>> valid URI references as inputs: >>>>> >>>>> https://url.spec.whatwg.org/interop/test-results/?filter=valid >>>>> ... >>>> >>>> >>>> So I'm now looking at the first valid entry with UA differences: >>>> >>>> >>>> >>>> >>>> >>>> >>>> which tests: >>>> >>>> http://user:pass@foo:21/bar;par?b#c >>>> >>>> This one is valid per the RFC 3986 ABNF and it contains a "userinfo" >>>> component. >>>> >>>> RFC 3986: >>>> >>>> "...Use of the format "user:password" in the userinfo field is >>>> deprecated. Applications should not render as clear text any data after >>>> the first colon (":") character found within a userinfo subcomponent >>>> unless the data after the colon is the empty string (indicating no >>>> password). Applications may choose to ignore or reject such data >>>> when it >>>> is received as part of a reference and should reject the storage of >>>> such >>>> data in unencrypted form. The passing of authentication information in >>>> clear text has proven to be a security risk in almost every case where >>>> it has been used...." -- >>>> >>>> >>>> RFC 7230: >>>> >>>> "The URI generic syntax for authority also includes a deprecated >>>> userinfo subcomponent ([RFC3986], Section 3.2.1) for including user >>>> authentication information in the URI. Some implementations make use of >>>> the userinfo component for internal configuration of authentication >>>> information, such as within command invocation options, configuration >>>> files, or bookmark lists, even though such usage might expose a user >>>> identifier or password. A sender MUST NOT generate the userinfo >>>> subcomponent (and its "@" delimiter) when an "http" URI reference is >>>> generated within a message as a request target or header field value. >>>> Before making use of an "http" URI reference received from an untrusted >>>> source, a recipient SHOULD parse for userinfo and treat its presence as >>>> an error; it is likely being used to obscure the authority for the sake >>>> of phishing attacks." -- >>>> >>>> >>>> Looking at the test results suggests that >>>> >>>> a) only the Python implementation is really broken (it probably follows >>>> RFC 2396 which treated params as a separate component; Firefox had a >>>> similar problem until a few years ago; but that was fixed by me) >>> >>> FWIW, there was a problem with my script that captured test results, I >>> wasn't capturing username and password, and this is now fixed: >>> >>> https://github.com/webspecs/url/commit/72b286722209771b4a18a53a3493c20e88d95736 >>> >>> >>> But that is likely separate from what you are commenting on, namely the >>> problem with an incomplete pathname. >>> ... >> >> FWIW, it could also be an incorrect use of Python's urllib.parse >> () which is >> documented to extract the last path segment's parameter as a separate >> component. So test code will need to properly reconstruct the path with >> that information. > > I'm inclined to think otherwise as Python's implementation treats the > ';' as a delimiter and not a part of the path. As an example, the > following two calls produce identical results: > > urlparse('http://foo/a/b') > urlparse('http://foo/a/b;') Actually I was wrong; special handling of parameters dates back to RFC 1808 and was removed in RFC 2396, see : > :///;?# So this is what these implementations try to do. To reconstruct the path, given that API, you'll need to re-append the params. And yes, the problem with Python's implementation probably is that you can't distinguish an empty params component from absence of that component. This should be raised as a bug report against the Python libraries. (My point being that this -- when properly used -- affects only the edge case of a path ending in a ";") Best regards, Julian From nobody Fri Jan 2 05:52:14 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB9D1A8743 for ; Fri, 2 Jan 2015 05:52:12 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwM6rh7ETfA2 for ; Fri, 2 Jan 2015 05:52:11 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 E52EA1A3BA6 for ; Fri, 2 Jan 2015 05:52:10 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8E5D722E265; Fri, 2 Jan 2015 08:52:09 -0500 (EST) Message-ID: <54A6A253.2050306@seantek.com> Date: Fri, 02 Jan 2015 05:51:15 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: IETF Apps Discuss References: <54A5763C.5060203@ninebynine.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ohXaLwxDvBo5Ido9yN3sYdf4Y8M Cc: Graham Klyne , Larry Masinter Subject: Re: [apps-discuss] Call for Adoption: draft-kerwin-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jan 2015 13:52:13 -0000 On 1/1/2015 9:20 AM, Murray S. Kucherawy wrote: > On Thu, Jan 1, 2015 at 8:30 AM, Graham Klyne > wrote: > > In the case of file:, I have no doubt that the scheme is both > widely supported and widely used. The problems with the current > specification have been widely discussed, over a long period. But > I would have reservations about permanent registration if there is > no clear community consensus about how the scheme may be used or > is expected to function. > > > [...] > > Can I take this to mean that as wide adoption increases, [...an RFC > should result...] Let's be clear about file: URI. The file scheme *is* permanently registered in the URI Schemes database . The reference is RFC 1738 (December 1994). Until this or any other document supplants it, RFC 1738 is in force. The full text of RFC 1738 is: The file URL scheme is used to designate files accessible on a particular host computer. This scheme, unlike most other URL schemes, does not designate a resource that is universally accessible over the Internet. A file URL takes the form: file:/// where is the fully qualified domain name of the system on which the is accessible, and is a hierarchical directory path of the form //.../. For example, a VMS file DISK$USER:[MY.NOTES]NOTE123456.TXT might become As a special case, can be the string "localhost" or the empty string; this is interpreted as `the machine from which the URL is being interpreted'. The file URL scheme is unusual in that it does not specify an Internet protocol or access method for such files; as such, its utility in network protocols between hosts is limited. It's short, sweet, and to the point. Sure it leaves a lot unspecified, but short = less to argue about. :) Does anyone take issue with the RFC 1738 text? Sean From nobody Fri Jan 2 05:55:09 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5501A872D for ; Fri, 2 Jan 2015 05:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwYFUjVOxglN for ; Fri, 2 Jan 2015 05:55:04 -0800 (PST) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA8B1A3BA6 for ; Fri, 2 Jan 2015 05:55:04 -0800 (PST) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Y72gx-0007ez-i6; Fri, 02 Jan 2015 13:55:03 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Y72gx-0003rQ-ES; Fri, 02 Jan 2015 13:55:03 +0000 Message-ID: <54A6A347.3080808@ninebynine.org> Date: Fri, 02 Jan 2015 13:55:19 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <54A5763C.5060203@ninebynine.org> <54A58B8C.1020504@ninebynine.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Zb1P9MoytU6rpa53qH_KRCTPw3o Cc: IETF Apps Discuss , Larry Masinter Subject: Re: [apps-discuss] Call for Adoption: draft-kerwin-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jan 2015 13:55:06 -0000 On 01/01/2015 18:17, Murray S. Kucherawy wrote: > Actually, my question was more general, and not specific to this particular > document. I'll rephrase: > > Can I take this to mean that, as wide adoption of a given a scheme (or > media type, though I know that's not what you review) increases, your > expectation of community discussion and possibly even RFC publication > defining that scheme also increases? Ah, thanks, I think I get your question now :) Short answer: No (or not specifically). Longer answer: My reference to "adoption" as well as "consensus" is a recognition that, where there are non-standardized URI schemes out there in the wild which are widely used, and which are not otherwise controversial, it is probably appropriate per the "utility" requirement to include them in the permanent registry. But I still have a preference for seeing RFC publication, or open standard publication, as that provides some evidence of "clear utility to the broad Internet community" [http://tools.ietf.org/html/rfc4395#section-2.1]. Absent that, I will look for, or ask for, other indicators, such as widespread adoption. #g -- From nobody Fri Jan 2 06:26:59 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447B51A874F for ; Fri, 2 Jan 2015 06:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiWRjtR-geql for ; Fri, 2 Jan 2015 06:26:56 -0800 (PST) Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) by ietfa.amsl.com (Postfix) with ESMTP id 060831A874E for ; Fri, 2 Jan 2015 06:26:55 -0800 (PST) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Y73Bm-0003xm-d8; Fri, 02 Jan 2015 14:26:54 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Y73Bl-0002cp-MG; Fri, 02 Jan 2015 14:26:54 +0000 Message-ID: <54A6AABF.4060406@ninebynine.org> Date: Fri, 02 Jan 2015 14:27:11 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> In-Reply-To: <54A59B26.5000408@intertwingly.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Uv07xazoIayK0svHOQ9TtDiIK7Y Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jan 2015 14:26:58 -0000 On 01/01/2015 19:08, Sam Ruby wrote: >>> https://mailarchive.ietf.org/arch/msg/apps-discuss/KyxFLw2FCwv7CSpiWAmLr8Ha7vc >> >> This raises two points for me: >> >> 1. 'file: should be seen as an "escape hatch"'. >> >> I disagree. For me, the value of file: URIs is to provide a file naming >> structure that can be used in libraries that unify local and web access >> to resources. So I think it's important that file: URIs follow common >> URI syntax and resolution mechanisms, even if their interpretation for >> the purposes of dereferencing, etc., is defined locally. >> >> (This is not to impose "normative statements on OS vendors for their own >> software" - unless the vendors choose to use URIs natively for file >> naming.) > > I'll contrast "can be used in libraries that..." (immediately above), and "works > for everyone" (previous point). > > If the intent of draft-kerwin-file-scheme is only to be valid in a subset of > libraries, then it should say so. If it is intended to also match other user > agent behaviors (e.g. browsers), then we collectively have considerably more > work to do. I never made that claim. I also think it is not the role of the URI spec to describe "agent behaviour" (beyond relative reference resolution, if that is a "behaviour"). I think it is the role of the URI spec to: (a) define what constitutes a valid URI, and URI reference, and (b) describe how to combine a valid base URI with a valid URI reference to yield a valid resulting URI. Which is, of course, what RFC3986 does (how well is up for discussion). I fully accept that there may be desirable agent behaviours that are not covered here, and that an additional document may be desired to describe these, particularly where the behaviours impact interoperability. > >> 2. Use of vendor-specific documentation >> >> I agree with this, specifically: "The right way ... is to write the RFC >> in such a way that OS-specific variations are not required for >> RFC-compliance in the first place" >> >> So it's clear to me that there are aspects of file: URI handling that >> are local-context dependent (e.g. how to actually dereference). But I >> think other activities (such as relative reference resolution should be >> possible without regard to the underlying file system implementation - >> and this is the level of commonality that a file: URI scheme RFC should >> aim to provide. > > I'll note that draft-kerwin-file-scheme includes such constructs as windows-path > and unc-path. Sure, but I'm not sure what point you're making here. I would want to see all such system-specific forms conform to standard URI syntax, and to yield the desired results when resolved using a standard resolution algorithm. >>> It is my hope that by working together I can feel confident enough to >>> remove >>> that red box. As it is, I don't feel that either spec matches widely >>> deployed >>> applications. >> >> Fair enough. Which suggests to me that focusing on a single focused >> spec and aligning around that might be a productive way to tackle this. > > What I am focused on is the following question: what should a "URI.parse" method > do? In some ways that question is more general (in that is isn't file: scheme > specific). In some ways that question is more focused (in that it doesn't > attempt to describe the operating system specific interpretations of the results). For me, the question of what URI.parse *does* goes beyond what the core URI spec needs to define. But I agree about operating system specific behaviours of file: URIs being outside the desirable scope of that core spec. > >>
--001a1134cd58381aad050bc3ff69-- From nobody Sat Jan 3 10:56:58 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEEF1A00F5 for ; Sat, 3 Jan 2015 10:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzwECofDr7_Z for ; Sat, 3 Jan 2015 10:56:54 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C8C11A007B for ; Sat, 3 Jan 2015 10:56:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 85746BF02; Sat, 3 Jan 2015 18:56:52 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moLm5IWfjF59; Sat, 3 Jan 2015 18:56:51 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.26.8]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 09463BEF4; Sat, 3 Jan 2015 18:56:51 +0000 (GMT) Message-ID: <54A83B72.4010106@cs.tcd.ie> Date: Sat, 03 Jan 2015 18:56:50 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , Graham Klyne References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> <54A6AABF.4060406@ninebynine.org> <54A6B6DF.1010206@intertwingly.net> <54A7DC46.2020708@ninebynine.org> <54A7E9F4.80406@intertwingly.net> <54A820EA.20200@ninebynine.org> <54A82CC4.9080606@intertwingly.net> In-Reply-To: <54A82CC4.9080606@intertwingly.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Pzatcrf6ydVR6KYmHtJJ9DcQPAc Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] presumption that RFC3986 is correct X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jan 2015 18:56:57 -0000 Hi Sam, On 03/01/15 17:54, Sam Ruby wrote: > > I intend to work with implementors, providing patches and/or new > implementations along the way. And I'll continue to document and > publish findings. One such place I have published such work is at the > W3C: > > http://www.w3.org/TR/url/ I have at least one question about how you (or W3C, or any of us) plan to head towards some reasonable level of completeness with that work. (This may be a bit of an aside in the current discussion, or maybe not, I'm not sure.) The draft at the URL above includes [1], which is a risibly small and fixed (?) subset of an IANA registry. [2] What's the plan for making that sensible? I would assume pointing at the IANA registry is the simple and obvious fix there, but am puzzled as to why that hasn't been done in the few years this text has been around. Is that just an oversight? Or is your work really only covering exactly that particular subset of schemes? Or something else? Thanks, S. [1] http://www.w3.org/TR/url/#relative-scheme [2] https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml From nobody Sat Jan 3 11:18:14 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CD01A011F for ; Sat, 3 Jan 2015 11:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4P3QNtFPynNl for ; Sat, 3 Jan 2015 11:18:11 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1CAC1A011D for ; Sat, 3 Jan 2015 11:18:11 -0800 (PST) Received: (qmail 998 invoked from network); 3 Jan 2015 19:18:10 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 3 Jan 2015 19:18:10 -0000 Date: 3 Jan 2015 19:17:48 -0000 Message-ID: <20150103191748.19958.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <54A830A8.8090601@seantek.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kgCGTGbUoaY0Uqc5ojTm5qEB3c0 Subject: Re: [apps-discuss] [arcmedia] Proposed charter for arcmedia X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jan 2015 19:18:13 -0000 >Here's a diff, and the changed text. >(Not sure if it will be accepted by the IETF mailing list...guess we're >about to find out) I'm with Murray. It seems harmless but pointless. One the things a WG will have to do is to figure out what counts as an archive data format. If you want us to consider ISO 9660, I want us to consider ANSI INCITS 27. R's, John From nobody Sat Jan 3 11:25:27 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7144C1A00BE; Sat, 3 Jan 2015 11:25:25 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGGNa_UpVfeT; Sat, 3 Jan 2015 11:25:24 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 1526A1A0055; Sat, 3 Jan 2015 11:25:24 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 045E922E260; Sat, 3 Jan 2015 14:25:16 -0500 (EST) Message-ID: <54A841E0.7070306@seantek.com> Date: Sat, 03 Jan 2015 11:24:16 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John Levine , apps-discuss@ietf.org, "arcmedia@ietf.org" References: <20150103191748.19958.qmail@ary.lan> In-Reply-To: <20150103191748.19958.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3pxYEMaREc7lDdhaCRI2kXXlYSQ Subject: Re: [apps-discuss] [arcmedia] Proposed charter for arcmedia X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jan 2015 19:25:25 -0000 On 1/3/2015 11:17 AM, John Levine wrote: >> Here's a diff, and the changed text. >> (Not sure if it will be accepted by the IETF mailing list...guess we'r= e >> about to find out) > I'm with Murray. It seems harmless but pointless. One the things a WG= > will have to do is to figure out what counts as an archive data format.= > If you want us to consider ISO 9660, I want us to consider ANSI INCITS = 27. If it's used in regular commerce on the Internet, I don't have a problem = with ANSI INCITS 27. But I think your suggestion is a bit tongue-in-cheeck. .iso files are=20 *everywhere* on the Internet, and can contain payloads that seriously=20 affect the security of Internet-connected systems. I believe there is a=20 certain popular website out there just dedicated to "hunting" for them.=20 And to-date it still doesn't have a media type. A few e-mails back, it was stated that "No other work is in scope for=20 this working group" [except what's in the charter]. So the natural=20 evolution is to be sure that the charter includes everything that should = be in-scope. Sean From nobody Sat Jan 3 11:36:16 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458CB1A0055 for ; Sat, 3 Jan 2015 11:36:15 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ms088jPyrxa for ; Sat, 3 Jan 2015 11:36:13 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 A73421A0058 for ; Sat, 3 Jan 2015 11:36:13 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 942FD22E261 for ; Sat, 3 Jan 2015 14:36:12 -0500 (EST) Message-ID: <54A84470.1000909@seantek.com> Date: Sat, 03 Jan 2015 11:35:12 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> <54A6AABF.4060406@ninebynine.org> <54A6B6DF.1010206@intertwingly.net> <54A7DC46.2020708@ninebynine.org> <54A7E9F4.80406@intertwingly.net> <54A820EA.20200@ninebynine.org> <54A82CC4.9080606@intertwingly.net> <54A83B72.4010106@cs.tcd.ie> In-Reply-To: <54A83B72.4010106@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/AkHbg2ehQZjQNOeFXn1Im1ue1EI Subject: Re: [apps-discuss] presumption that RFC3986 is correct X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jan 2015 19:36:15 -0000 On 1/3/2015 10:56 AM, Stephen Farrell wrote: > Hi Sam, > > On 03/01/15 17:54, Sam Ruby wrote: >> I intend to work with implementors, providing patches and/or new >> implementations along the way. And I'll continue to document and >> publish findings. One such place I have published such work is at the >> W3C: >> >> http://www.w3.org/TR/url/ > I have at least one question about how you (or W3C, or any of us) > plan to head towards some reasonable level of completeness with > that work. (This may be a bit of an aside in the current discussion, > or maybe not, I'm not sure.) > > The draft at the URL above includes [1], which is a risibly small > and fixed (?) subset of an IANA registry. [2] What's the plan for > making that sensible? I would assume pointing at the IANA registry > is the simple and obvious fix there, but am puzzled as to why that > hasn't been done in the few years this text has been around. +1 Yeah man, just use the IANA registry... Sean From nobody Sat Jan 3 12:07:18 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EB21A0040 for ; Sat, 3 Jan 2015 12:07:16 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcg3IRSKTAs5 for ; Sat, 3 Jan 2015 12:07:12 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 6FD121A000F for ; Sat, 3 Jan 2015 12:07:12 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5824922E25F for ; Sat, 3 Jan 2015 15:07:11 -0500 (EST) Message-ID: <54A84BB3.1050702@seantek.com> Date: Sat, 03 Jan 2015 12:06:11 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> <54A6AABF.4060406@ninebynine.org> <54A6B6DF.1010206@intertwingly.net> <54A7DC46.2020708@ninebynine.org> In-Reply-To: <54A7DC46.2020708@ninebynine.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/B5HHVrGbWuck4yKmBJCAqOXCjCI Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jan 2015 20:07:16 -0000 Basically this entire reply is a big +1 in the hopes of converging on=20 consensus and moving onwards. On 1/3/2015 4:10 AM, Graham Klyne wrote: > Sam, > > Rather than continue the blow-by-blow exchange of points, let me try=20 > and respond in one place where I think we stand: > > > 1. I agree that draft-kerwin-file-scheme *should* work for everyone. =20 > And that probably means reducing the scope of anything there that may=20 > be considered normative. +1 > > But I also believe it can be useful to document other behaviours=20 > *informatively*. I think this is discussed elsewhere and anticipate=20 > evolution in this direction. This could mean, to develop your=20 > example, describing Microsoft Windows specific behaviours without any=20 > expectation that such behaviours would be implemented by Apple. +=BD As I have stated previously, I do not believe that a Standards-Track RFC = on this topic should enumerate local forms (i.e., Windows vs. Mac OS X=20 vs. VMS vs. whatever). But informative text does not seem harmful to me. > > > 2. I think our disagreement may lie primarily in the area of what=20 > should be the scope of RFC 3986 or its successor. There is (I claim)=20 > a substantial developer community who are familiar with RFC3986 as it=20 > stands, and creating a new document to cover the same material with=20 > enlarged scope is unnecessary and disruptive. The additional scope=20 > coverage could be in a new document that builds upon what RFC3986 does = > specify. > > Part of this disagreement is that I don't think the URI core spec=20 > needs to describe the operation of splitting a URI into its=20 > components. (I regard https://tools.ietf.org/html/rfc3986#appendix-B=20 > as merely informative.) The syntax specification is sufficient to=20 > associate substrings of a well-formed URI with named syntax productions= =2E +1 > > I also think the core URI spec should not be describing how to turn = > non-URI strings (some of which may be system-dependent forms) into=20 > valid URIs. (Except URI-references, which are covered by the=20 > resolution specification.) +1 > > > 3. Where there is divergence between implementations and RFC3986,=20 > these indeed should be considered on a case-by-case basis, but with=20 > (IMO) the presumption that RFC3986 is correct. I.e. it is for those=20 > who think there is a problem with RFC3986 to make the case. +1 > > You ask me to spend time with your data. That's a big ask. If=20 > some implementers think there is a problem with RFC 3986 then I think=20 > it is they who should be making the specific arguments about where=20 > RFC3986 is problematic. I accept that UTS-46 host names is such an=20 > area, concerning which there should be a considered and focused debate = > (and about which I have insufficient knowledge to make a meaningful=20 > contribution). +1. UTS-46 host names shouldn't affect the file: scheme any differently=20 than anything else. > > > 4. I agree with your point about qualifying my statement about=20 > system-dependent forms conforming to core URI syntax. While forms=20 > such as "C:\Program Files (x86)" might be described as variations, I=20 > don't think they should be considered to be valid URIs. > > I'm supportive of the strategy you outline (repeated here for ease of=20 > reference), which I don't think is so different from what I've argued=20 > for: > > [[ > A strategy that is more likely to be successful would be to identify=20 > URIs as being completely system independent, and URLs as being mostly=20 > system independent, and for there to be a well known and documented=20 > mechanism for converting from URLs to URIs. Even that is not likely=20 > to be completely achieved -- the conversion may end up being (at least = > partially) system dependent, but in such cases we should be able to=20 > define the problematic set of the inputs as non-conforming. > ]] > --=20 > https://mailarchive.ietf.org/arch/msg/apps-discuss/lNsLrE3xDYpo2GyvgHzG= GZv-PLI +1 > > Where I may diverge is that I don't think the "well known and=20 > documented mechanism for converting from URLs to URIs" should be part=20 > of the URI specification (cf. my point 2 above). +1 it's a local convention issue > > > 5. The previous point also begs the question of what should be covered = > by the file: scheme document. I think it may be appropriate to=20 > describe some commonly occurring system-dependent file: URL forms, but = > I'm less convinced that this is the place to describe how to map them=20 > to URIs. Any normative specification of file: URI formats should be=20 > restricted to forms that comply fully with RFC3986. +1 There could be some value in having a "normative" file: URI=20 format...which if anything, probably means that it is: file://{HOST}/{root stuff}/{directories...}/{filename} In an abstract non-system-specific way, that fully complies with RFC 3986= =2E Individual systems (Windows, Mac OS) can have other forms (e.g., \=20 [which doesn't comply with 3986 and thus is not a URI] or : [which does=20 comply and therefore is a URI, but isn't analyzable in the 3986=20 p-component way]), and those other forms are acceptable for their use,=20 but they aren't the "normative" form (whether or not they are "URIs")=20 and that's okay. The end. Sean From nobody Sat Jan 3 12:46:07 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB82F1A0263 for ; Sat, 3 Jan 2015 12:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNNsgqeNg7jV for ; Sat, 3 Jan 2015 12:46:05 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2111A024C for ; Sat, 3 Jan 2015 12:46:05 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:45039] helo=rubix) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 27/00-08196-B0558A45; Sat, 03 Jan 2015 20:46:04 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 0E971140128; Sat, 3 Jan 2015 15:46:03 -0500 (EST) Message-ID: <54A8550A.1020708@intertwingly.net> Date: Sat, 03 Jan 2015 15:46:02 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Stephen Farrell References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> <54A6AABF.4060406@ninebynine.org> <54A6B6DF.1010206@intertwingly.net> <54A7DC46.2020708@ninebynine.org> <54A7E9F4.80406@intertwingly.net> <54A820EA.20200@ninebynine.org> <54A82CC4.9080606@intertwingly.net> <54A83B72.4010106@cs.tcd.ie> In-Reply-To: <54A83B72.4010106@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/FtsMkGHsIWqxCoSbgeCCp3qiEpY Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] presumption that RFC3986 is correct X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jan 2015 20:46:07 -0000 On 01/03/2015 01:56 PM, Stephen Farrell wrote: > > Hi Sam, > > On 03/01/15 17:54, Sam Ruby wrote: >> >> I intend to work with implementors, providing patches and/or new >> implementations along the way. And I'll continue to document and >> publish findings. One such place I have published such work is at the >> W3C: >> >> http://www.w3.org/TR/url/ > > I have at least one question about how you (or W3C, or any of us) > plan to head towards some reasonable level of completeness with > that work. (This may be a bit of an aside in the current discussion, > or maybe not, I'm not sure.) > > The draft at the URL above includes [1], which is a risibly small > and fixed (?) subset of an IANA registry. [2] What's the plan for > making that sensible? I would assume pointing at the IANA registry > is the simple and obvious fix there, but am puzzled as to why that > hasn't been done in the few years this text has been around. > > Is that just an oversight? Or is your work really only covering > exactly that particular subset of schemes? Or something else? This is a valid question, and the subject of an open bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27233 So the short answer is: it is a known issue, and suggestions are welcome. The longer answer isn't all that much longer. Given that every modern programming language (and for that matter, every browser) will have a part of their runtime library a concept of either a URI or a URL, and a method to parse a string into such a structure, the question you pose is equivalent to: "how should URI.parse methods handle unknown schemes"? Possible answers include: treat the content as hierarchical, and treat the content as opaque. There may be other answers. What there probably needs to be is a sane default, and a way to register new schemes. At the moment, the URL Working Draft treats unknown schemes as opaque. The bug suggests that hierarchical might be a better choice. As to registration, at the moment that is undefined. The spec literally says "..." at this point: http://www.w3.org/TR/url/#url-writing The hope is to work together with the authors of the following Internet-Draft: https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg This is mentioned in bullet 3 of the following section: https://tools.ietf.org/html/draft-ruby-url-problem-00#section-4 Meanwhile, patches are welcome! It may be that there are certain URI schemes that defy conventional classification (file: certainly comes to mind, there may be others) that need to be specified explicitly in the specification. The easiest way to participate is to propose tests in the form of input strings, base strings, and expected results. That data will be added to: https://github.com/w3c/web-platform-tests/blob/master/url/urltestdata.txt And I'll use that data to update: https://url.spec.whatwg.org/interop/test-results/ Should you feel inclined to suggest changes to the URL spec, I'd encourage you to look at the following which contains an incomplete but significantly reworked parser: https://specs.webplatform.org/url/webspecs/develop/ That repository has a bunch of other things, including the evaluation scripts and a reference implementation. More information can be found here: https://github.com/webspecs/url#the-url-standard > Thanks, > S. - Sam Ruby > [1] http://www.w3.org/TR/url/#relative-scheme > [2] https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml From nobody Sat Jan 3 13:05:18 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1141A03F9 for ; Sat, 3 Jan 2015 13:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgTxWLRMl4Fs for ; Sat, 3 Jan 2015 13:05:06 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEA4F1A033B for ; Sat, 3 Jan 2015 13:05:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B6CE3BF35; Sat, 3 Jan 2015 21:05:04 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFAyzIhq_jsm; Sat, 3 Jan 2015 21:05:03 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.26.8]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D83F9BF32; Sat, 3 Jan 2015 21:05:02 +0000 (GMT) Message-ID: <54A8597E.9090206@cs.tcd.ie> Date: Sat, 03 Jan 2015 21:05:02 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> <54A6AABF.4060406@ninebynine.org> <54A6B6DF.1010206@intertwingly.net> <54A7DC46.2020708@ninebynine.org> <54A7E9F4.80406@intertwingly.net> <54A820EA.20200@ninebynine.org> <54A82CC4.9080606@intertwingly.net> <54A83B72.4010106@cs.tcd.ie> <54A8550A.1020708@intertwingly.net> In-Reply-To: <54A8550A.1020708@intertwingly.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/58yZb8o8gUyFoFSep29rSI58aT8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] presumption that RFC3986 is correct X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jan 2015 21:05:08 -0000 Hiya, On 03/01/15 20:46, Sam Ruby wrote: > On 01/03/2015 01:56 PM, Stephen Farrell wrote: >> >> Hi Sam, >> >> On 03/01/15 17:54, Sam Ruby wrote: >>> >>> I intend to work with implementors, providing patches and/or new >>> implementations along the way. And I'll continue to document and >>> publish findings. One such place I have published such work is at the >>> W3C: >>> >>> http://www.w3.org/TR/url/ >> >> I have at least one question about how you (or W3C, or any of us) >> plan to head towards some reasonable level of completeness with >> that work. (This may be a bit of an aside in the current discussion, >> or maybe not, I'm not sure.) >> >> The draft at the URL above includes [1], which is a risibly small >> and fixed (?) subset of an IANA registry. [2] What's the plan for >> making that sensible? I would assume pointing at the IANA registry >> is the simple and obvious fix there, but am puzzled as to why that >> hasn't been done in the few years this text has been around. >> >> Is that just an oversight? Or is your work really only covering >> exactly that particular subset of schemes? Or something else? > > This is a valid question, and the subject of an open bug: > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=27233 > > So the short answer is: it is a known issue, and suggestions are welcome. My suggestion: a) reference the IANA registry for schemes and b) the same for port numbers and then c) list which subsets of those the additions to 3986 (*) in the w3c document cover. That is, I don't think you need to try provide additional rules/text for all schemes but you do need to specify which you cover. (*) I'm assuming a sensible model where [1] ends up as a set of additional specifications on top of 3986 (or on top of 3986+errata or on top of a 3986bis if one ends up being needed). [1] http://www.w3.org/TR/url/ > > The longer answer isn't all that much longer. Given that every modern > programming language (and for that matter, every browser) will have a > part of their runtime library a concept of either a URI or a URL, and a > method to parse a string into such a structure, the question you pose is > equivalent to: "how should URI.parse methods handle unknown schemes"? > > Possible answers include: treat the content as hierarchical, and treat > the content as opaque. There may be other answers. > > What there probably needs to be is a sane default, and a way to register > new schemes. At the moment, the URL Working Draft treats unknown > schemes as opaque. The bug suggests that hierarchical might be a better > choice. > > As to registration, at the moment that is undefined. The spec literally > says "..." at this point: > > http://www.w3.org/TR/url/#url-writing > > The hope is to work together with the authors of the following > Internet-Draft: > > https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg That's a good plan. It's (welcome) news to me though, but good to hear. Are the editors of [1] and that draft in contact already? > > This is mentioned in bullet 3 of the following section: > > https://tools.ietf.org/html/draft-ruby-url-problem-00#section-4 > > Meanwhile, patches are welcome! It may be that there are certain URI > schemes that defy conventional classification (file: certainly comes to > mind, there may be others) that need to be specified explicitly in the > specification. > > The easiest way to participate That depends on who you are I guess:-) For me, that is not the best way (nor easiest) to participate. Cheers, S. > is to propose tests in the form of input > strings, base strings, and expected results. That data will be added to: > > https://github.com/w3c/web-platform-tests/blob/master/url/urltestdata.txt > > And I'll use that data to update: > > https://url.spec.whatwg.org/interop/test-results/ > > Should you feel inclined to suggest changes to the URL spec, I'd > encourage you to look at the following which contains an incomplete but > significantly reworked parser: > > https://specs.webplatform.org/url/webspecs/develop/ > > That repository has a bunch of other things, including the evaluation > scripts and a reference implementation. More information can be found > here: > > https://github.com/webspecs/url#the-url-standard > >> Thanks, >> S. > > - Sam Ruby > >> [1] http://www.w3.org/TR/url/#relative-scheme >> [2] https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml > > From nobody Sat Jan 3 14:54:20 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0102C1A0390; Sat, 3 Jan 2015 14:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lhPwpEqtQFs; Sat, 3 Jan 2015 14:54:15 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC601A036D; Sat, 3 Jan 2015 14:54:14 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id w62so6013696wes.27; Sat, 03 Jan 2015 14:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0oCNUrK04HDCMS1vWRC7/ggOkRdP9KhAYKsk7BP0LD0=; b=Gu/Q+zeLlUngFqchuXTyQIGS32HhzmDGFmUI91hOPY08PgLHxs2TzqWMGDK88Al8f0 1FRsB9sdyoPznqzKit3gRS3nBu5935KPCTpTZOCmnfx+Se7WZ96yatDl+8PFo0vV0THt OoGxd6sXXpkRCiHpgwqvOMcZEcolgrV9IKh6/ODPEW5VUHxn3INHv3Kmm+JT4Ii9xF4+ EUAV3EpETZYa8+cmn6c8kPWK/N9PhKVfvLESnPpI7Bq21RT5e6A8Qep4X+XGarAlciXK VO1FCvUz7ufJmHTXxhYX6juiU7k/g6pnPwXLj2cSDg/rA2LU2Ss59SZCYcC0+J+iasV/ hXFA== MIME-Version: 1.0 X-Received: by 10.194.62.76 with SMTP id w12mr164995324wjr.5.1420325653538; Sat, 03 Jan 2015 14:54:13 -0800 (PST) Received: by 10.27.204.198 with HTTP; Sat, 3 Jan 2015 14:54:12 -0800 (PST) Received: by 10.27.204.198 with HTTP; Sat, 3 Jan 2015 14:54:12 -0800 (PST) In-Reply-To: <54A841E0.7070306@seantek.com> References: <20150103191748.19958.qmail@ary.lan> <54A841E0.7070306@seantek.com> Date: Sat, 3 Jan 2015 14:54:12 -0800 Message-ID: From: "Murray S. Kucherawy" To: Sean Leonard Content-Type: multipart/alternative; boundary=047d7ba977a40b6e83050bc75683 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/sF-NWVHMw77_87NEXTUf8scSW-c Cc: arcmedia@ietf.org, John Levine , apps-discuss@ietf.org Subject: Re: [apps-discuss] [arcmedia] Proposed charter for arcmedia X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jan 2015 22:54:17 -0000 --047d7ba977a40b6e83050bc75683 Content-Type: text/plain; charset=UTF-8 Why does creating a new top level type also have to include everything that will be in it? That paragraph just gives examples so the unfamiliar reader will know what space we're talking about. I don't understand the purpose of enumerating all of the arguably popular instances of archive formats. -MSK On Jan 3, 2015 11:25 AM, "Sean Leonard" wrote: > On 1/3/2015 11:17 AM, John Levine wrote: > >> Here's a diff, and the changed text. >>> (Not sure if it will be accepted by the IETF mailing list...guess we're >>> about to find out) >>> >> I'm with Murray. It seems harmless but pointless. One the things a WG >> will have to do is to figure out what counts as an archive data format. >> If you want us to consider ISO 9660, I want us to consider ANSI INCITS 27. >> > > If it's used in regular commerce on the Internet, I don't have a problem > with ANSI INCITS 27. > > But I think your suggestion is a bit tongue-in-cheeck. .iso files are > *everywhere* on the Internet, and can contain payloads that seriously > affect the security of Internet-connected systems. I believe there is a > certain popular website out there just dedicated to "hunting" for them. And > to-date it still doesn't have a media type. > > A few e-mails back, it was stated that "No other work is in scope for this > working group" [except what's in the charter]. So the natural evolution is > to be sure that the charter includes everything that should be in-scope. > > Sean > > _______________________________________________ > arcmedia mailing list > arcmedia@ietf.org > https://www.ietf.org/mailman/listinfo/arcmedia > --047d7ba977a40b6e83050bc75683 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Why does creating a new top level type also have to include = everything that will be in it?

That paragraph just gives examples so the unfamiliar reader = will know what space we're talking about. I don't understand the pu= rpose of enumerating all of the arguably popular instances of archive forma= ts.

-MSK

On Jan 3, 2015 11:25 AM, "Sean Leonard"= ; <dev+ietf@seantek.com>= ; wrote:
On 1/3/2015= 11:17 AM, John Levine wrote:
Here's a diff, and the changed text.
(Not sure if it will be accepted by the IETF mailing list...guess we're=
about to find out)
I'm with Murray.=C2=A0 It seems harmless but pointless.=C2=A0 One the t= hings a WG
will have to do is to figure out what counts as an archive data format.
If you want us to consider ISO 9660, I want us to consider ANSI INCITS 27.<= br>

If it's used in regular commerce on the Internet, I don't have a pr= oblem with ANSI INCITS 27.

But I think your suggestion is a bit tongue-in-cheeck. .iso files are *ever= ywhere* on the Internet, and can contain payloads that seriously affect the= security of Internet-connected systems. I believe there is a certain popul= ar website out there just dedicated to "hunting" for them. And to= -date it still doesn't have a media type.

A few e-mails back, it was stated that "No other work is in scope for = this working group" [except what's in the charter]. So the natural= evolution is to be sure that the charter includes everything that should b= e in-scope.

Sean

_______________________________________________
arcmedia mailing list
arcmedia@ietf.org
https://www.ietf.org/mailman/listinfo/arcmedia
--047d7ba977a40b6e83050bc75683-- From nobody Sat Jan 3 17:23:50 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4681A1AB3; Sat, 3 Jan 2015 17:23:48 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24bOub-qXmgD; Sat, 3 Jan 2015 17:23:45 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0674.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::674]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A101A1AC9; Sat, 3 Jan 2015 17:23:42 -0800 (PST) Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0957.namprd02.prod.outlook.com (25.160.216.25) with Microsoft SMTP Server (TLS) id 15.1.49.12; Sun, 4 Jan 2015 01:23:18 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) by DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) with mapi id 15.01.0049.002; Sun, 4 Jan 2015 01:23:18 +0000 From: Larry Masinter To: Sean Leonard , "Murray S. Kucherawy" Thread-Topic: [apps-discuss] [arcmedia] Proposed charter for arcmedia Thread-Index: AQHQJyeNuL7u9fgufEOJX1POSFIv65yuER+AgAESKiA= Date: Sun, 4 Jan 2015 01:23:17 +0000 Message-ID: References: <54A41D6C.9010501@ninebynine.org> <86C96FDF-9A48-43A3-B38A-468F4407AD82@mnot.net> <286F8573-CD20-49DD-A361-B2D610D229AB@seantek.com> <54A7A8F5.1000402@seantek.com> In-Reply-To: <54A7A8F5.1000402@seantek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:9:8380:992:6043:96d7:2b0:6ee8] authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DM2PR0201MB0957; x-forefront-prvs: 0446F0FCE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(189002)(479174004)(24454002)(199003)(377454003)(2950100001)(16601075003)(19617315012)(19580395003)(74316001)(106116001)(62966003)(99286002)(92566001)(2900100001)(76176999)(15975445007)(54356999)(33656002)(102836002)(68736005)(107046002)(587094005)(54206007)(20776003)(19580405001)(77156002)(76576001)(106356001)(64706001)(86362001)(105586002)(120916001)(4396001)(99396003)(87936001)(2656002)(50986999)(97736003)(19625215002)(40100003)(101416001)(21056001)(46102003)(16236675004)(19300405004)(54606007)(122556002)(31966008)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0957; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_DM2PR0201MB0960C87FF61C5B46306257DEC35B0DM2PR0201MB0960_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2015 01:23:17.8097 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB0957 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/2-oxFv5qYyawOtU8CgGZ7XwtCas Cc: IETF Apps Discuss , "arcmedia@ietf.org" , Graham Klyne , Mark Nottingham , Public TAG List Subject: Re: [apps-discuss] [arcmedia] Proposed charter for arcmedia X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jan 2015 01:23:48 -0000 --_000_DM2PR0201MB0960C87FF61C5B46306257DEC35B0DM2PR0201MB0960_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkaWRu4oCZdCB3YW50IHRvIHF1aWJibGUgYWJvdXQgdGhlIHZlcmIg4oCTIOKAnG9ic2VydmVk 4oCdIGlzIGFtYmlndW91cywgYnV0IHNvIGlzIOKAnGNvbnNpZGVyZWTigJ0uIEkgd2FzIGhvcGlu ZyBub3QgdG8gaGF2ZSB0byBkZWZpbmUgcHJlY2lzZWx5IHdoYXQgY29vcmRpbmF0aW9uIGlzIGJl aW5nIG1hbmRhdGVkLCBidXQg4oCcd2lsbCBiZSBsb29rZWQgYXQgZm9yIGluZm9ybWF0aW9uYWwg cHVycG9zZXPigJ0gaXNu4oCZdCBzdHJvbmcgZW5vdWdoLg0KDQpJZiB0aGUgVzNDIFRBRyB3b3Jr IHdlcmUgaW5zdGVhZCBpbiBhbiBJRVRGIHdvcmtpbmcgZ3JvdXAgY2hhcnRlcmVkIHRvIHByb2R1 Y2UgaXQsIHdvdWxkIHRoZSBJRVRGIGV2ZW4gY2hhcnRlciBhbm90aGVyIGdyb3VwPyBJZiBzbywg d2hhdCBjb29yZGluYXRpb24gd291bGQgYmUgZXhwZWN0ZWQ/DQoNClRoZSB3YXkgdGhlIElFVEYg Y29tbWl0cyB0byBkbyB3b3JrIGlzIGJ5IGNoYXJ0ZXJpbmcgd29ya2luZyBncm91cHM7IHRoZSB3 YXkgdGhlIElFVEYgY29tbWl0cyB0byBjb29yZGluYXRlIGlzIGJ5IHB1dHRpbmcgdGhlIHByb21p c2UgaW4gd29ya2luZyBncm91cCBjaGFydGVycyAob3IsIGluIEFQU0FXRyB0aGUgZG9jdW1lbnQg bWluaS1jaGFydGVyKS4gIEkgZG9u4oCZdCB3YW50IHRvIHdvcmRzbWl0aCB0aGUgY2hhcnRlciBh bmQgaGF2ZSB0aGUgaW50ZW50IGdldCBsb3N0LiBJIHdhbnQgdG8gYXZvaWQgc2VlaW5nIElFVEYg c3RhbmRhcmRpemUgYXJjbWVkaWEgd2hpbGUgVzNDIHN0YW5kYXJkaXplcyBhbiBhcmNtZWRpYSBm b3JtYXQgd2hpY2ggaXNu4oCZdCBjb21wYXRpYmxlLiBUaGlzIG1heSBiZSBzaW1wbGUgb3IgbWF5 IHJlcXVpcmUgYWN0aXZlIGNvb3JkaW5hdGlvbiBvbiBib3RoIHNpZGVzLg0KDQpJZiB3ZSBhZ3Jl ZSB0byB0aGUgc2VudGltZW50LCB3ZSBjYW4gZGVjaWRlIGhvdyB0byBzYXkgaXQgaW4gdGhlIGNo YXJ0ZXIuDQoNCihiY2MgcHVibGljLWlldGYtdzNjIHJlIGFyY21lZGlhIHdvcmtpbmcgZ3JvdXAg Y2hhcnRlcikNCg0KTGFycnkNCi0tDQpodHRwOi8vbGFycnkubWFzaW50ZXIubmV0DQoNCg0KT24g MS8yLzIwMTUgMTE6MzMgUE0sIE11cnJheSBTLiBLdWNoZXJhd3kgd3JvdGU6DQpPbiBGcmksIEph biAyLCAyMDE1IGF0IDI6NDAgUE0sIFNlYW4gTGVvbmFyZCA8ZGV2K2lldGZAc2VhbnRlay5jb208 bWFpbHRvOmRlditpZXRmQHNlYW50ZWsuY29tPj4gd3JvdGU6DQo+ICJUaGUgVzNDIFRBRyB3b3Jr IG9uIHBhY2thZ2luZyBhbmQgYXJjaGl2ZXMsIGN1cnJlbnRseSBpbiBwcm9ncmVzcywgd2lsbCBh bHNvIGJlIG9ic2VydmVkLuKAnQ0KDQrigJxvYnNlcnZlZOKAnSBoYXMgdHdvIGRlZmluaXRpb25z OiDigJx3aWxsIGJlIGxvb2tlZCBhdCBmb3IgaW5mb3JtYXRpb25hbCBwdXJwb3Nlc+KAnSwgYW5k IOKAnHdpbGwgYmUgZm9sbG93ZWQgKHJlc3BlY3RlZCA9IHRyZWF0ZWQgYXMgbm9ybWF0aXZlKeKA nS4NCg0KU2luY2UgdGhlIHRoaW5nIGJlaW5nIG9ic2VydmVkIGlzIGEgd29yay1pbi1wcm9ncmVz cyBvdXRzaWRlIG9mIHRoZSBJRVRGLCBJIGd1ZXNzZWQgdGhhdCB3b3VsZG4ndCBiZSB0YWtlbiBu b3JtYXRpdmVseS4NCg0KSG93IGFib3V0ICJjb25zaWRlcmVkIj8NCg0KImNvbnNpZGVyZWQiIGlz IG9rLg0KDQo= --_000_DM2PR0201MB0960C87FF61C5B46306257DEC35B0DM2PR0201MB0960_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjYxNjk4NTcy MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTExNzI2 NjUwMiAtMjA3OTY1OTY5MCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLXN0YXJ0LWF0OjEwOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JIGRpZG7igJl0IHdhbnQgdG8gcXVpYmJsZSBhYm91dCB0aGUgdmVyYiDigJMg4oCc b2JzZXJ2ZWTigJ0gaXMgYW1iaWd1b3VzLCBidXQgc28gaXMg4oCcY29uc2lkZXJlZOKAnS4gSSB3 YXMgaG9waW5nIG5vdCB0byBoYXZlIHRvIGRlZmluZSBwcmVjaXNlbHkgd2hhdCBjb29yZGluYXRp b24gaXMgYmVpbmcNCiBtYW5kYXRlZCwgYnV0IOKAnDwvc3Bhbj53aWxsIGJlIGxvb2tlZCBhdCBm b3IgaW5mb3JtYXRpb25hbCBwdXJwb3NlczxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7i gJ0gaXNu4oCZdCBzdHJvbmcgZW5vdWdoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SWYgdGhlIFczQyBUQUcgd29yayB3ZXJlIGluc3RlYWQgaW4gYW4gSUVURiB3 b3JraW5nIGdyb3VwIGNoYXJ0ZXJlZCB0byBwcm9kdWNlIGl0LCB3b3VsZCB0aGUgSUVURiBldmVu IGNoYXJ0ZXINCjxpPmFub3RoZXI8L2k+IGdyb3VwPyBJZiBzbywgd2hhdCBjb29yZGluYXRpb24g d291bGQgYmUgZXhwZWN0ZWQ/ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+VGhlIHdheSB0aGUgSUVURiBjb21taXRzIHRvIGRvIHdvcmsgaXMgYnkgY2hh cnRlcmluZyB3b3JraW5nIGdyb3VwczsgdGhlIHdheSB0aGUgSUVURiBjb21taXRzIHRvIGNvb3Jk aW5hdGUgaXMgYnkgcHV0dGluZyB0aGUgcHJvbWlzZSBpbiB3b3JraW5nIGdyb3VwIGNoYXJ0ZXJz DQogKG9yLCBpbiBBUFNBV0cgdGhlIGRvY3VtZW50IG1pbmktY2hhcnRlcikuICZuYnNwO0kgZG9u 4oCZdCB3YW50IHRvIHdvcmRzbWl0aCB0aGUgY2hhcnRlciBhbmQgaGF2ZSB0aGUgaW50ZW50IGdl dCBsb3N0LiBJIHdhbnQgdG8gYXZvaWQgc2VlaW5nIElFVEYgc3RhbmRhcmRpemUgYXJjbWVkaWEg d2hpbGUgVzNDIHN0YW5kYXJkaXplcyBhbiBhcmNtZWRpYSBmb3JtYXQgd2hpY2ggaXNu4oCZdCBj b21wYXRpYmxlLiBUaGlzIG1heSBiZSBzaW1wbGUgb3IgbWF5IHJlcXVpcmUNCiBhY3RpdmUgY29v cmRpbmF0aW9uIG9uIGJvdGggc2lkZXMuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SWYgd2UgYWdyZWUgdG8gdGhlIHNlbnRpbWVudCwgd2UgY2FuIGRlY2lkZSBo b3cgdG8gc2F5IGl0IGluIHRoZSBjaGFydGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+KGJjYyBwdWJsaWMtaWV0Zi13M2MgcmUgYXJjbWVkaWEgd29ya2luZyBn cm91cCBjaGFydGVyKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ TGFycnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0 cDovL2xhcnJ5Lm1hc2ludGVyLm5ldCI+aHR0cDovL2xhcnJ5Lm1hc2ludGVyLm5ldDwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEvMi8yMDE1IDExOjMzIFBNLCBNdXJyYXkg Uy4gS3VjaGVyYXd5IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEphbiAyLCAyMDE1IGF0IDI6NDAgUE0sIFNlYW4gTGVv bmFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRldiYjNDM7aWV0ZkBzZWFudGVrLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmRldiYjNDM7aWV0ZkBzZWFudGVrLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jmd0OyAmcXVvdDtUaGUgVzNDIFRBRyB3b3JrIG9uIHBhY2thZ2luZyBhbmQgYXJjaGl2ZXMsIGN1 cnJlbnRseSBpbiBwcm9ncmVzcywgd2lsbCBhbHNvIGJlIG9ic2VydmVkLuKAnTxicj4NCjxicj4N CuKAnG9ic2VydmVk4oCdIGhhcyB0d28gZGVmaW5pdGlvbnM6IOKAnHdpbGwgYmUgbG9va2VkIGF0 IGZvciBpbmZvcm1hdGlvbmFsIHB1cnBvc2Vz4oCdLCBhbmQg4oCcd2lsbCBiZSBmb2xsb3dlZCAo cmVzcGVjdGVkID0gdHJlYXRlZCBhcyBub3JtYXRpdmUp4oCdLjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2luY2UgdGhlIHRoaW5n IGJlaW5nIG9ic2VydmVkIGlzIGEgd29yay1pbi1wcm9ncmVzcyBvdXRzaWRlIG9mIHRoZSBJRVRG LCBJIGd1ZXNzZWQgdGhhdCB3b3VsZG4ndCBiZSB0YWtlbiBub3JtYXRpdmVseS48YnI+DQo8YnI+ DQpIb3cgYWJvdXQgJnF1b3Q7Y29uc2lkZXJlZCZxdW90Oz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KJnF1b3Q7Y29uc2lkZXJlZCZxdW90OyBpcyBvay48YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM2PR0201MB0960C87FF61C5B46306257DEC35B0DM2PR0201MB0960_-- From nobody Sun Jan 4 00:43:37 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B981A7023 for ; Sun, 4 Jan 2015 00:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uD40kgBLMh1L for ; Sun, 4 Jan 2015 00:43:34 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 00F811A7022 for ; Sun, 4 Jan 2015 00:43:33 -0800 (PST) Received: from [192.168.2.160] ([84.187.62.205]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MJngW-1Y8miC0AzM-0018yq; Sun, 04 Jan 2015 09:43:30 +0100 Message-ID: <54A8FD21.10206@gmx.de> Date: Sun, 04 Jan 2015 09:43:13 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> <54A6AABF.4060406@ninebynine.org> <54A6B6DF.1010206@intertwingly.net> <54A6BB22.2060203@gmx.de> <54A6C01A.6020000@intertwingly.net> <54A6CD33.3080101@gmx.de> <54A6E5F1.3070006@intertwingly.net> In-Reply-To: <54A6E5F1.3070006@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:rBvkleASDJnGPlSkedGrYd0gCqY4rbOJewxPJb/co+n3VUxckO8 g0nUb79OjPc5sgrcYE6xEVrXRl5dwizL9iLR1tqibDUBUZVLRci8ZIqgJp/TfIrZedUyAkG Iji1fUX1on/3S+G5tp3mUUp0Q1vTcQLCQf9I8FB5oyYqR8tlwloZEwjk2e16XsD7Toomy/o nWetdfuTmk80QVjtxas/g== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/uIj5z0pJzVbNrv4KwgdYU2tD6XE Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Potential issues in RFC 3986 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jan 2015 08:43:36 -0000 On 2015-01-02 19:39, Sam Ruby wrote: > ... > Since you agree that RFC 3986 is likely incorrect wrt IDNA advice, can I > get you to suggest a test case that demonstrates this? > > The master source for these tests is here: > > https://github.com/w3c/web-platform-tests/blob/master/url/urltestdata.txt > > A pull request would be appreciated. A detailed suggestion with the > same information (a source string, a base URI, and what the expected > values for each of the components) also works. > ... My understanding is that whatever IDNA-related problems might be in the spec, they won't be observable with parsing tests alone; we would need to observe that actually gets on the wire when (for instance) the HTTP request is made (such as what the DNS lookup is). > ... Best regards, Julian From nobody Sun Jan 4 03:55:37 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451AD1A87E3 for ; Sun, 4 Jan 2015 03:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAJvK1LjO-ge for ; Sun, 4 Jan 2015 03:55:33 -0800 (PST) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76801A8710 for ; Sun, 4 Jan 2015 03:55:32 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id r5so14584476qcx.13 for ; Sun, 04 Jan 2015 03:55:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=bw8YJ5NcntrcbAs2gQd6uGP0xpEP0agES7hV57mAovg=; b=XZdgNsOO0dwwJxyDXViHMVPEFQEsNDMbxY4/DuIpR65aDex23pO5Hz4h3rI4dvvvcf usysQj4Brh2kvsvZskkvXrMzNvtNFbmgleoSxyw0TcxonF2Y9G4BD8Y3U4WFXWvNogYs P43fQK8HIU33KH961JNjnfYNS4qctDlYM+qlbF2mABFTb9/kye43mcNZYUT/06Lnvb1M NqZ4Zv/WSQAd2X2xxBtsE95kaMBOLb8bItiikZSlPAXGXv6v5cXnqLEZubnrCWtWwx7g TAVGTAEg7/apR44LKahSDL//zldLTQGKduILCsxgqKKWQJe4FFyam4zv9IU0EoZQCc9u 4RdQ== MIME-Version: 1.0 X-Received: by 10.224.165.148 with SMTP id i20mr70736488qay.67.1420372532027; Sun, 04 Jan 2015 03:55:32 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Sun, 4 Jan 2015 03:55:31 -0800 (PST) In-Reply-To: <54A6A253.2050306@seantek.com> References: <54A5763C.5060203@ninebynine.org> <54A6A253.2050306@seantek.com> Date: Sun, 4 Jan 2015 21:55:31 +1000 X-Google-Sender-Auth: JZdabyPnrxTAuzkx7uZx_UYFPmk Message-ID: From: Matthew Kerwin To: Sean Leonard Content-Type: multipart/alternative; boundary=089e01295656386944050bd24042 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kyPYlr2QJ0djP57wRV7OjuTkOao Cc: Graham Klyne , IETF Apps Discuss , Larry Masinter Subject: Re: [apps-discuss] Call for Adoption: draft-kerwin-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jan 2015 11:55:35 -0000 --089e01295656386944050bd24042 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2 January 2015 at 23:51, Sean Leonard wrote: > > Let's be clear about file: URI. The file scheme *is* permanently > registered in the URI Schemes database assignments/uri-schemes/uri-schemes.xhtml#uri-schemes-2>. The reference > is RFC 1738 (December 1994). Until this or any other document supplants i= t, > RFC 1738 is in force. > > =E2=80=8B[...] > > > > It's short, sweet, and to the point. Sure it leaves a lot unspecified, bu= t > short =3D less to argue about. :) Does anyone take issue with the RFC 173= 8 > text? > > RFC 1738 is marked "obsolete," even if that's not entirely true, and thus some members of the internet community (rightly or wrongly) believe that file: is orphaned. In fact, that fact was what triggered me to start writing it in the first place. Then, when I first attempted to write the draft, I essentially took the text from 1738 and wangled it the way Paul Hoffman did with 4248 and 2466 to basically clarify the status without changing anything, and no one was happy with that. The attempt to satisfy everyone's desire to see something better more thorough and up to date (including mine) is what lead to the text you see today. =E2=80=8BShort doesn't mean less to argue about, when short means holes in = the definition. More ambiguity =3D more to argue about. I'd have thought that w= as self evident with file: in particular (try typing the same UNC-flavoured file: URL into both Chrome and Firefox and see how long it takes them to disagree violently.) --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --089e01295656386944050bd24042 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 2 January 2015 at 23:51, Sean Leonard <dev+ietf@seantek.com>= ; w= rote:

Let's be clear about file: URI. The file scheme *is* permanently regist= ered in the URI Schemes database <http://= www.iana.org/assignments/uri-schemes/uri-schemes.xhtml#uri-sc= hemes-2>. The reference is RFC 1738 (December 1994). Until this or a= ny other document supplants it, RFC 1738 is in force.

=E2=80=8B[...]



It's short, sweet, and to the point. Sure it leaves a lot unspecified, = but short =3D less to argue about. :) Does anyone take issue with the RFC 1= 738 text?


<= div class=3D"gmail_default" style=3D"font-family:georgia,serif;color:rgb(7,= 55,99)">RFC 1738 is marked "obsolete," even if that's not ent= irely true, and thus some members of the internet community (rightly or wro= ngly) believe that file: is orphaned. In fact, that fact was what triggered= me to start writing it in the first place.

Then, when I first attempted to write the draft, I essentially took the t= ext from 1738 and wangled it the way Paul Hoffman did with 4248 and 2466 to= basically clarify the status without changing anything, and no one was hap= py with that. The attempt to satisfy everyone's desire to see something= <s>better</s> more thorough and up to date (including mine) = =C2=A0is what lead to the text you see today.

=E2=80=8BShort doesn't mean less to argue about, = when short means holes in the definition. More ambiguity =3D more to argue = about. I'd have thought that was self evident with file: in particular = (try typing the same UNC-flavoured file: URL into both Chrome and Firefox a= nd see how long it takes them to disagree violently.)


--
=C2= =A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--089e01295656386944050bd24042-- From nobody Sun Jan 4 04:23:07 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40771A8824 for ; Sun, 4 Jan 2015 04:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSHgfAlEIX3C for ; Sun, 4 Jan 2015 04:23:01 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 086891A87F2 for ; Sun, 4 Jan 2015 04:23:01 -0800 (PST) Received: by mail-qg0-f45.google.com with SMTP id z107so3298022qgd.32 for ; Sun, 04 Jan 2015 04:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NQRHj8YXjsrUyE2QznV+ILKaKMYvOp4NonhqepjJ0IA=; b=VnqpWP6Ebi0PS8iKU7dJW96V448xXw2vntTsiRCMCx2ciMSDwn58diwcf77R1IpAlM Am9XpS3zKoITJ3oIdiiABX1O8N/EBnFeI1Qe9AdkSuo1fJqxfJrEPzZXDAs9GfXY1ITJ PsemRf024l36zMalExJ7IVS0qty/7gQfT3hMYRVu/76PUb5jOM6RgrL+g0msP+4wCUa7 eRN7sB4DNfQDwVFubvTc1V1nSe4YFSGii4LPAIeY3y9mmtrZB1Vx9VG22Sr22o17YJ8E G+51JEFoBbiENN3L2HAaqhMbglFM3Ed7lKGf1g7BOzLFl/ejteIgAYubgiwNXVSVTeqC 7ZSw== MIME-Version: 1.0 X-Received: by 10.224.165.148 with SMTP id i20mr70867297qay.67.1420374180235; Sun, 04 Jan 2015 04:23:00 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Sun, 4 Jan 2015 04:22:59 -0800 (PST) In-Reply-To: <54A557E1.6050502@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> Date: Sun, 4 Jan 2015 22:22:59 +1000 X-Google-Sender-Auth: v5hwDmqQsTANuNJOerONKqwFa3U Message-ID: From: Matthew Kerwin To: Sam Ruby Content-Type: multipart/alternative; boundary=089e012956567617d5050bd2a255 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/yzYDAoZKyhER8-OyRmKokFiO9ko Cc: IETF Apps Discuss , Larry Masinter Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jan 2015 12:23:04 -0000 --089e012956567617d5050bd2a255 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2 January 2015 at 00:21, Sam Ruby wrote: > > A few concrete examples are here: > > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13511.html > =E2=80=8B=E2=80=8B > > > It is my hope that by comparing notes we can converge. > =E2=80=8B > =E2=80=8B =E2=80=8BTo be honest, a big reason for using RFC 3986 as a normative refer= ence is so I don't have to deal with things like hostnames. If those definitions are good enough for the shiny new HTTP/1.1 (which actually uses hostnames) then surely they're also sufficient for file: (which often doesn't). BTW who on earth writes localhost as "2130706433"? Or more significantly, who on earth *accepts* that as a valid URL? =E2=80=8B > > I guess I could add support for backslashes. I suspect that would end up >> in a non-normative appendix, along with the "|" drive letter separator >> (as suggested in an earlier message, and currently being worked into the >> next draft.) >> > > I don't understand the thought process here. The current Internet-Draft > takes care to document a select few browser specific syntaxes, but many > others (including the ones you mention above) are not included. What is > the selection criteria you are using? > > For the most part: things that aren't silly (big-endian integer encoding of IPv4 addresses), things that aren't widely touted as obsolete (like backslashes[1]), and as much as possible, things that go against the parent standards (like trying to jimmy "/c|/" into RFC 3986). Importantly, I don't want to include every codepath in every implementation that exists, but I don't want the definition I write to *not* work in any implementations. [1] http://blogs.msdn.com/b/ie/archive/2006/12/06/file-uris-in-windows.aspx --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --089e012956567617d5050bd2a255 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 2 January 2015 at 00:21, Sam Ruby <= ;rubys@intertwi= ngly.net> wrote:

A few concrete examples are here:

http://www.ietf.org/mail-archive/web/apps= -discuss/current/msg13511.html
=E2=80=8B= =E2=80=8B


It is my hope that by comparing notes we can converge.
=E2=80=8B
=E2=80=8B

=E2=80=8BTo be h= onest, a big reason for using RFC 3986 as a normative reference is so I don= 't have to deal with things like hostnames. If those definitions are go= od enough for the shiny new HTTP/1.1 (which actually uses hostnames) then s= urely they're also sufficient for file: (which often doesn't).

BTW who on earth writes localhost as "213= 0706433"? Or more significantly, who on earth *accepts* that as a vali= d URL?


=E2=80=8B

I guess I could add support for backslashes. I suspect that would end up in a non-normative appendix, along with the "|" drive letter sepa= rator
(as suggested in an earlier message, and currently being worked into the next draft.)

 I don't understand the thought process here. The current Internet-Draft= takes care to document a select few browser specific syntaxes, but many ot= hers (including the ones you mention above) are not included.=C2=A0 What is= the selection criteria you are using?


<= div class=3D"gmail_default" style=3D"font-family:georgia,serif;color:rgb(7,= 55,99)">For the most part: things that aren't silly (big-endian integer= encoding of IPv4 addresses), things that aren't widely touted as obsol= ete (like backslashes[1]), and as much as possible, things that go against = the parent standards (like trying to jimmy "/c|/" into RFC 3986).=

Importantly, I don't want to include = every codepath in every implementation that exists, but I don't want th= e definition I write to *not* work in any implementations.
<= br>
[1]=C2=A0http://blogs.msdn.com/b/ie/archive/2006= /12/06/file-uris-in-windows.aspx


= --
=C2=A0 Matthew Kerwi= n
=C2=A0 htt= p://matthew.kerwin.net.au/
--089e012956567617d5050bd2a255-- From nobody Sun Jan 4 05:02:30 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB4B1A8893 for ; Sun, 4 Jan 2015 05:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.627 X-Spam-Level: X-Spam-Status: No, score=-1.627 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muPnVBbSWVDY for ; Sun, 4 Jan 2015 05:02:22 -0800 (PST) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6111A00A8 for ; Sun, 4 Jan 2015 05:02:21 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id i17so14741244qcy.35 for ; Sun, 04 Jan 2015 05:02:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=g3rqPFBEF/2IxbwamyDQHdLTQ5TT/VVCy39k2A92mME=; b=Gb3rQQ2yhnjay6ZCR80/r5d+dlm/CmQ797z1PBhWY4XPQcYIqFt+q3/mX17PiMSP6a ffMrkE+GiuZB0ibfmvItH7fS9S2YJszD2F6YZ38vJwQFjxwO2n9cCRRmVjqj0pPsnqzG DpFLPptASXfWbCdP6lvs4w3Wx40iWfhT6bQt/AoHlWT9vC1D3nOqyowRQVX/jGZn1Aw9 Vu3Zv5oxc/d5fKwA53dkrdyQ2Zi/Mx4835nIBtncsjy+iRXRNKrHM/hEylm0gNPjFNaG KALdpCXO6Opd272+9lEc21gT67iUGT9kq1EB59UWVRsl27TcElN6QH30+maT3Z41zxlp U+sA== MIME-Version: 1.0 X-Received: by 10.229.249.137 with SMTP id mk9mr137045937qcb.4.1420376540957; Sun, 04 Jan 2015 05:02:20 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Sun, 4 Jan 2015 05:02:20 -0800 (PST) In-Reply-To: <54A56E7C.5010605@ninebynine.org> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A56E7C.5010605@ninebynine.org> Date: Sun, 4 Jan 2015 23:02:20 +1000 X-Google-Sender-Auth: NWpHQdamSDhZxKAq_tWOhLtiDLo Message-ID: From: Matthew Kerwin To: Graham Klyne Content-Type: multipart/alternative; boundary=001a11334d902bd312050bd32fbd Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Rcl9vJeQFyxymG0AFaPfOqZTN0E Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jan 2015 13:02:27 -0000 --001a11334d902bd312050bd32fbd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2 January 2015 at 01:57, Graham Klyne wrote: > Matthew, > > I've finally been prompted to read through your > https://tools.ietf.org/html/draft-kerwin-file-scheme-13. I think it's > great that this is being tackled (again), and I'm hoping that there will = be > enough pragmatism this time round to achieve consensus on something that'= s > an improvement over the status quo, even if not perfect. > > My comments follow... > > > Section 2: windows-path > > I'm pretty sure I've come across '/c:/rest-of-path' as a mapping of > Windows file paths (I'm not sure where; I may even have used it myself. = It > makes some logical sense to me in that on Windows (non-UNC-naming) the > drive letters are effectively the top-level directories in a single-root > file system.) > > But that would subsumed by 'path-absolute'. [Later] I see you have this > covered as an example, and more. > > Yes, the ABNF is currently being changed to remove a lot of unnecessary redundancy and confusion like this, and also hopefully to resolve the following point. > > Section 2: Inclusion of "|" > > As others have raised, there's an question of how to deal with common > extensions to normal URI syntax, and separation of a preferred core for > file: URI syntax from documentation of common variations. If possible, m= y > preference would be to treat non-conformance with RFC3986, like this, as = a > common variation. I think 'core' file URIs should preferably be fully > RFC3986 conformant so that existing generic parsers will handle them. > > [Later] I see you have this covered too. > > I think the document might be clearer in its intent if at the start of > section 2, and in the syntax productions, it were more clearly signaled > that the syntax described here includes commonly-used forms that go beyon= d > RFC3986 syntax. > > =E2=80=8BThe current plan is to move it to a non-normative appendix as a "c= ommonly used but invalid" thingy, so the normative construct can be simpler.=E2=80= =8B > > Section 2: local vs non-local > > See below. I think this is a non-relevant distinction. e.g. Is a remote > file system mounted on a Unix-style mount point supposed to include an > authority? > > Probably not. My intention was to distinguish things that don't have an authority (can use local filesystem calls to access) from those that require an authority (must be opened some other way, like a different syscall, or by implementing some other protocol). This part of the language would benefit from having more peoples' input. > > Section 3: methods on file URIs > > I'm not sure I agree that translation to filename is the *only* operatio= n > that can be done using a file: URI. And I have concerns about use of the > term "method" here, which is strongly suggestive of HTTP "methods". > =E2=80=8B > =E2=80=8B > > =E2=80=8B > =E2=80=8B =E2=80=8BRE the only operation: rather than deal with trying to define (or reasonably leave unspecified) the set of operations that are made available by the local filesystem API, I went a bit reductive. I'm not sure of a better way forward, other than to make the language less strong. RE the term "method": actually that's my OO programming background shining through, but yes, BCP 35 or 115 or whatever it's called uses "operations" so I can change to conform with that. =E2=80=8B > > =E2=80=8B=E2=80=8B > Specifically, dereferencing: I have frequently used APIs that retrieve > the entity referenced by a URI, including file: URIs. Indeed, in much of > my code, this is central to unifying web and local file access. I think > retrieval is an operation that is very naturally performed on a file URI, > with results broadly equivalent to an HTTP GET. Some analogue to HTTP PU= T > is also conceivable. > =E2=80=8B=E2=80=8B > > =E2=80=8B > =E2=80=8B Yes, that's fair, I was being overly reductive. Presumably file: URIs ought to support the full CRUD suite, assuming the underlying filesystem allows it. =E2=80=8B > > I think the issue here is not that the nature of operations that can be > performed is restricted, but the details of how to perform them, which wi= ll > vary from system to system. > > You also say "The local file system API can only be used if the file URI > has a > blank (or absent) authority and the path, when transformed to the > local system's conventions, is not a UNC string." > > A common case I've come across is where the authority is "localhost", in > which case it seems reasonable to allow local file access based the file: > URI. > =E2=80=8B=E2=80=8B > > =E2=80=8B > =E2=80=8B =E2=80=8BI've swung back and forth on this particular topic. The issue is t= hat some folk (including Chrome) treat "file://localhost/foo" as \\localhost\foo (i.e. a samba file share served from this machine), and when it comes to choosing one way or the other, this time I went with Chrome. This is a change (potentially a big one?) from 1738, but I guessed it was reasonable. =E2=80=8B > > More generally, it seems to me that the difference between local and > remote files (with or without host) is in the mechanism that might be use= d > to access the file. In some cases, it may be the same, by virtue of bein= g > handled by the underlying system's file system. And in some cases, a > filename that appears to have no host may in fact be remote (cf. remote > file system, mounted on Unix-like file system). I think that trying to > make this distinction raises more questions than it answers. > > That may be the case. Is it better to do a 1738 and not say anything useful about a non-blank, non-localhost authority? > > Section 3.1 (esp step 4): > > I'm a bit confused by the intent here. I think it's reasonably clear tha= t > > file://example.org/c:/path/segments > file:///c:/path/segments > > would be expected, but what about: > > file:/c:/path/segments > vs > file:c:/path/segments > > I think you prefer the latter. > > But I think it would be more consistent, and would avoid potential > ambiguities in relative reference resolution, to prefer the former; i.e. > to consider that drives are like top-level sub-directories of a root "/". > I think this section could also be thereby simplified a little. > > =E2=80=8BTo be perfectly honest, if someone can propose something about the= root that makes my life easier, I'll welcome it with open arms. My struggle has been with addressing the UNIX root directory, and now you're suggesting I also include it in Windows. I guess if it's ubiquitous it saves me the burden of trying to describe it, or explain when not to use it.=E2=80=8B > > Section 3.3, steps 5, 6: > > I think it is necessary to say something about %-escaping here. I've bee= n > bitten in the past by doing roughly what you describe here, with filename= s > that happen to contain (say) '#' characters. > > Isn't that covered by "Transform the directory name to a path segment ( [RFC3986], Section 3.3 ) as per Section 2 of [RFC3986] ."? > > Section 6: > > Can you please include a full registration template for the file: scheme > here. cf. https://tools.ietf.org/html/rfc4395#section-5.4 > > (Many of the fields will just refer to other sections of the document) > > It used to be like that until version 12, when somebody (I can't remember who) suggested it could be simplified to what it currently is. > > Again, thanks for tackling this. > > =E2=80=8BNo worries, thanks for the comments.=E2=80=8B --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11334d902bd312050bd32fbd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 2 January 2015 at 01:57, Graham Klyne <gk@ninebynine= .org> wrote:
Matthew,

I've finally been prompted to read through your https://tool= s.ietf.org/html/draft-kerwin-file-scheme-13.=C2=A0 I think it= 9;s great that this is being tackled (again), and I'm hoping that there= will be enough pragmatism this time round to achieve consensus on somethin= g that's an improvement over the status quo, even if not perfect.

My comments follow...


Section 2: windows-path

I'm pretty sure I've come across '/c:/rest-of-path' as a ma= pping of Windows file paths (I'm not sure where; I may even have used i= t myself.=C2=A0 It makes some logical sense to me in that on Windows (non-U= NC-naming) the drive letters are effectively the top-level directories in a= single-root file system.)

But that would subsumed by 'path-absolute'.=C2=A0 [Later] I see you= have this covered as an example, and more.


Yes, the ABNF is currently be= ing changed to remove a lot of unnecessary redundancy and confusion like th= is, and also hopefully to resolve the following point.

= =C2=A0

Section 2: Inclusion of "|"

As others have raised, there's an question of how to deal with common e= xtensions to normal URI syntax, and separation of a preferred core for file= : URI syntax from documentation of common variations.=C2=A0 If possible, my= preference would be to treat non-conformance with RFC3986, like this, as a= common variation.=C2=A0 I think 'core' file URIs should preferably= be fully RFC3986 conformant so that existing generic parsers will handle t= hem.

[Later] I see you have this covered too.

I think the document might be clearer in its intent if at the start of sect= ion 2, and in the syntax productions, it were more clearly signaled that th= e syntax described here includes commonly-used forms that go beyond RFC3986= syntax.


=E2=80=8BThe current plan is = to move it to a non-normative appendix as a "commonly used but invalid= " thingy, so the normative construct can be simpler.=E2=80=8B
=C2=A0

Section 2: local vs non-local

See below.=C2=A0 I think this is a non-relevant distinction.=C2=A0 e.g. Is = a remote file system mounted on a Unix-style mount point supposed to includ= e an authority?


Probably not. My intention wa= s to distinguish things that don't have an authority (can use local fil= esystem calls to access) from those that require an authority (must be open= ed some other way, like a different syscall, or by implementing some other = protocol). This part of the language would benefit from having more peoples= ' input.

=C2=A0

Section 3: methods on file URIs

I'm not sure I agree that translation to filename is the=C2=A0 *only* o= peration that can be done using a file: URI.=C2=A0 And I have concerns abou= t use of the term "method" here, which is strongly suggestive of = HTTP "methods".
=E2=80=8B
=E2=80=8B

=E2=80=8B
=E2=80=8B<= /blockquote>

=E2=80=8BRE the only operation: rather than deal with trying to d= efine (or reasonably leave unspecified) the set of operations that are made= available by the local filesystem API, I went a bit reductive. I'm not= sure of a better way forward, other than to make the language less strong.=

RE the term "method": actually = that's my OO programming background shining through, but yes, BCP 35 or= 115 or whatever it's called uses "operations" so I can chang= e to conform with that.


=E2=80=8B

=E2=80=8B=E2=80=8BSpecifically, dereferencing:=C2=A0 I have frequently used APIs that retrie= ve the entity referenced by a URI, including file: URIs.=C2=A0 Indeed, in m= uch of my code, this is central to unifying web and local file access.=C2= =A0 =C2=A0I think retrieval is an operation that is very naturally performe= d on a file URI, with results broadly equivalent to an HTTP GET.=C2=A0 Some= analogue to HTTP PUT is also conceivable.
=E2=80=8B= =E2=80=8B

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

Yes, that's fair, I= was being overly reductive. Presumably file: URIs ought to support the ful= l CRUD suite, assuming the underlying filesystem allows it.

=
=E2=80=8B

I think the issue here is not that the nature of operations that can be per= formed is restricted, but the details of how to perform them, which will va= ry from system to system.

You also say "The local file system API can only be used if the file U= RI has a
=C2=A0 =C2=A0blank (or absent) authority and the path, when transformed to = the
=C2=A0 =C2=A0local system's conventions, is not a UNC string."

A common case I've come across is where the authority is "localhos= t", in which case it seems reasonable to allow local file access based= the file: URI.
=E2=80=8B=E2=80=8B

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

=E2=80=8BI've swung= back and forth on this particular topic. The issue is that some folk (incl= uding Chrome) treat "file://localhost/foo" as \\localhost\foo (i.= e. a samba file share served from this machine), and when it comes to choos= ing one way or the other, this time I went with Chrome.

<= /div>
This is a change (potentially a big one?) from 1738, but I gu= essed it was reasonable.


=E2=80=8B

More generally, it seems to me that the difference between local and remote= files (with or without host) is in the mechanism that might be used to acc= ess the file.=C2=A0 In some cases, it may be the same, by virtue of being h= andled by the underlying system's file system.=C2=A0 And in some cases,= a filename that appears to have no host may in fact be remote (cf. remote = file system, mounted on Unix-like file system).=C2=A0 I think that trying t= o make this distinction raises more questions than it answers.


That may be the case. Is it b= etter to do a 1738 and not say anything useful about a non-blank, non-local= host authority?

=C2=A0

Section 3.1 (esp step 4):

I'm a bit confused by the intent here.=C2=A0 I think it's reasonabl= y clear that

=C2=A0 file://example.org/c:/path/segments
=C2=A0 file:///c:/path/segments

would be expected, but what about:

=C2=A0 file:/c:/path/segments
vs
=C2=A0 file:c:/path/segments

I think you prefer the latter.

But I think it would be more consistent, and would avoid potential ambiguit= ies in relative reference resolution, to prefer the former;=C2=A0 i.e. to c= onsider that drives are like top-level sub-directories of a root "/&qu= ot;.=C2=A0 I think this section could also be thereby simplified a little.<= br>

=E2=80=8BTo be perfectly hone= st, if someone can propose something about the root that makes my life easi= er, I'll welcome it with open arms. My struggle has been with addressin= g the UNIX root directory, and now you're suggesting I also include it = in Windows. I guess if it's ubiquitous it saves me the burden of trying= to describe it, or explain when not to use it.=E2=80=8B

=C2=A0

Section 3.3, steps 5, 6:

I think it is necessary to say something about %-escaping here.=C2=A0 I'= ;ve been bitten in the past by doing roughly what you describe here, with f= ilenames that happen to contain (say) '#' characters.


Isn't that covered by &qu= ot;Transform the directory name to a path segment ([RFC3986],= =C2=A0Section=C2=A03.3) as per Section=C2=A02 of [RFC3986]."?

=C2= =A0

Section 6:

Can you please include a full registration template for the file: scheme he= re. cf.=C2=A0 https://tools.ietf.org/html/rfc4395#section-5.4=

(Many of the fields will just refer to other sections of the document)


It used to be like that until= version 12, when somebody (I can't remember who) suggested it could be= simplified to what it currently is.


=C2= =A0

Again, thanks for tackling this.


=E2=80= =8BNo worries, thanks for the comments.=E2=80=8B


--
=C2=A0 M= atthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a11334d902bd312050bd32fbd-- From nobody Sun Jan 4 05:11:27 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F041A88B1 for ; Sun, 4 Jan 2015 05:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fw_E-6NYX1_J for ; Sun, 4 Jan 2015 05:11:23 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735811A88AF for ; Sun, 4 Jan 2015 05:11:23 -0800 (PST) Received: by mail-qg0-f41.google.com with SMTP id e89so12747553qgf.28 for ; Sun, 04 Jan 2015 05:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4P/k71Wd+kTmx9B8c2ARpgKfexlcyzFO9YFYsjdctdk=; b=b+Fy8HbAZRUC3cFZxBuQX0Ymd2Q0bp105RnOR/UUtpQ6VM+TvHBsWOmPdOYvuWDiQN RU9i+cdSSa4gjRfsb2wdCzYrjWoqZUridKmW0tRjl8cwZHSDARXLSxYLng9iCeSVsVHN CIxkKJwazRSx/5IFeD4EzHH5fbN4jeHl/BMXgghnN+C1uicr35n7QFtxCnLOj2qzUREQ bT8aeATc64Lypw73j1AjfLa5zPz51jKxOMqHLkBfhsrSCWZjca+t7y1mQnxGEHSIEDVu aS4JciFrQOrcUe8eWQWutXDoMK2WQNyjWvA9fWp79I7iQZL6mKOPvGe6oheusMSV6QTm 09fg== MIME-Version: 1.0 X-Received: by 10.140.107.73 with SMTP id g67mr70065584qgf.103.1420377082637; Sun, 04 Jan 2015 05:11:22 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Sun, 4 Jan 2015 05:11:22 -0800 (PST) In-Reply-To: <54A583DD.9010602@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> Date: Sun, 4 Jan 2015 23:11:22 +1000 X-Google-Sender-Auth: 4ICCr9jo8ugemU006gvOovWnLxA Message-ID: From: Matthew Kerwin To: Sam Ruby Content-Type: multipart/alternative; boundary=001a113a7c027534c1050bd34f67 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/1WSek_RDkXQftPjH5yrC5XE466I Cc: Graham Klyne , IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jan 2015 13:11:25 -0000 --001a113a7c027534c1050bd34f67 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2 January 2015 at 03:29, Sam Ruby wrote: > On 01/01/2015 11:17 AM, Graham Klyne wrote: >> >> >> For some reason, I didn't see Larry's original comment. Probably >> overwhelmed. But I've just looked at >> https://specs.webplatform.org/url/webspecs/develop/ and: >> >> (a) noticed the same issue that Matthew just noted about the "big red >> box". >> > > I added that big red box. I encourage you to follow the following links: > > http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0526.html > > https://mailarchive.ietf.org/arch/msg/apps-discuss/ > KyxFLw2FCwv7CSpiWAmLr8Ha7vc > > It is my hope that by working together I can feel confident enough to > remove that red box. As it is, I don't feel that either spec matches > widely deployed applications. > =E2=80=8B > =E2=80=8B > > > So... are you advocating we make file: non-standard? That seems to be what both linked posts suggest. That would go with Dave Thaler's earlier proposition, that we move it to Historical, and get rid of it. Not exactly what I had in mind coming into this. --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a113a7c027534c1050bd34f67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 2 January 2015 at 03:29, Sam Ruby &= lt;rubys@intert= wingly.net> wrote:
On 01= /01/2015 11:17 AM, Graham Klyne wrote:

For some reason, I didn't see Larry's original comment.=C2=A0 Proba= bly
overwhelmed. But I've just looked at
https://specs.webplatform.org/url/webspecs/develop/ and:<= br>
(a) noticed the same issue that Matthew just noted about the "big red = box".

I added that big red box.=C2=A0 I encourage you to follow the following lin= ks:

http://lists.w3.org/Archives/Public/publi= c-webapps/2014OctDec/0526.html

https://mailarchive.ietf.org/arch/= msg/apps-discuss/KyxFLw2FCwv7CSpiWAmLr8Ha7vc

It is my hope that by working together I can feel confident enough to remov= e that red box.=C2=A0 As it is, I don't feel that either spec matches w= idely deployed applications.
=E2=80= =8B
=E2=80=8B


=

So... are you advocating we make file: non-standard? That = seems to be what both linked posts suggest. That would go with Dave Thaler&= #39;s earlier proposition, that we move it to Historical, and get rid of it= .

Not exactly what I had in mind com= ing into this.


--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwi= n.net.au/
--001a113a7c027534c1050bd34f67-- From nobody Sun Jan 4 05:20:48 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693591A88BF for ; Sun, 4 Jan 2015 05:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8bT0D-4cNhR for ; Sun, 4 Jan 2015 05:20:44 -0800 (PST) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DC6B1A88B4 for ; Sun, 4 Jan 2015 05:20:44 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id b13so15993927qcw.20 for ; Sun, 04 Jan 2015 05:20:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=k309RzrkthpGQ/c1LhDVSaa+ZDVyIbvK9p62ACQII6A=; b=mkCohFbUvkZ3vb+4cpLJMa4vF5W2L/NZ3KfzHuAXMBJa6M/Vn9N5lqkZUMZvd1QWQ5 73VyUKA5qmfzLymH+jgzo6ZAvd4xtjmOlD29Urd99Swg2u6fXSw2wLrmX/Fb2Dr4fgMs A4X9wJBunqSGKrKrJUXEUqB9O39xJ6LgaWiLel0tepv5KRzqdRGvECD3K6X50hzaIPUf v33xkH24RcPJHoaZsSKawiirQS04L5cLn9CbNLnc0dAp1So/X6nL9joSn/dojbVzEJKP YgMlg1f5186d6eBfM63sR1+X5KyAAMm7WgeLs+BJaMrb1dqwTwTZuUs27/IF9Jfy9FvL cCzw== MIME-Version: 1.0 X-Received: by 10.224.88.129 with SMTP id a1mr58005736qam.92.1420377643246; Sun, 04 Jan 2015 05:20:43 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Sun, 4 Jan 2015 05:20:43 -0800 (PST) In-Reply-To: <54A7DC46.2020708@ninebynine.org> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> <54A6AABF.4060406@ninebynine.org> <54A6B6DF.1010206@intertwingly.net> <54A7DC46.2020708@ninebynine.org> Date: Sun, 4 Jan 2015 23:20:43 +1000 X-Google-Sender-Auth: 9xb8763MnQocdjMZlCLMt76WVGw Message-ID: From: Matthew Kerwin To: Graham Klyne Content-Type: multipart/alternative; boundary=001a11c2c31edf6a71050bd37054 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/mXbiVTRzPoPCfuIbbFj2wa8rFeQ Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jan 2015 13:20:46 -0000 --001a11c2c31edf6a71050bd37054 Content-Type: text/plain; charset=UTF-8 On 3 January 2015 at 22:10, Graham Klyne wrote: > Sam, > > Rather than continue the blow-by-blow exchange of points, let me try and > respond in one place where I think we stand: > > > 1. I agree that draft-kerwin-file-scheme *should* work for everyone. And > that probably means reducing the scope of anything there that may be > considered normative. > > But I also believe it can be useful to document other behaviours > *informatively*. I think this is discussed elsewhere and anticipate > evolution in this direction. This could mean, to develop your example, > describing Microsoft Windows specific behaviours without any expectation > that such behaviours would be implemented by Apple. > > This is in the works. I've had a computer die, and been in full time vacation mode for the past month, so I'm a bit behind schedule, but I'll have something for folks to look at as soon as I can. > 4. I agree with your point about qualifying my statement about > system-dependent forms conforming to core URI syntax. While forms such as > "C:\Program Files (x86)" might be described as variations, I don't think > they should be considered to be valid URIs. > > I'm supportive of the strategy you outline (repeated here for ease of > reference), which I don't think is so different from what I've argued for: > > [[ > A strategy that is more likely to be successful would be to identify URIs > as being completely system independent, and URLs as being mostly system > independent, and for there to be a well known and documented mechanism for > converting from URLs to URIs. Even that is not likely to be completely > achieved -- the conversion may end up being (at least partially) system > dependent, but in such cases we should be able to define the problematic > set of the inputs as non-conforming. > ]] > -- https://mailarchive.ietf.org/arch/msg/apps-discuss/ > lNsLrE3xDYpo2GyvgHzGGZv-PLI > > Where I may diverge is that I don't think the "well known and documented > mechanism for converting from URLs to URIs" should be part of the URI > specification (cf. my point 2 above). > > Is there a reference somewhere that distinguishes URIs and URLs the way you guys are here? I thought URL was still a subset of URI. Has that changed? > > 5. The previous point also begs the question of what should be covered by > the file: scheme document. I think it may be appropriate to describe some > commonly occurring system-dependent file: URL forms, but I'm less convinced > that this is the place to describe how to map them to URIs. Any normative > specification of file: URI formats should be restricted to forms that > comply fully with RFC3986. > > Indeed. The normative core of the spec will be the pure RFC 3986-compatible parts; the non-normative appendices will include bad things like pipe characters and backslashes and such. I think it would be helpful to *suggest* how to map those to valid URIs, at the very least so people can update their old documents. -- Matthew Kerwin http://matthew.kerwin.net.au/ --001a11c2c31edf6a71050bd37054 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 3 January 2015 at 22:10, Graham Klyne <gk@ninebynine.org> wrote:<= /span>
Sam,

Rather than continue the blow-by-blow exchange of points, let me try and re= spond in one place where I think we stand:


1. I agree that draft-kerwin-file-scheme *should* work for everyone.=C2=A0 = And that probably means reducing the scope of anything there that may be co= nsidered normative.

=C2=A0 =C2=A0But I also believe it can be useful to document other behaviou= rs *informatively*.=C2=A0 I think this is discussed elsewhere and anticipat= e evolution in this direction.=C2=A0 This could mean, to develop your examp= le, describing Microsoft Windows specific behaviours without any expectatio= n that such behaviours would be implemented by Apple.


This is in the works. I'v= e had a computer die, and been in full time vacation mode for the past mont= h, so I'm a bit behind schedule, but I'll have something for folks = to look at as soon as I can.



4. I agree with your point about qualifying my statement about system-depen= dent forms conforming to core URI syntax.=C2=A0 While forms such as "C= :\Program Files (x86)" might be described as variations, I don't t= hink they should be considered to be valid URIs.

I'm supportive of the strategy you outline (repeated here for ease of r= eference), which I don't think is so different from what I've argue= d for:

[[
A strategy that is more likely to be successful would be to identify URIs a= s being completely system independent, and URLs as being mostly system inde= pendent, and for there to be a well known and documented mechanism for conv= erting from URLs to URIs.=C2=A0 Even that is not likely to be completely ac= hieved -- the conversion may end up being (at least partially) system depen= dent, but in such cases we should be able to define the problematic set of = the inputs as non-conforming.
 ]]
-- https://mailarchive.ietf.org/ar= ch/msg/apps-discuss/lNsLrE3xDYpo2GyvgHzGGZv-PLI

Where I may diverge is that I don't think the "well known and docu= mented mechanism for converting from URLs to URIs" should be part of t= he URI specification (cf. my point 2 above).


Is there a reference somewher= e that distinguishes URIs and URLs the way you guys are here? I thought URL= was still a subset of URI. Has that changed?

=C2=A0

5. The previous point also begs the question of what should be covered by t= he file: scheme document.=C2=A0 I think it may be appropriate to describe s= ome commonly occurring system-dependent file: URL forms, but I'm less c= onvinced that this is the place to describe how to map them to URIs.=C2=A0 = Any normative specification of file: URI formats should be restricted to fo= rms that comply fully with RFC3986.


Indeed. The normative core of the spec wil= l be the pure RFC 3986-compatible parts; the non-normative appendices will = include bad things like pipe characters and backslashes and such. I think i= t would be helpful to *suggest* how to map those to valid URIs, at the very= least so people can update their old documents.


--
=C2=A0 M= atthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a11c2c31edf6a71050bd37054-- From nobody Sun Jan 4 05:31:18 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A631A88D7 for ; Sun, 4 Jan 2015 05:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKGTcgwa1I9e for ; Sun, 4 Jan 2015 05:31:14 -0800 (PST) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5FC91A88C9 for ; Sun, 4 Jan 2015 05:31:12 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id r5so14763841qcx.27 for ; Sun, 04 Jan 2015 05:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=IxpSuSL2da1sND0jt5nGIC1j2BSJX9Opoo0jFXrS34U=; b=wRxuWkWea4VBqegfoS7797xwbexBMhH81TCeHzBvR+g6jHIGDwQ3pt8YJGBwRCGUWu QVMGniwfkgOI2sIGZi2/5up3FJFfRQnmeTS6A3cEDT8x7iVeKHBuKQwoLma8wWMCTiqM xNdPZFhdvM/f1Yv8x14b/QGH0+GyKnkgfSkHUQHUzG6vUtFsjOMyI0Ur9WOHp1NujBtE 6/EnMktew1X1F7eOU9guiSYexbehIpX04H1CdtakaSP+mEvSMeHdAI2mRoce2XzmPCfM Iszj/pm35+Cta6DJhv26N27cGjKHacQEjHmWb/5YzxjTvGYSw0Gl3bNGqU4I58d+3b8w 0C+A== MIME-Version: 1.0 X-Received: by 10.224.25.139 with SMTP id z11mr103460965qab.17.1420378272121; Sun, 04 Jan 2015 05:31:12 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Sun, 4 Jan 2015 05:31:12 -0800 (PST) In-Reply-To: <5494C6AF.4070902@intertwingly.net> References: <54922C81.4030908@intertwingly.net> <5494C6AF.4070902@intertwingly.net> Date: Sun, 4 Jan 2015 23:31:12 +1000 X-Google-Sender-Auth: cNG7awItYMF5rMbn9tRQiDPT0-k Message-ID: From: Matthew Kerwin To: Sam Ruby Content-Type: multipart/alternative; boundary=047d7bea31c45b4b5d050bd396ab Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/D8l-TR-T6y9p9bnysjfIoZZY7-g Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-kerwin-file-scheme and hosts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jan 2015 13:31:16 -0000 --047d7bea31c45b4b5d050bd396ab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So, finally getting around to replying to this... On 20 December 2014 at 10:45, Sam Ruby wrote: > =E2=80=8B=E2=80=8B > > The area I've chosen to focus on first is host names -- something that is > particularly thorny. The RFCs you reference don't quite capture all of t= he > necessary behavior. I encourage you to explore the following URIs. In > particular, I recommend exploring these with the Chrome browser: > > file://2130706433/foo > That's just silly. Sure, there's a code path for that in Chrome; does that mean every implementation out there must also parse decimal strings as big-endian IPv4 addresses? > file://[2001::1]/foo > I thought this already worked with RFC 3986..? See the "IP-literal" construct in , which is used in "host". > file:// > =E2=80=8B=E2=80=8B > =EF=BC=90=EF=BC=B8=EF=BD=83=EF=BC=90=EF=BC=8E=EF=BC=90=EF=BC=92=EF=BC=95= =EF=BC=90=EF=BC=8E=EF=BC=90=EF=BC=91/foo > > Note that the last one is using Unicode wide characters. An alternate > representation would be as follows: > > file://\uFF10\uFF38\uFF43\uFF10\uFF0E\uFF10\uFF12\uFF15\ > uFF10\uFF0E\uFF10\uFF11/foo > > There are no wide chars in a URI. That would be an IRI. --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --047d7bea31c45b4b5d050bd396ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So, finally getting around to replying to this...=

On 20 December 2014 at 10:45, Sam Ruby <rubys@intertwingly.net> wrote:
=E2=80=8B= =E2=80=8B

The area I've chosen to focus on first is host names= -- something that is particularly thorny.=C2=A0 The RFCs you reference don= 't quite capture all of the necessary behavior.=C2=A0 I encourage you t= o explore the following URIs.=C2=A0 In particular, I recommend exploring th= ese with the Chrome browser:

file://2130706433/foo

That'= ;s just silly. Sure, there's a code path for that in Chrome; does that = mean every implementation out there must also parse decimal strings as big-= endian IPv4 addresses?

=C2=A0
file://[2001::1]/foo

=C2=A0
file://
=E2=80=8B=E2=80=8B
=EF=BC=90=EF=BC=B8= =EF=BD=83=EF=BC=90=EF=BC=8E=EF=BC=90=EF=BC=92=EF=BC=95=EF=BC=90=EF=BC=8E=EF= =BC=90=EF=BC=91/foo

Note that the last one is using Unicode wide characters.=C2=A0 An alternate= representation would be as follows:

file://\uFF10\uFF38\uFF43\uFF10\uFF0E\uFF10\uFF12\uFF15\uFF10= \uFF0E\uFF10\uFF11/foo


There are no wide chars in a = URI. That would be an IRI.


-= -
=C2=A0 Matthew Kerwin=
=C2=A0 http= ://matthew.kerwin.net.au/
--047d7bea31c45b4b5d050bd396ab-- From nobody Sun Jan 4 05:33:04 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E530F1A88F8 for ; Sun, 4 Jan 2015 05:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4iCh0DjvxTI for ; Sun, 4 Jan 2015 05:32:59 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.228]) by ietfa.amsl.com (Postfix) with ESMTP id B3FFC1A88D6 for ; Sun, 4 Jan 2015 05:32:59 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:19881] helo=rubix) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 37/E8-30224-A0149A45; Sun, 04 Jan 2015 13:32:59 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id B541B140A15; Sun, 4 Jan 2015 08:32:57 -0500 (EST) Message-ID: <54A94109.5010901@intertwingly.net> Date: Sun, 04 Jan 2015 08:32:57 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/UWt8buXMThittnu6_vpwzW0EGKg Cc: IETF Apps Discuss , Larry Masinter Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jan 2015 13:33:02 -0000 On 01/04/2015 07:22 AM, Matthew Kerwin wrote: > > On 2 January 2015 at 00:21, Sam Ruby > wrote: > > A few concrete examples are here: > > http://www.ietf.org/mail-__archive/web/apps-discuss/__current/msg13511.html > > > It is my hope that by comparing notes we can converge. > > ​To be honest, a big reason for using RFC 3986 as a normative reference > is so I don't have to deal with things like hostnames. If those > definitions are good enough for the shiny new HTTP/1.1 (which actually > uses hostnames) then surely they're also sufficient for file: (which > often doesn't). > > BTW who on earth writes localhost as "2130706433"? Or more > significantly, who on earth *accepts* that as a valid URL? I cited three specific examples in: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13511.html All three of the below are accepted by Chrome, and possibly others: file://2130706433/foo file://[2001::1]/foo file://０Ｘｃ０．０２５０．０１/foo Note that RFC 3986 requires square brackets around IPv6 names, but your draft does not. The final example involves IDNA processing. Unfortunately, IDNA processing can't be avoided, nor does RFC 3986 specify it. > I guess I could add support for backslashes. I suspect that > would end up > in a non-normative appendix, along with the "|" drive letter > separator > (as suggested in an earlier message, and currently being worked > into the > next draft.) > > > I don't understand the thought process here. The current > Internet-Draft takes care to document a select few browser specific > syntaxes, but many others (including the ones you mention above) are > not included. What is the selection criteria you are using? > > For the most part: things that aren't silly (big-endian integer encoding > of IPv4 addresses), things that aren't widely touted as obsolete (like > backslashes[1]), and as much as possible, things that go against the > parent standards (like trying to jimmy "/c|/" into RFC 3986). > > Importantly, I don't want to include every codepath in every > implementation that exists, but I don't want the definition I write to > *not* work in any implementations. > > [1] http://blogs.msdn.com/b/ie/archive/2006/12/06/file-uris-in-windows.aspx You have a definition for a "windows-path" and a "unc-path". These are unlikely to work on Android or OS/X. Firefox does not appear to support host for file: URIs. > -- > Matthew Kerwin > http://matthew.kerwin.net.au/ - Sam Ruby From nobody Sun Jan 4 05:47:26 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158421A8904 for ; Sun, 4 Jan 2015 05:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zo9uuYDlt8-Z for ; Sun, 4 Jan 2015 05:47:23 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.232]) by ietfa.amsl.com (Postfix) with ESMTP id E841A1A88FC for ; Sun, 4 Jan 2015 05:47:22 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:21821] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 75/BE-04279-96449A45; Sun, 04 Jan 2015 13:47:22 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 8658B140A15; Sun, 4 Jan 2015 08:47:20 -0500 (EST) Message-ID: <54A94468.4010504@intertwingly.net> Date: Sun, 04 Jan 2015 08:47:20 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Rhu7xP-C8KuCB7D6ajZjNddCXl0 Cc: Graham Klyne , IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jan 2015 13:47:25 -0000 On 01/04/2015 08:11 AM, Matthew Kerwin wrote: > > > On 2 January 2015 at 03:29, Sam Ruby > wrote: > > On 01/01/2015 11:17 AM, Graham Klyne wrote: > > > For some reason, I didn't see Larry's original comment. Probably > overwhelmed. But I've just looked at > https://specs.webplatform.org/__url/webspecs/develop/ > and: > > (a) noticed the same issue that Matthew just noted about the > "big red box". > > > I added that big red box. I encourage you to follow the following > links: > > http://lists.w3.org/Archives/__Public/public-webapps/__2014OctDec/0526.html > > > https://mailarchive.ietf.org/__arch/msg/apps-discuss/__KyxFLw2FCwv7CSpiWAmLr8Ha7vc > > > It is my hope that by working together I can feel confident enough > to remove that red box. As it is, I don't feel that either spec > matches widely deployed applications. > > So... are you advocating we make file: non-standard? That seems to be > what both linked posts suggest. That would go with Dave Thaler's earlier > proposition, that we move it to Historical, and get rid of it. > > Not exactly what I had in mind coming into this. Some indeed are proposing essentially that. I'm not: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27518#c1 What I will say is that if you drop normative statements concerning things that aren't interoperable (like hosts and windows paths), you end up with a rather small specification. > -- > Matthew Kerwin > http://matthew.kerwin.net.au/ - Sam Ruby From nobody Sun Jan 4 05:47:56 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F181A8902 for ; Sun, 4 Jan 2015 05:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVeuFEPplTBq for ; Sun, 4 Jan 2015 05:47:53 -0800 (PST) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A45361A88B2 for ; Sun, 4 Jan 2015 05:47:53 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id i17so14518701qcy.32 for ; Sun, 04 Jan 2015 05:47:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5RrvXa1x+rl9lsQg/bUjQdyWfD3P0yVgUA+Wc5N8Ud8=; b=fClbbQwkuysW6HnlCdhKcLWTYyCeWjVegEESqjZ/OJ1QBUwRclAs7gn0dti8PNshud Cm4unHMpTPY5fDD7MXlYiFGYMoUG/ZUlyKrPOvZxw+yWdA7pmUKXFM6qmdhpI8M8rZMD /leGRM6XNnLF63pOcNKry5CgxGFT7f05J+Mf2EfYpYLJRAR/5NnbBQmTOtm4Zs/NBFT9 uouFYBg3/nBPHceztvMzrnBFv+L5QW+Z+YrVTgKp1cB60iFIwFISzoPUN72ctJFklDW2 nmJUmb5UaKUVJbsZlwkADkIjXg3V+36GYZ1WvGc2Dp+we+yCSU8XT6zr0RcwgiXuw1dP yQSQ== MIME-Version: 1.0 X-Received: by 10.224.25.139 with SMTP id z11mr103550774qab.17.1420379272853; Sun, 04 Jan 2015 05:47:52 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Sun, 4 Jan 2015 05:47:52 -0800 (PST) In-Reply-To: <54A94109.5010901@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> Date: Sun, 4 Jan 2015 23:47:52 +1000 X-Google-Sender-Auth: K_qHVoPCY8U8jVBvRmFtG13-P3k Message-ID: From: Matthew Kerwin To: Sam Ruby Content-Type: multipart/alternative; boundary=047d7bea31c4014216050bd3d29b Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XXYRY26c1a1wgrW8mchtC-f9WM4 Cc: IETF Apps Discuss , Larry Masinter Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jan 2015 13:47:55 -0000 --047d7bea31c4014216050bd3d29b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4 January 2015 at 23:32, Sam Ruby wrote: > >> For the most part: things that aren't silly (big-endian integer encoding >> of IPv4 addresses), things that aren't widely touted as obsolete (like >> backslashes[1]), and as much as possible, things that go against the >> parent standards (like trying to jimmy "/c|/" into RFC 3986). >> >> Importantly, I don't want to include every codepath in every >> implementation that exists, but I don't want the definition I write to >> *not* work in any implementations. >> >> [1] http://blogs.msdn.com/b/ie/archive/2006/12/06/file-uris- >> in-windows.aspx >> > > You have a definition for a "windows-path" and a "unc-path". These are > unlikely to work on Android or OS/X. > =E2=80=8B=E2=80=8B > > =E2=80=8B > =E2=80=8B They can (and should) parse them. Then they can (and should) fail to open them. What's wrong with that? To get rid of "windows-path", as I said earlier tonight, if someone can give me better text to deal with roots then by all means please do so. =E2=80=8B > > =E2=80=8B=E2=80=8B > Firefox does not appear to support host for file: URIs. > =E2=80=8B=E2=80=8B > Firefox does a couple of things in its own way. I've wavered back and forth about whether it's "file://host/path" or "file:////host/path" (or "file://///host/path" as Firefox says), and in the end I went with the one that seems to be fairy widely (if not universally) supported, and in the spirit of how URIs work in the modern age. There's an open bug somewhere about how Firefox interprets UNC-type file: URIs. Perhaps if this draft gets published, in some form or other, that will be the catalyst required to get said bug fixed/resolved. --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --047d7bea31c4014216050bd3d29b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 4 January 2015 at 23:32, Sam Ruby &= lt;rubys@intert= wingly.net> wrote:

For the most part: things that aren't silly (big-endian integer encodin= g
of IPv4 addresses), things that aren't widely touted as obsolete (like<= br> backslashes[1]), and as much as possible, things that go against the
parent standards (like trying to jimmy "/c|/" into RFC 3986).

Importantly, I don't want to include every codepath in every
implementation that exists, but I don't want the definition I write to<= br> *not* work in any implementations.

[1] http://blogs.msdn.com/b/ie/archive/20= 06/12/06/file-uris-in-windows.aspx

You have a definition for a "windows-path" and a "unc-path&q= uot;.=C2=A0 These are unlikely to work on Android or OS/X.
=E2=80=8B=E2=80=8B

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

They can (and should) p= arse them. Then they can (and should) fail to open them. What's wrong w= ith that?

To get rid of "windows-path= ", as I said earlier tonight, if someone can give me better text to de= al with roots then by all means please do so.


=E2=80=8B

=E2=80=8B=E2=80=8B
Firefox does not appear to = support host for file: URIs.
=E2= =80=8B=E2=80=8B

= Firefox does a couple of things in its own way. I've wavered back and f= orth about whether it's "file://host/path" or "file:////= host/path" (or "file://///host/path" as Firefox says), and i= n the end I went with the one that seems to be fairy widely (if not univers= ally) supported, and in the spirit of how URIs work in the modern age. Ther= e's an open bug somewhere about how Firefox interprets UNC-type file: U= RIs. Perhaps if this draft gets published, in some form or other, that will= be the catalyst required to get said bug fixed/resolved.



--
=
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--047d7bea31c4014216050bd3d29b-- From nobody Sun Jan 4 05:54:32 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60121A88B1 for ; Sun, 4 Jan 2015 05:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m_vVBVGGGKSH for ; Sun, 4 Jan 2015 05:54:29 -0800 (PST) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1001A88D7 for ; Sun, 4 Jan 2015 05:54:27 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id k15so11854851qaq.35 for ; Sun, 04 Jan 2015 05:54:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=s2NbU4CLESzx1RNznH6apK8X4W40uWPoKpB2hoYBsjo=; b=ydMDo/Pp/ZXgYSBIBHRgEGVRl8poWHjok8zKovfR8milmesII0uADCrOeWAuvqJoiw l0Xzo/jYnR24hSS5LmiKykqslY08kWC+B3GgufX4DD10Ww6W0SKnZ4B1KwdgpI6hd+fO 6Y0CXa+fsqzkfIV5rAIK1a3AswkkZmxwpelqW9suzOzOdBPbfLqEWX6uBOJkwUygNeQV xl4Oy1ntxH2X+qg9/Jw5UALQnoCW5ZirkC3x804DA0hw11UHpQBORirPJmHWD7d5VXit wgcLmJXE0U3U71u4ICUvCZXLBSyfOYnfQ9HF2xBzU0egtolV3W9XUxDNxmI7WRy09ruD +D6g== MIME-Version: 1.0 X-Received: by 10.229.249.137 with SMTP id mk9mr137351066qcb.4.1420379666871; Sun, 04 Jan 2015 05:54:26 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Sun, 4 Jan 2015 05:54:26 -0800 (PST) In-Reply-To: <54A94468.4010504@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A94468.4010504@intertwingly.net> Date: Sun, 4 Jan 2015 23:54:26 +1000 X-Google-Sender-Auth: HPLzmSyhFUU6XQNzTODOX-jdat0 Message-ID: From: Matthew Kerwin To: Sam Ruby Content-Type: multipart/alternative; boundary=001a11334d907d7eb8050bd3e953 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tmQK88RKE_XS4OouYGNPnHISeTg Cc: Graham Klyne , IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jan 2015 13:54:31 -0000 --001a11334d907d7eb8050bd3e953 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4 January 2015 at 23:47, Sam Ruby wrote: > > What I will say is that if you drop normative statements concerning thing= s > that aren't interoperable (like hosts and windows paths), you end up with= a > rather small specification. > > I'm working on it. <=E2=80=8B https://github.com/phluid61/internet-drafts/blob/15-separate-norm-inform/fi= le-scheme/draft.md >=E2=80=8B --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11334d907d7eb8050bd3e953 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 4 January 2015 at 23:47, Sam Ruby <rubys@intertwingly.net= > wrote:

What I will say is that if you drop normative statements concerning things = that aren't interoperable (like hosts and windows paths), you end up wi= th a rather small specification.


I= 'm working on it. <=E2=80=8Bhttps://g= ithub.com/phluid61/internet-drafts/blob/15-separate-norm-inform/file-scheme= /draft.md>=E2=80=8B


--
=C2=A0 Matthew Kerwin
=C2= =A0 http://matt= hew.kerwin.net.au/
--001a11334d907d7eb8050bd3e953-- From nobody Sun Jan 4 10:49:52 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE111A8A54 for ; Sun, 4 Jan 2015 10:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agQz9CwuTMq8 for ; Sun, 4 Jan 2015 10:49:49 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id CE08A1A8A55 for ; Sun, 4 Jan 2015 10:49:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1420397388; d=isode.com; s=selector; i=@isode.com; bh=Z+gtD7wI/gYQQ4WWbk7MeQu3E6zCx9TgKhlTboOBBv4=; 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=WaRhQkQh/qr4EgfBmQDkoirvrGP0ScR/ss42egHXoAgvqBpK8y7OOsRXJ51ewjJTdJcJDa 4HgPnCGwcsdOSNS1Tchqfq1fs/f5d2dh3DREXC+uHDfYc+tEW3Jsi0XsYkKNjrkWVnPTYN uNRq2DUONF0ezDf2rYbuDH5qgF+J6G0=; Received: from [192.168.0.5] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 4 Jan 2015 18:49:47 +0000 Message-ID: <54A984DE.3020504@isode.com> Date: Sun, 04 Jan 2015 18:22:22 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: Larry Masinter , IETF Apps Discuss References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/DnzVTTSSpBdrG1hAWmIlaow8iIA Subject: Re: [apps-discuss] uri-scheme-reg rules for updating a permanent scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Jan 2015 18:49:51 -0000 On 02/01/2015 02:46, Larry Masinter wrote: > In talking about kerwin-file-scheme, it was claimed: >> The BCP for registering schemes appears not to require an RFC, only Expert Review. > but > http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-03#section-7.3 > > Registrations can be updated in the registry by the same mechanism as > required for an initial registration. In cases where the original > definition of the scheme is contained in an IESG-approved document, > update of the specification also requires IESG approval. > > IESG approval (usually) happens by approval of something for publication as an RFC. > Should this be more explicit? How else could someone ask for IESG approval? IESG can issue Last Call and approve a URI update as a management item. For example if the updated document becomes a W3C document. > Shouldn't there be guidelines for updates to a registration that > talks about review against widely deployed implementations? > > For example, requirements that updates SHOULD > * significantly improve the match with deployed implementations, and/or > * note, as an interoperability consideration, wide deployments > that don't match, and > * have evidence of review by those responsible for with > updates to current implementations, with confidence that > they will conform to the new spec. I am not against that, but this sounds a bit of a rathole. From nobody Mon Jan 5 16:12:40 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470721A9095 for ; Mon, 5 Jan 2015 16:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0nk6gfOVbwg for ; Mon, 5 Jan 2015 16:12:33 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0064.outbound.protection.outlook.com [65.55.169.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D15DF1A909B for ; Mon, 5 Jan 2015 16:12:32 -0800 (PST) Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) with Microsoft SMTP Server (TLS) id 15.1.49.12; Tue, 6 Jan 2015 00:12:31 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) by DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) with mapi id 15.01.0049.002; Tue, 6 Jan 2015 00:12:31 +0000 From: Larry Masinter To: "dcrocker@bbiw.net" , Lyndon Nerenberg Thread-Topic: [apps-discuss] Gopher updated spec Thread-Index: AQHQJgcQM/zijmyhFU6NgiZg6zojDJyrzS6AgAAEUwCAAFQQAA== Date: Tue, 6 Jan 2015 00:12:30 +0000 Message-ID: References: <075D7793E42A501B9B9A014D@P5> <54A5C434.6080806@dcrocker.net> In-Reply-To: <54A5C434.6080806@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:9:8380:992:1871:9a36:2010:c6e5] authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DM2PR0201MB0960; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB0960; x-forefront-prvs: 0448A97BF2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(74316001)(54206007)(122556002)(4396001)(19300405004)(19580395003)(15395725005)(33656002)(40100003)(92566001)(20776003)(64706001)(21056001)(2501002)(97736003)(101416001)(99396003)(2656002)(87936001)(50986999)(120916001)(54356999)(76176999)(54606007)(106356001)(99286002)(106116001)(105586002)(77156002)(31966008)(1720100001)(68736005)(62966003)(107046002)(2900100001)(86362001)(102836002)(15975445007)(2420400003)(76576001)(46102003)(2950100001)(3826002)(562404015); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0960; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2015 00:12:30.7428 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB0960 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/V3iwffm3GOB94T72IC88SIHkU0c Cc: Nick Matavka , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Gopher updated spec X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2015 00:12:35 -0000 SSd2ZSB3cml0dGVuIGFib3V0IHVwZGF0ZXMgdG8gd2lkZWx5IGRlcGxveWVkIHNjaGVtZXM7IEkg ZG9uJ3QgdGhpbmsNCidnb3BoZXI6JyBxdWFsaWZpZXMgYXMgJ3dpZGVseS1kZXBsb3llZCcsIGJ1 dCBtb3N0IG9mIHdoYXQgSSBzYWlkIGFwcGxpZXMuDQoNCklmIHRoZSBnb2FsIGlzIHRvIHByb3Zp ZGUgc29tZSBoaXN0b3JpY2FsIGJhY2tncm91bmQsIHRoZXJlIGFyZSBiZXR0ZXINCnBsYWNlcyB0 byBkbyBzbyB0aGFuIGFuIEludGVybmV0IERyYWZ0IC8gUkZDLCBlLmcuLCANCmh0dHA6Ly9lbi53 aWtpcGVkaWEub3JnL3dpa2kvR29waGVyXyUyOHByb3RvY29sJTI5DQoNCj4gQXQgdGhlIHRpbWUs IG9ubHkgaHRtbCBkb2N1bWVudHMgY291bGQgYmUgcHVibGlzaGVkIGZvciB0aGUgd2ViLCB3aGls ZQ0KPiBnb3BoZXIgd2FzIHRleHQgYmFzZWQuICBTbyBpdCB3YXMgZWFzaWVyIHRvIHB1Ymxpc2gg dGhyb3VnaCBnb3BoZXIsDQo+IGFsYmVpdCBkb2N1bWVudHMgd2VyZW4ndCBhcyBwcmV0dHkuDQoN CmdvcGhlciBoYWQgbm9uLXRleHQgZG9jdW1lbnRzICh1c2luZyBhIDEgYnl0ZSB0eXBlIGNvZGUs IHNlc2UNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzE0MzYgc2VjdGlvbiAzLjgpLA0K d2hpbGUgZ29waGVyKyB1c2VkIE1JTUUsIGFzIGRpc2N1c3NlZCBpbiAxOTkzIEdvcGhlckNvbi4N Cmh0dHA6Ly9wcmVudGlzc3JpZGRsZS5jb20vdHJpcHMvZ29waGVyY29uMTk5My5odG1sDQoNCkxh cnJ5DQotLQ0KaHR0cDovL2xhcnJ5Lm1hc2ludGVyLm5ldA0KDQo= From nobody Tue Jan 6 13:59:36 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8891A873B for ; Tue, 6 Jan 2015 13:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOm9jsfdJJGV for ; Tue, 6 Jan 2015 13:59:32 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0072.outbound.protection.outlook.com [207.46.100.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D509C1A872F for ; Tue, 6 Jan 2015 13:59:32 -0800 (PST) Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0957.namprd02.prod.outlook.com (25.160.216.25) with Microsoft SMTP Server (TLS) id 15.1.49.12; Tue, 6 Jan 2015 21:59:29 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) by DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) with mapi id 15.01.0049.002; Tue, 6 Jan 2015 21:59:29 +0000 From: Larry Masinter To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , "Bjoern Hoehrmann" Thread-Topic: does URL parsing result in Unicode strings or in ASCII strings? Thread-Index: AdAp9z3pCBDBWQ1+Tlu/LtWdkoK4qQ== Date: Tue, 6 Jan 2015 21:59:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:9:8380:992:1871:9a36:2010:c6e5] authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DM2PR0201MB0957; x-forefront-prvs: 0448A97BF2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(51704005)(19580395003)(19580405001)(99396003)(101416001)(120916001)(20776003)(62966003)(2900100001)(64706001)(74316001)(77156002)(40100003)(106356001)(105586002)(33656002)(87936001)(4396001)(122556002)(99286002)(54356999)(31966008)(50986999)(54206007)(54606007)(92566001)(107046002)(102836002)(21056001)(15975445007)(97736003)(2656002)(76576001)(229853001)(86362001)(46102003)(68736005)(7059030)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0957; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2015 21:59:29.4223 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB0957 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/igS05aO0NWiq8i47R8cOpbOSS60 Cc: "julian.reschke@gmx.de" , Mark Nottingham , "apps-discuss@ietf.org" Subject: [apps-discuss] does URL parsing result in Unicode strings or in ASCII strings? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jan 2015 21:59:35 -0000 VGhpcyBpcyBmcm9tIGEgY29udmVyc2F0aW9uIG9uIHB1YmxpYy1pZXRmLXczY0B3My5vcmcgKEJD QydkKQ0KUmU6IFt1cmxdIFJlcXVlc3RzIGZvciBGZWVkYmFjayAod2FzIEZlZWRiYWNrIGZyb20g VFBBQykNCg0KTWFydGluOg0KPiA+PiBUaGUgVVJMIHNwZWMsIGFzIGZhciBhcyBJIHVuZGVyc3Rh bmQsIGFsbG93cyBVbmljb2RlIGFzIGlucHV0LCBzbyBpbg0KPiA+PiB0aGF0IHJlc3BlY3QsIGl0 IGlzbid0IGdoZXR0b2l6aW5nLiBCdXQgaXQgY29udmVydHMgYWxsIG91dHB1dCB0byBBU0NJSSwN Cj4gPj4gYW5kIHNvIGVzc2VudGlhbGx5IHNlbmRzIGEgbWVzc2FnZSB0aGF0IFVuaWNvZGUgaXMg c2Vjb25kLWNsYXNzLg0KPiA+Pg0KPiA+PiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIHJl YXNvbiBmb3IgdGhpcyBpcyB0aGF0IGN1cnJlbnQgYnJvd3Nlcg0KPiA+PiBpbnRlcmZhY2VzIGFy ZSB3b3JraW5nIHRoYXQgd2F5LCBhbmQgSSdtIG5vdCBhZ2FpbnN0IGRvY3VtZW50aW5nIHRoYXQs DQo+ID4+IGJ1dCBJJ2Qgd2lzaCB3ZSBjb3VsZCBnZXQgYXdheSBmcm9tIHRoYXQgbGltaXRhdGlv biBmb3IgdGhlIGdlbmVyYWwgY2FzZQ0KPiA+PiAoaS5lLiBwYXJzZXIgcmVzdWx0cyBhcmUgc3Rp bGwgVW5pY29kZSkuDQoNCldlIHNob3VsZCBub3QgZXZhbHVhdGUgcHJvdG9jb2wgY2hvaWNlcyBi eSBjb25zaWRlcmluZw0Kd2hldGhlciBzb21ldGhpbmcgInNlbmRzIGEgbWVzc2FnZSIgb3Igd2hh dCBzb3VuZHMgbGlrZQ0KYW4gYXBwZWFsIG5vdCB0byBtYWtlIFVuaWNvZGUgInNlY29uZC1jbGFz cyIuDQpCYWQsIG5vbi1pbnRlcm9wZXJhYmxlIGRlc2lnbiAic2VuZHMgYSBtZXNzYWdlIi4NCg0K SW4gZmFjdCwgVVJMcyB3aGVuIGludmVudGVkIHdlcmUgQVNDSUkgb25seSwgYW5kIHRoZSBvbmx5 DQptZXNzYWdlIHdlIHNob3VsZCBzZW5kIGlzIHRoYXQgdXBncmFkaW5nIGZyb20gQVNDSUkNCnRv IFVuaWNvZGUgaXNuJ3Qgc2ltcGx5IGEgbWF0dGVyIG9mIGluY3JlYXNpbmcgdGhlIHJlcGVydG9p cmUuDQpZZXMsIFVuaWNvZGUgaXMgc2Vjb25kLiANCg0KU2FtOg0KPiA+IFRoZXJlIGFyZSBhIGNv dXBsZSBvZiBjb25mbGljdGluZyByZXF1aXJlbWVudHMgdGhhdCBtYWtlIHRoYXQgZGlmZmljdWx0 Lg0KPiA+IElmIHlvdSBtYWtlIGFuIEFQSSBmb3IgcmVzb3VyY2UgaWRlbnRpZmllcnMsIHlvdSBk b24ndCB3YW50IGl0IHRvIGNoYW5nZQ0KPiA+IGJlaGF2aW9yIHdoZW4gbmV3IHNjaGVtZXMgYXJl IGludHJvZHVjZWQ7IHlvdSBwcm9iYWJseSBhbHNvIHdhbnQgdGhhdCBhbg0KPiA+IGlucHV0IGxp a2UgYGV4YW1wbGU6Ly8vw7ZgIGlzIGhhbmRsZWQgdGhlIHNhbWUgYXMgYGV4YW1wbGU6Ly8vJWMz JWI2YCBhbmQNCj4gPiB0aGVuIGFsc28gYXZvaWQgdHVybmluZyBgZGF0YTppbWFnZS9wbmcsLi4u JXh4Li4uYCBpbnRvIGEgbWl4IG9mIHJhbmRvbQ0KPiA+IFVuaWNvZGUgY2hhcmFjdGVycyBpbnRl cnNwZXJzZWQgd2l0aCAleHggZXNjYXBlcyB0aGF0IHdvdWxkIG5vdCByb3VuZC0NCj4gPiB0cmlw IGlmIGRlY29kZWQuIElmIHlvdSB3YW50IFVuaWNvZGUgb3V0cHV0LCBhbmQgYSBkYXRhLWxpa2Ug c2NoZW1lIGlzDQo+ID4gaW50cm9kdWNlZCwgeW91IGNhbm5vdCBzYXRpc2Z5IGFsbCByZXF1aXJl bWVudHMuDQoNCk1hcnRpbjoNCj4gVGhpcyBpcyBpbmRlZWQgYSB0aGVvcmV0aWNhbCBwcm9ibGVt LCBidXQgb25lIHRoYXQgaW4gcHJhY3RpY2UgcmFyZWx5DQo+IHNob3dzIHVwIGFuZCBpcyByYXRo ZXIgZWFzaWx5IGRlYWx0IHdpdGguDQo+IA0KPiBGaXJzdCwgZGF0YTotbGlrZSBzY2hlbWVzIGFy ZSBmZXcgYW5kIGZhciBiZXR3ZWVuLg0KDQphKSBFaXRoZXIgdGhlIHVzZSBjYXNlcyBhcmUgaW4g c2NvcGUgb3IgdGhleSdyZSBub3QuIElmIHRoZXkncmUgaW4gc2NvcGUgdGhlbiB0aGVpciByZXF1 aXJlbWVudHMgbXVzdA0KYmUgbWV0LiAiRmV3IGFuZCBmYXIgYmV0d2VlbiIgYnkgd2hhdCBtZWFz dXJlPyBBbmQgaG93IGRvIHlvdSAiZWFzaWx5IGRlYWwgd2l0aCIgdW5wcmVkaWN0YWJsZSBuZXcg c2NoZW1lcyB3aGljaCBhcmUga25vd24gdG8gdmVyeSB3aWRlbHkgZGVwbG95ZWQgVVJMIHBhcnNl cnM/DQoNCihJIHRoaW5rIHRoZXJlJ3MgYSBjbHVlIGhlcmUgYWJvdXQgJ3doeSBVUkwgc2hvdWxk bid0IGJlIGEgTGl2aW5nIFN0YW5kYXJkJyBiZWNhdXNlIHRoZXJlIGFyZSBvcmRlcnMgb2YgbWFn bml0dWRlIG1vcmUgZGVwbG95ZWQgaW1wbGVtZW50YXRpb25zLikNCg0KPiBTZWNvbmQsIHRoZXJl J3Mgbm8gcmVhc29uIHRvIGNvbnZlcnQgdG8gVW5pY29kZSBzZXF1ZW5jZXMgb2YgJXh4IHRoYXQN Cj4gY2FuJ3QgYmUgY29udmVydGVkIGluIGZ1bGwuDQoNClRoaXMgbGVhdmVzIGEgY29tcGxleCBh bmQgdW5zdGFibGUgcXVlc3Rpb24gb2Ygd2hpY2ggc2VxdWVuY2VzIHNob3VsZCBvciBzaG91bGRu J3QgYmUgY29udmVydGVkLCBvciBjYW4ndCBiZSAiaW4gZnVsbCIuICAgIEl0IGxlYXZlcyBtYW55 IHBvc3NpYmxlIHJlc3VsdHMgcmF0aGVyIHRoYW4gYSBjYW5vbmljYWwgb25lLiANCg0KPiBUaGly ZCwgdGhlIGVxdWl2YWxlbmNlIGJldHdlZW4gIsO2IiBhbmQgIiVjMyViNiIgbWlnaHQgYmUgcHJv dmlkZWQgYXQNCj4gYSBoaWdoZXIgbGV2ZWwgaW4gdGhlIEFQSSwgYmVjYXVzZSAiaXMgaGFuZGxl ZCB0aGUgc2FtZSIgYXNzdW1lcyBhDQo+IHVuaXZlcnNhbCBlcXVpdmFsZW5jZSBmdW5jdGlvbiBm b3IgVVJJcyBhbmQgSVJJcyB3aGVuIHRoZSBzcGVjcyBjbGVhcmx5DQo+IGV4cGxhaW4gdGhhdCB0 aGVyZSBpcyBubyBzdWNoIHRoaW5nIChzZWUNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjMzk4NiNzZWN0aW9uLTYgYW5kDQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM5 ODcjc2VjdGlvbi01KS4NCg0KMzk4Ni8zOTg3IG9uIGVxdWl2YWxlbmNlIGhhdmUgcHJvYmxlbXMs IHdoaWNoIGlzIHdoeSBJIHNwbGl0IG91dCBlcXVpdmFsZW5jZSBpbnRvIGEgc2VwYXJhdGUgZG9j dW1lbnQuDQpJIGRvbid0IHRoaW5rIGl0IGlzIHByb2R1Y3RpdmUgb3IgdXNlZnVsIHRvIHByb3Zp ZGUgYW4gQVBJIHdoaWNoIG1ha2VzIGl0IGVhc3kgdG8gZGlzdGluZ3Vpc2ggdGhlIGlucHV0IGZv cm0gb2YgVVJMIGFtb25nICJodHRwOiIgYW5kICJIVFRQOiIgb3IgIGJldHdlZW4gIsO2IiBhbmQg IiVjMyViNiIuDQoNClNpbmNlIGhvc3RuYW1lIHB1bnljb2RlIGhhcyB0byBiZSBoYW5kbGVkIGF0 IHRoaXMgbGV2ZWwsIGVuY29kaW5nIG9mIG90aGVyIHBhcnRzIG9mIHRoZSBVUkwgc2hvdWxkIGJl LCB0b28uDQoNCg0K From nobody Wed Jan 7 08:57:14 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A5F1A0055 for ; Wed, 7 Jan 2015 08:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFNB5Xj4e1hJ for ; Wed, 7 Jan 2015 08:57:07 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 918CB1A0089 for ; Wed, 7 Jan 2015 08:57:07 -0800 (PST) Received: from [192.168.1.194] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LlDx4-1XZHyj3rz4-00b4Oq; Wed, 07 Jan 2015 17:56:56 +0100 Message-ID: <54AD6554.7080304@gmx.de> Date: Wed, 07 Jan 2015 17:56:52 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , Stephen Farrell References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> <54A6AABF.4060406@ninebynine.org> <54A6B6DF.1010206@intertwingly.net> <54A7DC46.2020708@ninebynine.org> <54A7E9F4.80406@intertwingly.net> <54A820EA.20200@ninebynine.org> <54A82CC4.9080606@intertwingly.net> <54A83B72.4010106@cs.tcd.ie> <54A8550A.1020708@intertwingly.net> In-Reply-To: <54A8550A.1020708@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:fdugLlLOSljeOmjygP4NNY0zaARX26ohZBewj/AEs5LSS+MWKOW oOoRzS+J5zxRXJmqXVRGNPXor6Rhd3eKC3nWUqSpduM/lHXHodv/bdZIe2ZEF8S/CROZgHZ ONTYW8qi2vXutKGYEVSoiVmQjYkdh0nG70jaE7Q3JnmEmq9qKu/lrxzra43asokzJ7Frt2v HhlBXGOAkODg8GbV5ob0g== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iS3ElDPZAd1eTBkWlaA8SVX69zg Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] presumption that RFC3986 is correct X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2015 16:57:13 -0000 On 2015-01-03 21:46, Sam Ruby wrote: > ... > The longer answer isn't all that much longer. Given that every modern > programming language (and for that matter, every browser) will have a > part of their runtime library a concept of either a URI or a URL, and a > method to parse a string into such a structure, the question you pose is > equivalent to: "how should URI.parse methods handle unknown schemes"? > > Possible answers include: treat the content as hierarchical, and treat > the content as opaque. There may be other answers. > ... Such as: treat everything the same (as per RFC 3986). Best regards, Julian From nobody Wed Jan 7 08:58:03 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E311A009E for ; Wed, 7 Jan 2015 08:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdrbRUoqAmk6 for ; Wed, 7 Jan 2015 08:58:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 513851A0012 for ; Wed, 7 Jan 2015 08:58:00 -0800 (PST) Received: from [192.168.1.194] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lp7d2-1Xd9Xd0Vfg-00etUY; Wed, 07 Jan 2015 17:57:57 +0100 Message-ID: <54AD6592.1020101@gmx.de> Date: Wed, 07 Jan 2015 17:57:54 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , Graham Klyne References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> <54A6AABF.4060406@ninebynine.org> <54A6B6DF.1010206@intertwingly.net> <54A7DC46.2020708@ninebynine.org> <54A7E9F4.80406@intertwingly.net> <54A820EA.20200@ninebynine.org> <54A82CC4.9080606@intertwingly.net> In-Reply-To: <54A82CC4.9080606@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ep1qj2ixpQRE6gUsuDTGWyayOldB3/8zrGtzMSrAb+EPsooGMvn dA8skUF2ui+SIXxpUr/5TheO+HP3XB8GDjIckUIOWo1kVNk9wOKgol23O/YAfDh8urbQ9a5 EW3+iyqP77PChDzzqQocdcjLl5RGi7Vz036LP6fDUBXxJwTxBPD4urC0Ol6Hz59PJ9XCXH7 PpZZMMjKf8QDT9PYEPCDA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8CxoRtxE8Pk8u7WDgnfr91zMlwE Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] presumption that RFC3986 is correct X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2015 16:58:02 -0000 On 2015-01-03 18:54, Sam Ruby wrote: > ... > Meanwhile, I'm actively inquiring as to whether there are others who > would be willing to help update RFC 3986 with me. If that is not meant > to be, so be it. > ... I am willing to help to update RFC 3986 once we actually know precisely what needs to be done. Best regards, Julian From nobody Wed Jan 7 13:36:10 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E721A6F5D for ; Wed, 7 Jan 2015 13:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hw9P1Zvx_CNt for ; Wed, 7 Jan 2015 13:36:07 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 D9EC41A6F3D for ; Wed, 7 Jan 2015 13:36:06 -0800 (PST) Received: from [192.168.159.227] (unknown [104.132.4.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B105A22E25F; Wed, 7 Jan 2015 16:35:59 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Jan 2015 16:35:58 -0500 Message-Id: To: IETF Apps Discuss Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ajTG0cK3f0jJNPcVvkY1qmrohno Subject: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2015 21:36:09 -0000 I=E2=80=99ve updated my Python script that serves as a translation of = ABNF for URIs into regex. https://gist.github.com/mnot/138549 It now validates the following URI schemes according to their respective = specifications: - http - https - file - data - gopher - ws - wss - mailto I didn=E2=80=99t finish mailto or data, because they allow quoted-string = inside of URLs, and that makes my head hurt. Would the respective communities review the regex to make sure they=E2=80=99= re faithful (except for the caveat around quoted strings)? Cheers, -- Mark Nottingham http://www.mnot.net/ From nobody Wed Jan 7 14:45:28 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09EC1A1B94 for ; Wed, 7 Jan 2015 14:45:25 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pu573Yy0AZzd for ; Wed, 7 Jan 2015 14:45:23 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.225]) by ietfa.amsl.com (Postfix) with ESMTP id 32B1D1A1B93 for ; Wed, 7 Jan 2015 14:45:23 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:25264] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id A7/E2-22136-207BDA45; Wed, 07 Jan 2015 22:45:22 +0000 Received: from [192.168.159.48] (unknown [104.132.4.105]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 103AE14032C; Wed, 7 Jan 2015 17:45:21 -0500 (EST) Message-ID: <54ADB701.4000309@intertwingly.net> Date: Wed, 07 Jan 2015 17:45:21 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Mark Nottingham , IETF Apps Discuss References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/fy32kRi0Rn_zCt3s1g1P2i83-yo Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2015 22:45:26 -0000 On 01/07/2015 04:35 PM, Mark Nottingham wrote: > I’ve updated my Python script that serves as a translation of ABNF for URIs into regex. > > https://gist.github.com/mnot/138549 > > It now validates the following URI schemes according to their respective specifications: > - http > - https > - file > - data > - gopher > - ws > - wss > - mailto My test data: http://intertwingly.net/stories/2014/10/05/urltestdata.json A program to test each input: import uri_validate import json import re f = open('urltestdata.json') tests = json.load(f) f.close() valid = {} for test in tests: instr = test['input'] valid[instr] = False if re.match("^%s$" % uri_validate.URI_reference, instr, re.VERBOSE): try: scheme_validator = "%s_URI" % instr.split(":", 1)[0].lower() validator = getattr(uri_validate, scheme_validator) if re.match("^%s#" % validator, instr, re.VERBOSE): valid[instr] = True except AttributeError: valid[instr] = True print json.dumps(valid, indent=2) From nobody Wed Jan 7 15:11:34 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DFA1A7001 for ; Wed, 7 Jan 2015 15:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwF1R-buVZdJ for ; Wed, 7 Jan 2015 15:11:22 -0800 (PST) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3758E1A6FFD for ; Wed, 7 Jan 2015 15:09:52 -0800 (PST) Received: by mail-qc0-f169.google.com with SMTP id w7so1681392qcr.28 for ; Wed, 07 Jan 2015 15:09:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gQmYLURvcNDduz5Atd83y0BP3yFzdkptQhmlaXrwEHY=; b=wPP62prJ+qohHcXIFRpK/Hmylyf+dcLPdZ12jAjjIykFIgQGF9KNYxLAr3wYOixPGp 0v4l+nZFAjkg9Zjym+wk4p1XGvWrnH9nyVo22/FkgoA+cymDMPCFQG/bHoHG9Hf8TLdF 51XprvYiLBQFL+kjSeAtKoVfpGTVV3xb48l2qi0xgqIa44KMCSDBXB8sxJG8KHq18riN syIDlIYsI916h3cX7uXUl0zbEjJlERPRW3hXmeqaCRSJAclO2GD64QQ1GEZsbPzN2FM3 Kpo9GSiAEibhiqB8BRR/Q2li5F4AAKF0kiYkVFzOpTUOpwALpe2FmPA4buJ5jKTJkmGV GYjA== MIME-Version: 1.0 X-Received: by 10.140.19.139 with SMTP id 11mr9071656qgh.14.1420672191415; Wed, 07 Jan 2015 15:09:51 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Wed, 7 Jan 2015 15:09:51 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Jan 2015 09:09:51 +1000 X-Google-Sender-Auth: y47Vy3jvk5NdoO4bIQ148wuySek Message-ID: From: Matthew Kerwin To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a1134f03c4fcadd050c18050a Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/rVtiuBN1p2wieOSw4QWSjD2bwM8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2015 23:11:23 -0000 --001a1134f03c4fcadd050c18050a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8 January 2015 at 07:35, Mark Nottingham wrote: > I=E2=80=99ve updated my Python script that serves as a translation of ABN= F for > URIs into regex. > > https://gist.github.com/mnot/138549 > > =E2=80=8B[...] > =E2=80=8B > =E2=80=8B > =E2=80=8B > > =E2=80=8B > =E2=80=8B This is very cool. I'm definitely going to use it to help me retool the file ABNF. Thanks. > =E2=80=8B=E2=80=8B > Would the respective communities review the regex to make sure they=E2=80= =99re > faithful (except for the caveat around quoted strings)? > > =E2=80=8BHaving a look at file: #456-458: =E2=80=8B| =E2=80=8B # f-auth =3D [ userinfo "@" ] host =E2=80=8B | =E2=80=8B | file_f_auth =3D r"(?: %(userinfo)s @ %(host)s )" % locals() Shouldn't there be a `()?` around userinfo@=E2=80=8B ? =E2=80=8BCheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a1134f03c4fcadd050c18050a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 8 January 2015 at 07:35, Mark Nottingham <mnot@mnot.net> wrote:<= /span>
I=E2=80=99ve updated my Python script that serves as a translat= ion of ABNF for URIs into regex.

https://g= ist.github.com/mnot/138549

=E2=80=8B[...]
=E2=80= =8B
=E2=80=8B
=E2= =80=8B

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

This is= very cool. I'm definitely going to use it to help me retool the file A= BNF. Thanks.


= =E2=80=8B=E2=80=8B
Would the respective communities review the regex t= o make sure they=E2=80=99re faithful (except for the caveat around quoted s= trings)?


=E2=80= =8BHaving a look at file:

#456-458:
<= div class=3D"gmail_default" style=3D"font-family:georgia,serif;color:rgb(7,= 55,99)">
=E2=80=8B| =E2=80=8B# f-auth         =3D [ userinfo "@" ] host

=E2=80=8B<=
/div>| =E2=80=8B
| file_f_auth =3D = r"(?: %(userinfo)s @ %(host)s )&quo= t; % locals()

Shouldn't t= here be a `()?` around userinfo@=E2=80=8B ?

=E2=80=8BCheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a1134f03c4fcadd050c18050a-- From nobody Wed Jan 7 15:24:04 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA011A7D81 for ; Wed, 7 Jan 2015 15:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXjdX0MZsZ2I for ; Wed, 7 Jan 2015 15:23:50 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 DBA741A6F04 for ; Wed, 7 Jan 2015 15:23:49 -0800 (PST) Received: from netb ([89.204.130.54]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LyB6P-1XlTbJ2mHd-015WU8; Thu, 08 Jan 2015 00:23:46 +0100 From: Bjoern Hoehrmann To: Mark Nottingham Date: Thu, 08 Jan 2015 00:23:45 +0100 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:NSSVWW53R0lGycfC00DdtI38a8IX0TnaJYU48rUckqvXYXkw2W4 f67nMfFKwLkQH9sjw3l9bwWsBg5hvpLC0LSbN0UXiqMFFhloIC99bzkL8XHH731MhoTi8UZ +n3t6GYhIY+nhG6+hF/JFt4DhKlCPELMv5BqfvqkXhOl5gDR8c8Nu7ropEmxr2ayRGHaZQe V0WxiHLe6slsXyTh9j4QQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/pKr_ITkdbEJp09t5xYVlgK6mRNY Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jan 2015 23:23:56 -0000 * Mark Nottingham wrote: >I’ve updated my Python script that serves as a translation of ABNF for >URIs into regex. I note that there are a number of automated tools for this; I have not tried any of them recently though, but perhaps other can suggest one. >https://gist.github.com/mnot/138549 > >It now validates the following URI schemes according to their respective >specifications: > - http > - https > - file > - data > - gopher > - ws > - wss > - mailto > >I didn’t finish mailto or data, because they allow quoted-string inside >of URLs, and that makes my head hurt. The bigger problem might be that URI scheme grammars typically do not account for %xx-encoding. It should be fine to write `dAtA:;B%41se64,`, so you cannot use literals like `;base64` directly, unless you apply some syntax-preserving pre-processing. RFC 6068 also re-writes the RFC 5322 productions it uses in prose, and considering how complex the RFC 5322 grammar is, it is probably not wise to attempt to do this manually. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Wed Jan 7 17:18:17 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765FA1AC3C2 for ; Wed, 7 Jan 2015 17:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjbQZXxmrsj0 for ; Wed, 7 Jan 2015 17:18:13 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCBB81A87D5 for ; Wed, 7 Jan 2015 17:18:12 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id va2so5846204obc.8 for ; Wed, 07 Jan 2015 17:18:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qaMEGPtG9XJmyuuC/MKDkh3m1i4GnXrQttVeemuMg3w=; b=YRRwi+ZKVZipZXB3kKataWXIGU8Y8s2sN1x/F1BhQ/u5Bm+UbJ8QR23i1ghPXw42T9 Wat2N4vso+ZQjhKFaKnUGtBru0fDb9lAjwsqD3LSrRX6tDEKh1wJ5MyRoQkco3sWrBtV 1nXPUpWoHl6OI81BGWcvxAHJuKOc5qHnKzxG+yraZXC97LQG0rw9uaA75S6HtQccrq5n rQxMEKeNsDEuS0GQQOcK8RB/PDxN2qCe5lFgfgrzBI1CykNgMDQRg0eehM+FP8I6a2dk XW4WhXvHMoNapa8WsALsqvNWJGlHTbegbvEqVB3BBiER3nEKishdV42+o1M6b6qzgNaU 3YLw== MIME-Version: 1.0 X-Received: by 10.202.216.9 with SMTP id p9mr3806749oig.94.1420679892290; Wed, 07 Jan 2015 17:18:12 -0800 (PST) Received: by 10.202.226.136 with HTTP; Wed, 7 Jan 2015 17:18:12 -0800 (PST) In-Reply-To: References: Date: Wed, 7 Jan 2015 17:18:12 -0800 Message-ID: From: Martin Thomson To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/SgsDa3LtTlI9YfWDSL2wtKIErdQ Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jan 2015 01:18:15 -0000 On 7 January 2015 at 13:35, Mark Nottingham wrote: > I=E2=80=99ve updated my Python script that serves as a translation of ABN= F for URIs into regex. If I don't get back to you, remind me, I have a tool that does the same: https://github.com/martinthomson/abnf2regex It might be old. From nobody Wed Jan 7 17:28:50 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575FF1A87AF for ; Wed, 7 Jan 2015 17:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ihhAo10xpeR for ; Wed, 7 Jan 2015 17:28:45 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 616961A877C for ; Wed, 7 Jan 2015 17:28:45 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 35BFA32E59C; Thu, 8 Jan 2015 10:28:00 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 482f_0fe3_74ff0f17_2afd_4f2c_93d1_12d48cfb58b5; Thu, 08 Jan 2015 10:28:00 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id B7DE2C00DA; Thu, 8 Jan 2015 10:27:59 +0900 (JST) Message-ID: <54ADDD1F.9080105@it.aoyama.ac.jp> Date: Thu, 08 Jan 2015 10:27:59 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Julian Reschke , Sam Ruby , Graham Klyne References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> <54A6AABF.4060406@nin ebynine.org> <54A6B6DF.1010206@intertwingly.net> <54A7DC46.2020708@ninebynine.org> <54A7E9F4.80406@intertwingly.net> <54A820EA.20200@ninebynine.org> <54A82CC4.9080606@intertwingly.net> <54AD6592.1020101@gmx.de> In-Reply-To: <54AD6592.1020101@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/9bxWtnkvcOjzajn86nuAGG6Z0kE Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] presumption that RFC3986 is correct X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jan 2015 01:28:48 -0000 On 2015/01/08 01:57, Julian Reschke wrote: > On 2015-01-03 18:54, Sam Ruby wrote: >> ... >> Meanwhile, I'm actively inquiring as to whether there are others who >> would be willing to help update RFC 3986 with me. If that is not meant >> to be, so be it. >> ... > > I am willing to help to update RFC 3986 once we actually know precisely > what needs to be done. Same here for RFC 3987. I know some things that need to be done, but I get the impression that others think other things need to be done, without being able to understand what exactly. Regards, Martin. From nobody Wed Jan 7 19:01:29 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BF01A00F7 for ; Wed, 7 Jan 2015 19:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhVuhveNCm7C for ; Wed, 7 Jan 2015 19:01:19 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 13C8C1A87AC for ; Wed, 7 Jan 2015 19:01:10 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 589B332E52F; Thu, 8 Jan 2015 12:00:25 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 4836_34ce_a05b8a53_98c6_4127_9ccb_9fc507fd88bf; Thu, 08 Jan 2015 12:00:24 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id CAE93BF505; Thu, 8 Jan 2015 12:00:24 +0900 (JST) Message-ID: <54ADF2C8.8010604@it.aoyama.ac.jp> Date: Thu, 08 Jan 2015 12:00:24 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Bjoern Hoehrmann , Mark Nottingham References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/dnSwP91fV1QzS2kIRNu5vP326-o Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jan 2015 03:01:25 -0000 On 2015/01/08 08:23, Bjoern Hoehrmann wrote: > * Mark Nottingham wrote: >> I=E2=80=99ve updated my Python script that serves as a translation of = ABNF for >> URIs into regex. > > I note that there are a number of automated tools for this; I have not > tried any of them recently though, but perhaps other can suggest one. > >> https://gist.github.com/mnot/138549 >> >> It now validates the following URI schemes according to their respecti= ve >> specifications: >> - http >> - https >> - file >> - data >> - gopher >> - ws >> - wss >> - mailto >> >> I didn=E2=80=99t finish mailto or data, because they allow quoted-stri= ng inside >> of URLs, and that makes my head hurt. It'd probably make my head hurt, too, but I'll try to do it=20 (automatically or manually) to help verify or update=20 http://tools.ietf.org/html/rfc6068. > The bigger problem might be that URI scheme grammars typically do not > account for %xx-encoding. It should be fine to write `dAtA:;B%41se64,`, By RFC 3986 at least, it is. > so you cannot use literals like `;base64` directly, unless you apply > some syntax-preserving pre-processing. RFC 6068 also re-writes the RFC > 5322 productions it uses in prose, and considering how complex the RFC > 5322 grammar is, it is probably not wise to attempt to do this manually= . Did you mean 'automatically'? I would agree in that case. Regards, Martin. From nobody Thu Jan 8 04:15:26 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BBF1ACD19 for ; Thu, 8 Jan 2015 04:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nMuLRHLo79P for ; Thu, 8 Jan 2015 04:15:20 -0800 (PST) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id AD1731A1BC3 for ; Thu, 8 Jan 2015 04:15:20 -0800 (PST) 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 1Y9Bzj-0004px-h2; Thu, 08 Jan 2015 12:15:19 +0000 Received: from oerc-dynamic-192.oerc.ox.ac.uk ([129.67.194.192]) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Y9Bzj-00024I-Gv; Thu, 08 Jan 2015 12:15:19 +0000 Message-ID: <54AE74D6.6070304@ninebynine.org> Date: Thu, 08 Jan 2015 12:15:18 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> <54A6AABF.4060406@ninebynine.org> <54A6B6DF.1010206@intertwingly.net> <54A7DC46.2020708@ninebynine.org> <54A7E9F4.80406@intertwingly.net> <54A820EA.20200@ninebynine.org> <54A82CC4.9080606@intertwingly.net> In-Reply-To: <54A82CC4.9080606@intertwingly.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] presumption that RFC3986 is correct X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jan 2015 12:15:25 -0000 On 03/01/2015 17:54, Sam Ruby wrote: > Meanwhile, I'm actively inquiring as to whether there are others who would be > willing to help update RFC 3986 with me. If that is not meant to be, so be it. I would be happy to review specific problem statements and proposals for updates relating to RFC 3986, and to help with drafting of same where I feel able. #g -- From nobody Thu Jan 8 07:06:11 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E581A8A5E for ; Thu, 8 Jan 2015 07:06:08 -0800 (PST) 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 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 6a66NzJjU3YS for ; Thu, 8 Jan 2015 07:06:06 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 5CCFC1A8A6C for ; Thu, 8 Jan 2015 07:06:01 -0800 (PST) Received: from [192.168.158.75] (unknown [104.132.4.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DF36B509BB; Thu, 8 Jan 2015 10:05:59 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Mark Nottingham In-Reply-To: Date: Thu, 8 Jan 2015 10:05:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1993) Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jan 2015 15:06:09 -0000 On 7 Jan 2015, at 6:23 pm, Bjoern Hoehrmann wrote: >=20 >> I didn=E2=80=99t finish mailto or data, because they allow = quoted-string inside=20 >> of URLs, and that makes my head hurt. >=20 > The bigger problem might be that URI scheme grammars typically do not > account for %xx-encoding. It should be fine to write = `dAtA:;B%41se64,`, > so you cannot use literals like `;base64` directly, unless you apply > some syntax-preserving pre-processing. RFC 6068 also re-writes the RFC > 5322 productions it uses in prose, and considering how complex the RFC > 5322 grammar is, it is probably not wise to attempt to do this = manually. This is exactly the problem I ran into. I think that this really needs to be clearer in the documents; while we = all understand that the ABNF needs to be read within the context of the = prose, this is stretching credibility IMO. Cheers, -- Mark Nottingham http://www.mnot.net/ From nobody Thu Jan 8 07:07:52 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C361A6FD5 for ; Thu, 8 Jan 2015 07:07:52 -0800 (PST) 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 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 LnXU-otyN_zQ for ; Thu, 8 Jan 2015 07:07:50 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 D7B8F1A8A5E for ; Thu, 8 Jan 2015 07:07:49 -0800 (PST) Received: from [192.168.158.75] (unknown [104.132.4.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D5608509BB; Thu, 8 Jan 2015 10:07:48 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Mark Nottingham In-Reply-To: Date: Thu, 8 Jan 2015 10:07:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Matthew Kerwin X-Mailer: Apple Mail (2.1993) Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jan 2015 15:07:52 -0000 Fixed, thanks. I=E2=80=99m hoping to put this into a proper github project soon and = refactor it, to make reading it and making contributions easier. Cheers, > On 7 Jan 2015, at 6:09 pm, Matthew Kerwin = wrote: >=20 > On 8 January 2015 at 07:35, Mark Nottingham wrote: > I=E2=80=99ve updated my Python script that serves as a translation of = ABNF for URIs into regex. >=20 > https://gist.github.com/mnot/138549 >=20 > =E2=80=8B[...]=E2=80=8B=E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B >=20 > This is very cool. I'm definitely going to use it to help me retool = the file ABNF. Thanks. >=20 >=20 > =E2=80=8B=E2=80=8BWould the respective communities review the regex to = make sure they=E2=80=99re faithful (except for the caveat around quoted = strings)? >=20 >=20 > =E2=80=8BHaving a look at file: >=20 > #456-458: >=20 > =E2=80=8B| =E2=80=8B# f-auth =3D [ userinfo "@" ] host > =E2=80=8B| =E2=80=8B > | file_f_auth =3D r"(?: %(userinfo)s @ %(host)s )" % locals() >=20 > Shouldn't there be a `()?` around userinfo@=E2=80=8B ? >=20 > =E2=80=8BCheers > --=20 > Matthew Kerwin > http://matthew.kerwin.net.au/ > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From nobody Thu Jan 8 08:55:04 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C385C1A87EF for ; Thu, 8 Jan 2015 08:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzmlQEscCsG7 for ; Thu, 8 Jan 2015 08:54:59 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.227]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7541A87EC for ; Thu, 8 Jan 2015 08:54:59 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:62337] helo=rubix) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id D9/EB-31080-266BEA45; Thu, 08 Jan 2015 16:54:58 +0000 Received: from [192.168.1.115] (unknown [192.168.1.115]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 8BFC3140CFD; Thu, 8 Jan 2015 11:54:57 -0500 (EST) Message-ID: <54AEB660.1020701@intertwingly.net> Date: Thu, 08 Jan 2015 11:54:56 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Mark Nottingham , Matthew Kerwin References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: Cc: Alex Russell , Domenic Denicola , IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jan 2015 16:55:02 -0000 On 01/08/2015 10:07 AM, Mark Nottingham wrote: > Fixed, thanks. > > I’m hoping to put this into a proper github project soon and refactor it, to make reading it and making contributions easier. First, Mark: thanks for doing this! Would you consider putting it in https://github.com/webspecs/url, perhaps in the evaluate directory? Wherever it is placed, I plan to write scripts that make use of this information. For context (and in full disclosure, I discussed much of this F2F with Mark yesterday at the TAG meeting, but am including the background here for everybody's benefit): Different people care about different things, and that's all right. As an example, I was able to surprise Alex Russell and Dominic Denicola (both Google employees) by showing that the following expression produced different results on Chrome on Windows as compared to Chrome on OS/X: new URL("file:c|foo").pathname Why does this matter? Well in the case of web browsers, developers of those web browsers want content that shows up on the web to behave interoperabily, both across platforms, and across competing implementations. More specifically, if you can construct a web page (including javascript) that produces different results on Internet Explorer on Windows vs Apple's Safari on OS/X, then that's a problem. In the case of libraries like Node.js, there is a desire to parse URLs just like web browsers do. Given that Dominic cares about node.js and Chrome, I can point him to date such as the following https://url.spec.whatwg.org/interop/test-results/?select=nodejs&baseline=chrome Looks like there is quite a bit of yellow on that page. Since I care about the URL Standard, I created converted the prose into executable form so that it could be compared. This allows me to very easily produce a similar page comparing nodejs and (by proxy) the URL standard: https://url.spec.whatwg.org/interop/test-results/?select=nodejs With this data, we can triangulate: and have a discussion with real data as to whether node.js should change or whether the URL standard should change. Mark cares about valid URIs. He's certainly not alone in that. What he has done is express his interests not merely in high level prose, but in concrete, executable form. Given that he has done that, I can pose some interesting questions. For example, if you consider the process of canonicalizing a href value on an element and stringifying the result, an implementation like Chrome will produce something that will be sent across the wire. I've captured the results here: https://raw.githubusercontent.com/webspecs/url/develop/evaluate/useragent-results/chrome Given that data and Mark's script, I can produce a list of outputs that Mark doesn't consider valid: "http://f:21/%20b%20?%20d%20# e": false, "http://example.com/foo%": false, "http://2001::1]/": false, "http://[www.google.com]/": false, "http://f:fifty-two/c": false, "http://foo:-80/": false, "http://example.com/foo/.%2": false, "http://2001::1/": false, "http://[google.com]/": false, "http://example.org/foo/bar#\\": false, "http://example.org/foo/[61:24:74]:98": false, "gopher://example.com/": false, "http://example.org/foo/bar#\u03b2": false, "http://example.com/foo%2%C3%82%C2%A9zbar": false, "gopher://foo/": false, "http://example.com/foo%2zbar": false, "http://f:b/c": false, "a: foo.com": false, "http://[1::2]:3:4/": false, "http://example.org/foo/[61:27]/:foo": false, "http://f:%2021%20/%20b%20?%20d%20# e": false, "http://example.com/foo%2": false, "http://foo/path;a??e#f#g": false, "data:example.com/": false, "http://www.google.com/foo?bar=baz# \u00bb": false, "http://f:%20/c": false, "http://:www.example.com/": false, "data:/example.com/": false With this data, we can have a discussion as to whether Mark's script should be updated, or Chrome should change, or some spec should change. I have taken this a step further. I wrote a script that will convert Mark's script from Python to JavaScript. This means that he can maintain his script in Python and I can include an equivalent script on web pages and use that information to filter out things that aren't interesting or highlight things that are. Some people here may have different interests, and that is OK too. I encourage everybody to find a way to express their interests in the form of code. While my preference is JavaScript, I'm otherwise pretty agnostic. XSLT, Perl, PHP, C#: doesn't matter to me. If you do so, I'll find a way to include that as a filter or as a base for comparison. Doing so means that as the test suite grows, or implementation results change(*), you will be able to get instant results to the questions that interest you. - Sam Ruby (*) As an example, I'm trying to get updated results for IE. Current status: http://intertwingly.net/blog/2015/01/08/Ununzippable-Modern-IE From nobody Thu Jan 8 16:38:05 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26831A0125 for ; Thu, 8 Jan 2015 16:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yet41tLLTwCL for ; Thu, 8 Jan 2015 16:37:59 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740AC1A00E6 for ; Thu, 8 Jan 2015 16:37:59 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id q58so5365783wes.4 for ; Thu, 08 Jan 2015 16:37:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eVYMPaZC9B6NHVOldsNBnhbX4TT04sUUqQy9s8vtA5o=; b=fk+p6mt9eLrIh+FvnyeMM37xyJa5pcLqAC1j5gbNzVI4na0LRGzUejDbnUbfnDO0W1 kNZBExzHY7hHI+BBgzn0Uf06yGPcRQ6hrPSEhXwo89FF7t8da/Hb1goc4xcLQzqgYC9X viUamlKVt8veWW7Q3jWNsSwURwrdAx8tDdoeyNV1WgGw5IOFSVFLiDcF2BRJbewx91+h 8ebvj2sCTx3fJpIAr3GFlf2uWB/vxotn3LWcJlTYSgAXlMu8mqkejQvCBlshr/Ac7ppM mUklmOADt8hR81TcwiJog4ptq4KIIiVk7uV9+OrSDsDAXSuKDR8+bXfHsT/hx34P/Ymh M//A== MIME-Version: 1.0 X-Received: by 10.194.86.135 with SMTP id p7mr25819131wjz.89.1420763878263; Thu, 08 Jan 2015 16:37:58 -0800 (PST) Received: by 10.27.204.198 with HTTP; Thu, 8 Jan 2015 16:37:58 -0800 (PST) In-Reply-To: References: <20141222230149.31980.3522.idtracker@ietfa.amsl.com> Date: Thu, 8 Jan 2015 16:37:58 -0800 Message-ID: From: "Murray S. Kucherawy" To: Sean Leonard Content-Type: multipart/alternative; boundary=089e0102e49846144d050c2d5e76 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jan 2015 00:38:01 -0000 --089e0102e49846144d050c2d5e76 Content-Type: text/plain; charset=UTF-8 Colleagues, On Mon, Dec 22, 2014 at 3:21 PM, Sean Leonard wrote: > Hello apps-discuss: > > Here is draft-05. Have at it. > > Cheers, > > Sean > > On Dec 22, 2014, at 3:01 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 Applications Area Working Group Working > Group of the IETF. > > > > Title : The text/markdown Media Type > > Author : Sean Leonard > > Filename : draft-ietf-appsawg-text-markdown-05.txt > > Pages : 14 > > Date : 2014-12-22 > > > > Abstract: > > This document registers the text/markdown media type for use with > > Markdown, a family of plain text formatting syntaxes that optionally > > can be converted to formal markup languages such as HTML. > > [...] > There's been no feedback since this was posted. Is that because of the holidays, or because we think it's ready for a WGLC? -MSK --089e0102e49846144d050c2d5e76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

On Mon, Dec 22, 2014 at 3:21 PM, Sean L= eonard <dev+ietf@seantek.com> wrote:
Hello apps-discuss:

Here is draft-05. Have at it.

Cheers,

Sean

On Dec 22, 2014, at 3:01 PM, in= ternet-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: The text/markdown Media Type
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : S= ean Leonard
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-appsawg-text-markdown-05.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 14
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2014-12-22
>
> Abstract:
>=C2=A0 This document registers the text/markdown media type for use wit= h
>=C2=A0 Markdown, a family of plain text formatting syntaxes that option= ally
>=C2=A0 can be converted to formal markup languages such as HTML.
> [...]

There's been no f= eedback since this was posted.=C2=A0 Is that because of the holidays, or be= cause we think it's ready for a WGLC?

-MSK
<= /div>
--089e0102e49846144d050c2d5e76-- From nobody Thu Jan 8 16:45:42 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288FC1A6FEC for ; Thu, 8 Jan 2015 16:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyPFcBH7U5iw for ; Thu, 8 Jan 2015 16:45:39 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 442091A00E6 for ; Thu, 8 Jan 2015 16:45:39 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4835222E262 for ; Thu, 8 Jan 2015 19:45:20 -0500 (EST) Message-ID: <54AF245B.3090808@seantek.com> Date: Thu, 08 Jan 2015 16:44:11 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/alternative; boundary="------------000401050802040108060302" Archived-At: Subject: [apps-discuss] feedback Fwd: Re: draft-ietf-appsawg-text-markdown-05 (prelim notice) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jan 2015 00:45:41 -0000 This is a multi-part message in MIME format. --------------000401050802040108060302 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit FYI--for the list. Sean -------- Forwarded Message -------- Subject: Re: draft-ietf-appsawg-text-markdown-05 (prelim notice) Date: Mon, 22 Dec 2014 16:46:13 -0600 From: Evan Wondrasek <> To: Sean Leonard <> *Message-ID:* Sean, Just wanted to let you know that I'm still alive, and I looked at draft 5 and thought it looked great. Thanks for continuing to include me in the review. Evan On Sun, Dec 21, 2014 at 12:20 AM, Sean Leonard > wrote: Hello Reviewers: I worked on draft-ietf-appsawg-text-markdown-05. [SNIP] --------------000401050802040108060302 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit FYI--for the list.

Sean


-------- Forwarded Message --------
Subject: Re: draft-ietf-appsawg-text-markdown-05 (prelim notice)
Date: Mon, 22 Dec 2014 16:46:13 -0600
From: Evan Wondrasek <>
To: Sean Leonard <>
Message-ID:
 <CAHeJv1YrR9x9a97NnaD2yDUY5wziAr1Jyzxn0JWu_gXg_=vw7w@mail.gmail.com>


Sean,

Just wanted to let you know that I'm still alive, and I looked at draft 5 and thought it looked great. Thanks for continuing to include me in the review.

Evan

On Sun, Dec 21, 2014 at 12:20 AM, Sean Leonard <dev+ietf@seantek.com> wrote:
Hello Reviewers:

I worked on draft-ietf-appsawg-text-markdown-05.
[SNIP]

--------------000401050802040108060302-- From nobody Thu Jan 8 17:05:38 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BB31A7017 for ; Thu, 8 Jan 2015 17:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6IcOPJxyd3G for ; Thu, 8 Jan 2015 17:05:31 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C9FD1A6FF8 for ; Thu, 8 Jan 2015 17:05:09 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id x12so5572014wgg.10 for ; Thu, 08 Jan 2015 17:05:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C7+JQiVlShp+rR8C3YF9MfFoWYM9hBQ2DLXiNSkwidU=; b=DJdvpbaVmBXfaSL8QY354SFdUDLGL3ZJb62hOeuCKJN1VRFZNfvjh4HCKwUakrVger ExZG/tfc0yds3uNcGg/3leLVHoGpfTPc/4K8eWPhmJF5o4e3vmuB8UcVXjrxZ8P0yHyb ZDK7UwGjVdzxqKzuf57PHLAKXlom/YnLywKErioBVlMEMXgRZb2/cZ8bEJz+hAKYko/o /qWLjXSh2/NCVcBqezzQbc82GCj9Qhz0s13E1h/N+zExCjRpmn/01sfXcl6tBSZWnhvi IuxWarjzhdf/FJCZlz/pVDl7amF+SkqfCyJY/0rW8JpwcfOK/PH+yWuIFje+k3WCL7tc EoPg== MIME-Version: 1.0 X-Received: by 10.180.218.39 with SMTP id pd7mr26444975wic.21.1420765507847; Thu, 08 Jan 2015 17:05:07 -0800 (PST) Received: by 10.27.204.198 with HTTP; Thu, 8 Jan 2015 17:05:07 -0800 (PST) In-Reply-To: <21F9EC2D-2F87-4278-A139-F4C19F93CE2B@seantek.com> References: <20141228232409.13727.85741.idtracker@ietfa.amsl.com> <54A11093.1010100@seantek.com> <54A4200C.2040706@ninebynine.org> <21F9EC2D-2F87-4278-A139-F4C19F93CE2B@seantek.com> Date: Thu, 8 Jan 2015 17:05:07 -0800 Message-ID: From: "Murray S. Kucherawy" To: Sean Leonard Content-Type: multipart/alternative; boundary=001a1134cd58678ba1050c2dbfed Archived-At: Cc: Graham Klyne , IETF Apps Discuss Subject: Re: [apps-discuss] New Version Notification for draft-seantek-text-markdown-use-cases-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jan 2015 01:05:35 -0000 --001a1134cd58678ba1050c2dbfed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jan 1, 2015 at 3:26 PM, Sean Leonard wrote: > The links in the References field are to the documentation of the syntax > for the variant. Frequently, the only documentation about the variant is = in > documentation accompanying the primary implementation (e.g., pandoc =3D > README section called pandoc=E2=80=99s markdown). > > The prior registration template distinguished between syntax documentatio= n > and extant implementations. There was a lot of pushback on draft-03 that > the whole thing was too complicated. (I deemed the objection legitimate o= n > grounds that if the registration process is too cumbersome, people who wa= nt > to interoperate with a variant will not bother to register at all.) I tri= ed > to simplify the template as much as possible; this is the result. > I don't think enumerating implementations in a registry is useful because that will be the most volatile part of what gets registered. On the other hand, a reference to the defining document is pretty important to include. -MSK --001a1134cd58678ba1050c2dbfed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 1, 2015 at 3:26 PM, Sean Leonard <dev+ietf= @seantek.com> wrote:
The links in the References= field are to the documentation of the syntax for the variant. Frequently, = the only documentation about the variant is in documentation accompanying t= he primary implementation (e.g., pandoc =3D README section called pandoc=E2= =80=99s markdown).

The prior registration template distinguished between syntax documentation = and extant implementations. There was a lot of pushback on draft-03 that th= e whole thing was too complicated. (I deemed the objection legitimate on gr= ounds that if the registration process is too cumbersome, people who want t= o interoperate with a variant will not bother to register at all.) I tried = to simplify the template as much as possible; this is the result.

I don't think enumerating implementations in= a registry is useful because that will be the most volatile part of what g= ets registered.=C2=A0 On the other hand, a reference to the defining docume= nt is pretty important to include.
=C2=A0
-MSK
<= /div> --001a1134cd58678ba1050c2dbfed-- From nobody Thu Jan 8 17:05:46 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DEF1A6FF8 for ; Thu, 8 Jan 2015 17:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZy43Fhf6kyp for ; Thu, 8 Jan 2015 17:05:35 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A70241A7029 for ; Thu, 8 Jan 2015 17:05:30 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id em10so6776686wid.5 for ; Thu, 08 Jan 2015 17:05:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wrBnhrhPhlcFxglW8HI2RR1ALJErczvRQfRc85INxrE=; b=bGuoP2hQqUDJ/bpVKhaMRwo/NAC/o6Iwirpd2HHIt88D6RnlWn/zhy6mA5SSFIWcAp n67coAQvv0LO8E7l5XHEtfxm02OjmcBa7mG+uofzbuabmwlpy04RFwuxqPMClqQf4H20 /S6GTeXCxamGf9Ge5tNWs6w+4O44QxnDortO5yQ9eBw7ixfY4dK3YKwIWYAZUcwoGiK+ zPzdVXeUjUiXh7I+uwSJzzXIv0fakz/PQD9jfhjPN9zzO/8c0PHvt0w+bU3cHqKX3Qda AcyTTQToamyiN/AwYrHk/zm2KBb6pxLxPPTYhCJ8FZaHh0z0/lOCABAUlajQK2QV5rt7 6TOw== MIME-Version: 1.0 X-Received: by 10.194.62.76 with SMTP id w12mr26403151wjr.5.1420765529349; Thu, 08 Jan 2015 17:05:29 -0800 (PST) Received: by 10.27.204.198 with HTTP; Thu, 8 Jan 2015 17:05:29 -0800 (PST) In-Reply-To: <54A4200C.2040706@ninebynine.org> References: <20141228232409.13727.85741.idtracker@ietfa.amsl.com> <54A11093.1010100@seantek.com> <54A4200C.2040706@ninebynine.org> Date: Thu, 8 Jan 2015 17:05:29 -0800 Message-ID: From: "Murray S. Kucherawy" To: Graham Klyne Content-Type: multipart/alternative; boundary=047d7ba977a4afa3bb050c2dc058 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-seantek-text-markdown-use-cases-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jan 2015 01:05:37 -0000 --047d7ba977a4afa3bb050c2dc058 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 31, 2014 at 8:10 AM, Graham Klyne wrote: > I took a quick skim. I'm not sure I find the background rationale > especially useful, and haven't reviewed it in detail (but I've no objection > to it - as if that mattered!). > Graham, Are you referring to Section 1 and perhaps Section 2 with that remark? I believe we asked Sean to split out the registrations into a separate document, so that part seems to be okay for the moment. -MSK --047d7ba977a4afa3bb050c2dc058 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 31, 2014 at 8:10 AM, Graham Klyne <gk@ninebyn= ine.org> wrote:
I took a quick skim.=C2=A0 I'= ;m not sure I find the background rationale especially useful, and haven= 9;t reviewed it in detail (but I've no objection to it - as if that mat= tered!).

Graham,

Are you referri= ng to Section 1 and perhaps Section 2 with that remark?=C2=A0 I believe we = asked Sean to split out the registrations into a separate document, so that= part seems to be okay for the moment.

-MSK
--047d7ba977a4afa3bb050c2dc058-- From nobody Fri Jan 9 01:37:57 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E261A86E8 for ; Fri, 9 Jan 2015 01:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNOXGHyiD1OJ for ; Fri, 9 Jan 2015 01:37:53 -0800 (PST) Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7DB1A86EB for ; Fri, 9 Jan 2015 01:37:53 -0800 (PST) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Y9W0t-0004wF-rM; Fri, 09 Jan 2015 09:37:51 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Y9W0t-0008Sj-Dy; Fri, 09 Jan 2015 09:37:51 +0000 Message-ID: <54AFA16F.9010801@ninebynine.org> Date: Fri, 09 Jan 2015 09:37:51 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20141228232409.13727.85741.idtracker@ietfa.amsl.com> <54A11093.1010100@seantek.com> <54A4200C.2040706@ninebynine.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-seantek-text-markdown-use-cases-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jan 2015 09:37:55 -0000 On 09/01/2015 01:05, Murray S. Kucherawy wrote: > On Wed, Dec 31, 2014 at 8:10 AM, Graham Klyne wrote: > >> I took a quick skim. I'm not sure I find the background rationale >> especially useful, and haven't reviewed it in detail (but I've no objection >> to it - as if that mattered!). >> > > Graham, > > Are you referring to Section 1 and perhaps Section 2 with that remark? I > believe we asked Sean to split out the registrations into a separate > document, so that part seems to be okay for the moment. I was referring to section 1. Taken in isolation, my comment should not be regarded as any kind of blocker. For me, the substantive part of the document is the registrations. The rest might be useful to some, but I suspect that most people for whom this work is useful will already have their own experience of what Markdown is and how to use it. As for splitting out the registrations, I'm assuming this draft *is* the separate document. I thought there were differing opinions whether they should be in the main MIME type document of a separate informational document. Either works for me. I do seem to recall there was broader consensus to move the framing material (sections 1, 2 and maybe 4) out of the main document (YMMV). I've no objection to this document going forward in broadly its present form. #g From nobody Fri Jan 9 07:02:19 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB201A00E7 for ; Fri, 9 Jan 2015 07:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KotO9FrAfvBW for ; Fri, 9 Jan 2015 07:02:11 -0800 (PST) Received: from cp.hebergementsolutions.com (cp.hebergementsolutions.com [184.170.132.66]) (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 C587B1A6F12 for ; Fri, 9 Jan 2015 07:02:11 -0800 (PST) Received: from [173.246.6.251] (port=56286 helo=[10.0.0.81]) by cp.hebergementsolutions.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1Y9b2g-0005XS-1C; Fri, 09 Jan 2015 10:00:02 -0500 Content-Type: multipart/signed; boundary="Apple-Mail=_E64ABEA1-555E-49AE-9361-898402D90490"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Michel Fortin In-Reply-To: Date: Fri, 9 Jan 2015 10:02:04 -0500 Message-Id: References: <20141222230149.31980.3522.idtracker@ietfa.amsl.com> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1993) X-cPanel-MailScanner-Information: Please contact the ISP for more information X-cPanel-MailScanner-ID: 1Y9b2g-0005XS-1C X-cPanel-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-cPanel-MailScanner-SpamCheck: X-cPanel-MailScanner-From: michel.fortin@michelf.ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cp.hebergementsolutions.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - michelf.ca X-Get-Message-Sender-Via: cp.hebergementsolutions.com: authenticated_id: michel.fortin@michelf.ca Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jan 2015 15:02:17 -0000 --Apple-Mail=_E64ABEA1-555E-49AE-9361-898402D90490 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 8-janv.-2015 =C3=A0 19:37, Murray S. Kucherawy = a =C3=A9crit : > There's been no feedback since this was posted. Is that because of = the holidays, or because we think it's ready for a WGLC? For my part, it's mostly because I still don't really know what to think = of the whole thing. The complexity has been scaled down from the earlier drafts, that's = good. Having a registry for variants remains unnecessary in my view, and, = while I understand Sean personally has a use case for it, what remains = unclear to me is how the registry is going to be populated. It seems to = me that the only person that needs it is Sean and thus he'll either be = the one populating it or it'll be left mostly empty. Perhaps I'm wrong, = but who else has shown interest in the thing? I don't feel like I'm in a good position to evaluate most of this spec. = I have never been confronted with a problem where it'd have been useful = to programatically detect which variant to use for a given Markdown = document. Perhaps this makes me biased against any added layer trying to = solve that problem. But it makes me feel like I've put a lot of energy = trying to simplify a spec addressing a problem I have little experience = with and that in the end doesn't appeal to me much. It seems I don't have enough interest to spend the time necessary to = further review this document. If this was a two-page spec simply adding = a plain "text/markdown" media type registration then I could probably = spare the time to look at it in details, but that's quite far from the = current document. --=20 Michel Fortin michel.fortin@michelf.ca https://michelf.ca --Apple-Mail=_E64ABEA1-555E-49AE-9361-898402D90490 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMjTCCBjQw ggQcoAMCAQICAR8wDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAI6ByrMlixq5 piBb1m3JRDRfINXQII5OT8TWqeZz8zse9vt7fUZHaPVLFeWYlj8B9BA2uHhGfyZtPtyf0nYtnFPK g7xiSXX/apE16bFfYdtHka3qupMggZp1+OZmtAdRO/TRij5C2bV2o+kIf+53LfWav2tw6pICxfJO 9Hrjl7HbYo3+l3ul9YVB5SVKG8WLmMCkpm7ti1Z4LOYF0Y5AG3d8AqYS3/5aUWQN/ZQN4BMruXSJ GFYFYBDxu7jTBbBW9l2m4u/s80e+jkJ9P9XDXeOsclCsdAtY4F2C/kOH76j6fwiABKLx454BkTMt ukts/PLtzrIy37oV0UTiykmcFCXSmc1gQk+xz25vGs/D36Ve8L+2A+J7idUYP83A1wS4JLgb4Q7J Fzl/lqLO+IDM+AGH9cujofg7Pjl2HdyDq3FOn7eAz2ZPN+zGzes5/E8rK1QnTsk9tIsi7QRIPdAB TnhC8ImOaNjVkB9JGUJ2BAXwVLB5Dq9SEdnGiyWdS7a9fb+Tfy8D2wuOA9metV0hUlrPMHCmJtZR bFZAjOlQrKhMM5hE31Qal2HF6OkfVhtE0nvqgj6dLt3871yxSYh13c0OBF6kZPR9Sgij3GZhAwEN sESI065Wg0BRSoCtWB6RxATzwIyIGgD/Gm8uPp+cv9OtSrDRwNjGphN+MQ81oVh5MIIGUTCCBTmg AwIBAgIDCZgGMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTQwNDEwMDkzMjE4WhcNMTUwNDEyMDIxMjUzWjBnMRkwFwYDVQQNExBZbjhVdjUyNmNnNGJjcmlR MSEwHwYDVQQDDBhtaWNoZWwuZm9ydGluQG1pY2hlbGYuY2ExJzAlBgkqhkiG9w0BCQEWGG1pY2hl bC5mb3J0aW5AbWljaGVsZi5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM1xHBAc 28F84D5D/ITRvjBwB3dwI7osaLizqSCZhMRpXg4zWsxIoaDy6H9OTQdpaqY431ypMGiwd7vddirK pEn/DEVb0SItTb73touChfuVVE5LHYPKcL1CfRa0XJF4KhryeP/m9sPA4N4zLb7IR4HFioOkF/XL Hkh9bv12yXUK+6jWpSNaQNf/kUz2AlKUSSx4pW2kBH72EW4xreuRs30Qqft1rqwkL4LRhipd3GA9 0Pni7mOaNSKu3kGCHKz+/4+h4SUdNuD13nhZLwLFHyHhk4I+IpFyq5/vPFr/dFRg3rdpMxhgd+M/ H4rfaUm2Kb0ODq+7FXccjDSbhCFEc08CAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUu56gBRTHUtBmsqyG mqCVXtMAz9cwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYbWlj aGVsLmZvcnRpbkBtaWNoZWxmLmNhMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCC ASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRp b24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFy dHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29t L2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3Nw LnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2Fp YS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqG GGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAJjgunxV0rh494ufL ch4bvYfoewNrW9OIZjpyS3GTzjD+a8aUIctmXo5HilIew8NwaYzRRKhQ3V4uy3rPmpIGddZfXlxm jlejMlWCVcgBBuB2CziegUCWvJbpSjz4eM0dQX6nU0zAGV1iqWkdrIxMgkgeeGWZaWV+m2Qu/oWw 9EbgegPaz+cFJNbrZEjA06d9CKQJTn2MP7POPPSwDTlTHZ/b6/X1MckAfCeEm96CRCEEzBo06Yki UMJMOdqVggAyP7huNxo7TpnNfe7ylve4vsHBSxpW7NElcMaXIgFalFVmpxZICOvxcncajCmYOzJp cb+YJuJwkeYf5CMjGsBshzGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAwmYBjAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNTAxMDkxNTAyMDVaMCMGCSqGSIb3DQEJBDEWBBSUbm/9PwKMwg8pBIzz46IWo26k 8TCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwmYBjCB pwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCZgGMA0G CSqGSIb3DQEBAQUABIIBAD4WPh6tmq508/PslR6bcf44kYGINGbFMlsmxyYojuhQLiFlSsrnYwcR t51rr5pZqTONU1GoFP3JKiXnPcRwA/r36bSEuaZbOflmDGviBRiFuoCvW2yNrPxj4z2IWp9y5bhN OxI1is2VcOXO7gdo436YS/1/SMJ0cQDw2IZkKiw0Rwv9gK3V+flCYhcv6VyeigoBqgqhUhUNEXZr xaL15kzvSxrAWM92o+XgG5+AtzIVswMgJuOU7r9XTrk3h3SdlVnHE4BALiP9bR9asTTaWTDIhnES R+jM1B4dq/+WX8cHrBuTtiBmw+6X4XEwFkDZBr5TgOktdaxcQKUAdb8WDBMAAAAAAAA= --Apple-Mail=_E64ABEA1-555E-49AE-9361-898402D90490-- From nobody Fri Jan 9 12:16:51 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F18C1A9062 for ; Fri, 9 Jan 2015 12:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HldYbwNRgmqX for ; Fri, 9 Jan 2015 12:16:43 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3654E1A036D for ; Fri, 9 Jan 2015 12:16:34 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so4635182wiv.1 for ; Fri, 09 Jan 2015 12:16:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=P1fE46YOXzyNiCIIPc9EIHFCm94v8h+SNFjh7GThNHs=; b=rnFqnUMuSvNeCLizXU2/scH1tWTLXW77AnmKfoBIwglckt25zmQPk0FV22xUTH6q1Y I46hZQNb5bODpXE8cXiIwnys2RY1O2qOTL4ZSEl1OFsNpXwuG2JQD+JOQoncunNwFAoW aYRlTy/ody9F8Xg52TGRmgzODXS1wtBvWnb1DriERkAsX6qna2hvKNQnTVkf2MRbqpys AkwN/24yPldzLPAUdZ2Nf2Fm3bWO1E6TXAW4ZIMeZcDB9TcgLY5UpzdfsHS+YHVm+Qfk 6s0PlCv+/lE2jSqEZcXDOYHgnZRz7rDJOJIHapDMjzc2+chcZQNIqVrUfxsD8s/y2hw4 KZ3g== MIME-Version: 1.0 X-Received: by 10.181.29.198 with SMTP id jy6mr8622496wid.0.1420834592945; Fri, 09 Jan 2015 12:16:32 -0800 (PST) Received: by 10.27.204.198 with HTTP; Fri, 9 Jan 2015 12:16:32 -0800 (PST) Date: Fri, 9 Jan 2015 12:16:32 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c34694327bc3050c3dd5fe Archived-At: Subject: [apps-discuss] Call For Adoption: draft-seantek-text-markdown-use-cases X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jan 2015 20:16:45 -0000 --001a11c34694327bc3050c3dd5fe Content-Type: text/plain; charset=UTF-8 This note starts a Call For Adoption for draft-seantek-text-markdown-use-cases. This work was split from draft-ietf-appsawg-text-markdown which is already undergoing processing through APPSAWG. Note that a Call For Adoption only accepts the document as a first version for development by the working group. The working group can change it as it wishes subject to our usual consensus process. Please reply with support or objection on this thread by January 23, 2015. -MSK, APPSAWG co-chair --001a11c34694327bc3050c3dd5fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This note starts a Call For <= span class=3D"">Adoption for draft-seantek-text-markdown-use-cases.=C2=A0 This work was split from = draft-ietf-appsawg-text-markdown which is already undergoing processing thr= ough APPSAWG.

Note that a Call For Adoption only accepts the documen= t as a first version for development by the working group.=C2=A0 The workin= g group can change it as it wishes subject to our usual consensus process.<= br>
Please reply with support or objection on this thread by January 23,= 2015.

-MSK, APPSAWG co-chair
--001a11c34694327bc3050c3dd5fe-- From nobody Fri Jan 9 12:32:51 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7FF1A8AEF for ; Fri, 9 Jan 2015 12:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JB6k0eozV-sU for ; Fri, 9 Jan 2015 12:32:48 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798141A8AE7 for ; Fri, 9 Jan 2015 12:32:48 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id w62so9907907wes.13 for ; Fri, 09 Jan 2015 12:32:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=VxCt9WZe1ZJzJo2NUK+UOfg263XNJoqmFF5NWVzHKfQ=; b=I3YH8+TjsJmonFZE6sbp2T6B4f4V/kIarZuaAL00QPdKvE+mT1MmSYn3TJMrKysXGt az+8nJune68Wn6MSYrHx5cfYibpYstiBkHHgP6IFShYJjv9jsdCt3lvSI6Jck34zVEGq sMqY4tCuU+KHw5CduyP7mU9taUGabg6g7zk/njkA9Ak63NlRlTRLToufvBniEW8Tx701 W2wfMQtxlxILcgf3YfFCwbFbdZjbON8MEnlGgYUekwTLk7uDF0Kz8r2IIKoKuFUOMd0h eM2RFpydNiuNdCpvOTLs5xdazBowSJFyd0NDsrEeHgwCHYOsB88qduzXjKlKjez2qqZQ XCkA== MIME-Version: 1.0 X-Received: by 10.180.218.39 with SMTP id pd7mr8492586wic.21.1420835567279; Fri, 09 Jan 2015 12:32:47 -0800 (PST) Received: by 10.27.204.198 with HTTP; Fri, 9 Jan 2015 12:32:47 -0800 (PST) In-Reply-To: References: Date: Fri, 9 Jan 2015 12:32:47 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a1134cd5845a56b050c3e0f5c Archived-At: Subject: Re: [apps-discuss] Call For Adoption: draft-seantek-text-markdown-use-cases X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jan 2015 20:32:50 -0000 --001a1134cd5845a56b050c3e0f5c Content-Type: text/plain; charset=UTF-8 On Fri, Jan 9, 2015 at 12:16 PM, Murray S. Kucherawy wrote: > This note starts a Call For Adoption for > draft-seantek-text-markdown-use-cases. This work was split from > draft-ietf-appsawg-text-markdown which is already undergoing processing > through APPSAWG. > > Note that a Call For Adoption only accepts the document as a first version > for development by the working group. The working group can change it as > it wishes subject to our usual consensus process. > > Please reply with support or objection on this thread by January 23, 2015. > Some other things to consider in this or any Call For Adoption: - Is the publication of this document (even after development) necessary and useful? - Who is the intended audience? - Is APPSAWG the right venue for this work? Does it fit within our charter? - Does it conflict with work going on anywhere else that we should know about, inside or outside the IETF? - Does there appear to be enough people prepared to work on it? - Is there a better alternative document we might adopt instead? There might be others I'm not considering. My point here is that it's not a trivial thing to take on a new document for working group processing, and that needs due consideration when choosing work for us to adopt. -MSK --001a1134cd5845a56b050c3e0f5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jan 9, 2015 at 12:16 PM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
This note starts a Call For Adoption= for draft-seantek-text-markdown-use-cases.=C2=A0 This work was split from = draft-ietf-appsawg-text-markdown which is already undergoing processing thr= ough APPSAWG.

Note that a Call For Adoption only accepts the documen= t as a first version for development by the working group.=C2=A0 The workin= g group can change it as it wishes subject to our usual consensus process.<= br>
Please reply with support or objection on this thread by January 23,= 2015.

Some other things to= consider in this or any Call For Adoption:

- Is the publicati= on of this document (even after development) necessary and useful?
- Who= is the intended audience?
- Is APPSAWG the right venue for this work?= =C2=A0 Does it fit within our charter?
- Does it conflict with work= going on anywhere else that we should know about, inside or outside the IE= TF?
- Does there appear to be enough people prepared to work on it?
<= /div>
- Is there a better alternative document we might adopt instead?<= br>
There might be others I'm not considering.=C2=A0 My p= oint here is that it's not a trivial thing to take on a new document fo= r working group processing, and that needs due consideration when choosing = work for us to adopt.

-MSK
--001a1134cd5845a56b050c3e0f5c-- From nobody Fri Jan 9 13:51:49 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673E31A0687 for ; Fri, 9 Jan 2015 13:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSgr6h0c5ALg for ; Fri, 9 Jan 2015 13:51:45 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D721A0039 for ; Fri, 9 Jan 2015 13:51:45 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id a1so10347630wgh.9 for ; Fri, 09 Jan 2015 13:51:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=K2dVqMbpcJ9ggxHtS8qNnxdCXLQefMdKmm0ZUqr7600=; b=f4Tcamzr0PTf/yW4MNy4SFYdZV4lO+M9Cpc4znMF9z/kJjWX3ugx96JxBYUEa2DGpO cslGi1zjK4z9FEbE9tkbRmStfgOlnGf7sfbarYefXP778SXoVIK4GP7EkVZBs2mF/lkL u4QM5vLTiHmQrMedNC6WAXOdd3DP9kdIAT3ee1NQtcMorVRNUI5505w0mW+v3RImWjwt hVcAekHozkr/NbCMYoM8YOQV0mkCbNXm6tTD/q4FW2NIekfBLTlXA0p4FTFNvsaqbNgm iZGUHPnTpTXnsZzTEsb1SkLKZYLrVSV+bLqavufd1vZT6piu7bRTLv8j7XRlRcQ0Dy8D ZT4Q== X-Received: by 10.181.29.170 with SMTP id jx10mr9036376wid.50.1420840304251; Fri, 09 Jan 2015 13:51:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.177.218 with HTTP; Fri, 9 Jan 2015 13:51:24 -0800 (PST) In-Reply-To: References: From: Ira McDonald Date: Fri, 9 Jan 2015 16:51:24 -0500 Message-ID: To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a11c26e5c9e1a3a050c3f299c Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call For Adoption: draft-seantek-text-markdown-use-cases X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jan 2015 21:51:48 -0000 --001a11c26e5c9e1a3a050c3f299c Content-Type: text/plain; charset=UTF-8 Hi, +1 Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Fri, Jan 9, 2015 at 3:16 PM, Murray S. Kucherawy wrote: > This note starts a Call For Adoption for > draft-seantek-text-markdown-use-cases. This work was split from > draft-ietf-appsawg-text-markdown which is already undergoing processing > through APPSAWG. > > Note that a Call For Adoption only accepts the document as a first version > for development by the working group. The working group can change it as > it wishes subject to our usual consensus process. > > Please reply with support or objection on this thread by January 23, 2015. > > -MSK, APPSAWG co-chair > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --001a11c26e5c9e1a3a050c3f299c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

+1

Cheers,
- Ira

Ira McDonald (Musician / Software Arc= hitect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Fo= undation Open Printing WG
Secretary - IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated = Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
<= a style=3D"color:rgb(102,0,204)" href=3D"http://sites.google.com/site/highn= orthinc" target=3D"_blank">http://sites.google.com/site/highnorthincmailto: bluer= oofmusic@gmail.com
Winter=C2=A0 579 Park Place=C2=A0 Saline, MI=C2= =A0 48176=C2=A0 734-944-0094
Summer=C2=A0 PO Box 221=C2=A0 Grand Marais,= MI 49839=C2=A0 906-494-2434

<= /div>

On Fri, Jan 9, 2015 at 3:16 PM, Murray S. Ku= cherawy <superuser@gmail.com> wrote:
This note starts a Call Fo= r Adoption for draft-seantek-text-markdown-use-cases.=C2=A0 This work was split from = draft-ietf-appsawg-text-markdown which is already undergoing processing thr= ough APPSAWG.

Note that a Call For Adoption only accepts the documen= t as a first version for development by the working group.=C2=A0 The workin= g group can change it as it wishes subject to our usual consensus process.<= br>
Please reply with support or objection on this thread by January 23,= 2015.

-MSK, APPSAWG co-chair

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


--001a11c26e5c9e1a3a050c3f299c-- From nobody Sat Jan 10 03:24:42 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693801AC3A2 for ; Sat, 10 Jan 2015 03:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Im9l8J4S3L4A for ; Sat, 10 Jan 2015 03:24:37 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::740]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CFE1AC3BB for ; Sat, 10 Jan 2015 03:24:37 -0800 (PST) Received: from pc6 (81.151.167.59) by DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) with Microsoft SMTP Server (TLS) id 15.1.53.17; Sat, 10 Jan 2015 11:24:13 +0000 Message-ID: <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> From: t.petch To: Sam Ruby , Matthew Kerwin References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> Date: Sat, 10 Jan 2015 11:23:12 +0000 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: [81.151.167.59] X-ClientProxiedBy: AMSPR02CA0042.eurprd02.prod.outlook.com (10.242.225.170) To DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DBXPR07MB061; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DBXPR07MB061; X-Forefront-PRVS: 0452022BE1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(2473001)(51704005)(199003)(377454003)(13464003)(479174004)(24454002)(42186005)(62236002)(19580405001)(50226001)(77156002)(23676002)(62966003)(61296003)(50986999)(46102003)(44716002)(47776003)(66066001)(87976001)(19580395003)(50466002)(81686999)(101416001)(64706001)(81816999)(92566002)(76176999)(86362001)(14496001)(33646002)(97736003)(106356001)(105586002)(40100003)(68736005)(2420400003)(77096005)(15975445007)(1456003)(84392001)(93886004)(230783001)(122386002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB061; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB061; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2015 11:24:13.8162 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB061 Archived-At: Cc: IETF Apps Discuss , Larry Masinter Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2015 11:24:41 -0000 ----- Original Message ----- From: "Sam Ruby" To: "Matthew Kerwin" Sent: Sunday, January 04, 2015 1:32 PM > On 01/04/2015 07:22 AM, Matthew Kerwin wrote: > > > > On 2 January 2015 at 00:21, Sam Ruby > > wrote: > > > > A few concrete examples are here: > > > > http://www.ietf.org/mail-__archive/web/apps-discuss/__current/msg13511.h tml > > > > > > It is my hope that by comparing notes we can converge. > > > > ​To be honest, a big reason for using RFC 3986 as a normative reference > > is so I don't have to deal with things like hostnames. If those > > definitions are good enough for the shiny new HTTP/1.1 (which actually > > uses hostnames) then surely they're also sufficient for file: (which > > often doesn't). > > > > BTW who on earth writes localhost as "2130706433"? Or more > > significantly, who on earth *accepts* that as a valid URL? > > I cited three specific examples in: > > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13511.html > > All three of the below are accepted by Chrome, and possibly others: > > file://2130706433/foo > file://[2001::1]/foo > file://０Ｘｃ０．０２５０．０１/foo > > Note that RFC 3986 requires square brackets around IPv6 names, but your > draft does not. The final example involves IDNA processing. > Unfortunately, IDNA processing can't be avoided, nor does RFC 3986 > specify it. Sam I part company with you here. IDNA processing can be avoided - don't do it! Many of the IETF standards have no i18n in general, or IDNA in particular, just as the early standards' views of security would have hackers licking their lips with glee. Retrospectively, security has been added to most protocols, i18n has been added to many. The lack of security is a show stopper for most, but the lack of i18n limits the scope but still renders it useful for many so Matthew's I-D I see as a good step forward, all it needs to say is on this is that i18n (or IDNA) is for further study and we would still have a valuable RFC. I note that kitten is currently wrestling with normalisation in the context of Kerberos, where a loophole could generate a major security breach, and seem to be heading towards saying, if you are not an expert in this area, do not attempt to implement it (my words) i.e. this i18n/IDNA/normalisation area is not well enough engineered to be relied on in some areas. Tom Petch From nobody Sat Jan 10 08:39:39 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F461A1BF6 for ; Sat, 10 Jan 2015 08:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23Q89bCRzNT5 for ; Sat, 10 Jan 2015 08:39:33 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.227]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4CB1A00E7 for ; Sat, 10 Jan 2015 08:39:33 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:7754] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id D7/3E-03035-3C551B45; Sat, 10 Jan 2015 16:39:32 +0000 Received: from [192.168.1.115] (unknown [192.168.1.115]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id B60DD14006A; Sat, 10 Jan 2015 11:39:31 -0500 (EST) Message-ID: <54B155C2.8020505@intertwingly.net> Date: Sat, 10 Jan 2015 11:39:30 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "t.petch" , Matthew Kerwin References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> In-Reply-To: <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: Cc: IETF Apps Discuss , Larry Masinter Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2015 16:39:35 -0000 On 01/10/2015 06:23 AM, t.petch wrote: > ----- Original Message ----- > From: "Sam Ruby" > To: "Matthew Kerwin" > Sent: Sunday, January 04, 2015 1:32 PM >> On 01/04/2015 07:22 AM, Matthew Kerwin wrote: >>> >>> On 2 January 2015 at 00:21, Sam Ruby >> > wrote: >>> >>> A few concrete examples are here: >>> >>> > http://www.ietf.org/mail-__archive/web/apps-discuss/__current/msg13511.h > tml >>> > > >>> >>> It is my hope that by comparing notes we can converge. >>> >>> ​To be honest, a big reason for using RFC 3986 as a normative > reference >>> is so I don't have to deal with things like hostnames. If those >>> definitions are good enough for the shiny new HTTP/1.1 (which > actually >>> uses hostnames) then surely they're also sufficient for file: (which >>> often doesn't). >>> >>> BTW who on earth writes localhost as "2130706433"? Or more >>> significantly, who on earth *accepts* that as a valid URL? >> >> I cited three specific examples in: >> >> > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13511.html >> >> All three of the below are accepted by Chrome, and possibly others: >> >> file://2130706433/foo >> file://[2001::1]/foo >> file://０Ｘｃ０．０２５０．０１/foo >> >> Note that RFC 3986 requires square brackets around IPv6 names, but > your >> draft does not. The final example involves IDNA processing. >> Unfortunately, IDNA processing can't be avoided, nor does RFC 3986 >> specify it. > > Sam > > I part company with you here. IDNA processing can be avoided - don't do > it! > > Many of the IETF standards have no i18n in general, or IDNA in > particular, just as the early standards' views of security would have > hackers licking their lips with glee. > > Retrospectively, security has been added to most protocols, i18n has > been added to many. The lack of security is a show stopper for most, > but the lack of i18n limits the scope but still renders it useful for > many so Matthew's I-D I see as a good step forward, all it needs to say > is on this is that i18n (or IDNA) is for further study and we would > still have a valuable RFC. If that is all it says, then I think the result would be confusing. If it went further and said that it does not represent what a number of popular implementations do (including, at a minimum, current browsers), that would be fine. If it went that way, it should also remove other mentions of what those browsers do. > I note that kitten is currently wrestling with normalisation in the > context of Kerberos, where a loophole could generate a major security > breach, and seem to be heading towards saying, if you are not an expert > in this area, do not attempt to implement it (my words) i.e. this > i18n/IDNA/normalisation area is not well enough engineered to be relied > on in some areas. Saying that this is a specification for Kerberos would be fine. > Tom Petch - Sam Ruby From nobody Sat Jan 10 09:33:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12741A0231 for ; Sat, 10 Jan 2015 09:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_BmmWeG9IGD for ; Sat, 10 Jan 2015 09:33:21 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0084.outbound.protection.outlook.com [207.46.100.84]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D4731A0197 for ; Sat, 10 Jan 2015 09:33:20 -0800 (PST) Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) with Microsoft SMTP Server (TLS) id 15.1.53.17; Sat, 10 Jan 2015 17:33:19 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) by DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) with mapi id 15.01.0053.000; Sat, 10 Jan 2015 17:33:19 +0000 From: Larry Masinter To: t.petch , Sam Ruby , "Matthew Kerwin" Thread-Topic: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt Thread-Index: AQHP2Sc1jlL4BTpaWESzwAi/oPo9Z5yIE6gAgCO64gCAABuVgIAEleyAgAATjYCACUoxz4AAT/cA Date: Sat, 10 Jan 2015 17:33:18 +0000 Message-ID: References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> In-Reply-To: <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:9:8380:992::644] authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DM2PR0201MB0960; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB0960; x-forefront-prvs: 0452022BE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(51704005)(377454003)(87936001)(76576001)(54206007)(97736003)(2656002)(77156002)(62966003)(122556002)(40100003)(99286002)(105586002)(106356001)(106116001)(74316001)(561944003)(101416001)(102836002)(54606007)(2420400003)(15975445007)(46102003)(19580395003)(33656002)(64706001)(76176999)(50986999)(54356999)(86362001)(93886004)(92566002)(2950100001)(230783001)(2900100001)(68736005)(7059030)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0960; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2015 17:33:19.0127 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB0960 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2015 17:33:23 -0000 dC5wZXRjaCBTZW50OiBTYXR1cmRheSwgSmFudWFyeSAxMCwgMjAxNSAzOjIzIEFNDQoNCj4gSSBw YXJ0IGNvbXBhbnkgd2l0aCB5b3UgaGVyZS4gIElETkEgcHJvY2Vzc2luZyBjYW4gYmUgYXZvaWRl ZCAtIGRvbid0DQo+IGRvIGl0IQ0KPiANCj4gTWFueSBvZiB0aGUgSUVURiBzdGFuZGFyZHMgaGF2 ZSBubyBpMThuIGluIGdlbmVyYWwsIG9yIElETkEgaW4NCj4gcGFydGljdWxhciwganVzdCBhcyB0 aGUgZWFybHkgc3RhbmRhcmRzJyB2aWV3cyBvZiBzZWN1cml0eSB3b3VsZCBoYXZlDQo+IGhhY2tl cnMgbGlja2luZyB0aGVpciBsaXBzIHdpdGggZ2xlZS4NCj4gDQo+IFJldHJvc3BlY3RpdmVseSwg c2VjdXJpdHkgaGFzIGJlZW4gYWRkZWQgdG8gbW9zdCBwcm90b2NvbHMsIGkxOG4gaGFzDQo+IGJl ZW4gYWRkZWQgdG8gbWFueS4gIFRoZSBsYWNrIG9mIHNlY3VyaXR5IGlzIGEgc2hvdyBzdG9wcGVy IGZvciBtb3N0LA0KPiBidXQgdGhlIGxhY2sgb2YgaTE4biBsaW1pdHMgdGhlIHNjb3BlIGJ1dCBz dGlsbCByZW5kZXJzIGl0IHVzZWZ1bCBmb3INCj4gbWFueSBzbyBNYXR0aGV3J3MgSS1EIEkgc2Vl IGFzIGEgZ29vZCBzdGVwIGZvcndhcmQsIGFsbCBpdCBuZWVkcyB0byBzYXkNCj4gaXMgb24gdGhp cyBpcyB0aGF0IGkxOG4gKG9yIElETkEpIGlzIGZvciBmdXJ0aGVyIHN0dWR5IGFuZCB3ZSB3b3Vs ZA0KPiBzdGlsbCBoYXZlIGEgdmFsdWFibGUgUkZDLg0KDQpJJ20gbm90IHN1cmUsIGJ1dCBJIHRo aW5rIHlvdSdyZSBhcmd1aW5nIHRoYXQgdGhlICJmaWxlOiIgVVJMIHNjaGVtZSBub3Qgc3BlY2lm eSB0aGUgYmVoYXZpb3Igb2YgZGVhbGluZyB3aXRoIG5vbi1BU0NJSSBmaWxlbmFtZXMuIEkgZG9u J3QgdGhpbmsgYSBkb2N1bWVudCB0aGF0IGRpZG4ndCBzcGVjIHNvbWV0aGluZyB3b3VsZCBtZWV0 IHRoZSBjcml0ZXJpYSBmb3IgUHJvcG9zZWQgU3RhbmRhcmQuIA0KDQpUaGVyZSBpcyBhIHNlcmlv dXMgcHJvcG9zYWwgdG8gbWFrZSBzb21lIG9mIHRoZSBvcHRpb25zIG9mIGhhbmRsaW5nICJmaWxl OiIgaW50byAiaW1wbGVtZW50YXRpb24gZGVwZW5kZW50IiwgYnV0IHdpdGggbGVhdmluZyBzb21l IGtpbmRzIG9mIHJlbGF0aXZlIHBhdGggbmFtZXMgaW50ZXJvcGVyYWJsZSwgYW5kICBhIGRpc2N1 c3Npb24gYWJvdXQgaG93IHRvIHN0cnVjdHVyZSB0aGUgZG9jdW1lbnQgc28gdGhhdCBpbXBsZW1l bnRhdGlvbnMgY2FuIGJlIGNvbnNpZGVyZWQsIHJlZ2lzdGVyZWQsIG9yIGRlc2NyaWJlZCBpbmRl cGVuZGVudGx5LiBBYm91dCB3aGV0aGVyIHNvbWUgb2YgdGhlIHNwZWNpZmljYXRpb25zIG5lZWRl ZCBmb3Igbm9ybWF0aXZlIHJlZmVyZW5jZSBhcmUgcHJvcHJpZXRhcnkuDQoNCldlIGFjdHVhbGx5 IGhhdmUgZGF0YSBhYm91dCBob3cgaW1wbGVtZW50YXRpb25zIHJlc3BvbmQuIFRoZXJlIGlzIGFu IG9wcG9ydHVuaXR5IHRvIG1ha2UgdGhpcyBjb3JuZXIgb2YgdGhlIHdlYiBtb3JlIG9wZW5seSBz cGVjaWZpZWQgc28gYXBwbGljYXRpb24gd3JpdGVycyBjYW4gYnVpbGQgcGxhdGZvcm0taW5kZXBl bmRlbnQgY29kZSB1c2luZyBhbiBpbnRlcm9wZXJhYmxlIHN1YnNldCwgYW5kIHBsYXRmb3JtIGJ1 aWxkZXJzIGFuZCBtYWludGFpbmVycyBjYW4ga25vdyB3aGF0IHRvIGNvZGUgdG8uDQoNCiJmb3Ig ZnVydGhlciBzdHVkeSIgaXMgbm90IGdlbmVyYWxseSBmb3VuZCBpbiBJRVRGIHN0YW5kYXJkcywg YWx0aG91Z2ggaXQgaXMgYSB0ZWNobmlxdWUgdXNlZCBpbiBhY2FkZW1pYyBwYXBlcnMgYW5kIHNl ZW4gaW4gb3RoZXIgU0RPcy4gV2UndmUgc3R1ZGllZC4gV2UncmUgbWFraW5nIHByb2dyZXNzLiBL ZWVwIGdvaW5nLg0KDQpMYXJyeQ0KLS0NCmh0dHA6Ly9sYXJyeS5tYXNpbnRlci5uZXQNCg0KDQoN Cg0K From nobody Sat Jan 10 10:16:23 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6AB11A6F07 for ; Sat, 10 Jan 2015 10:16:19 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoNiGIjBNQz3 for ; Sat, 10 Jan 2015 10:16:17 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 08A021A0373 for ; Sat, 10 Jan 2015 10:16:17 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DEF3322E260 for ; Sat, 10 Jan 2015 13:16:15 -0500 (EST) Message-ID: <54B16C2B.9050604@seantek.com> Date: Sat, 10 Jan 2015 10:15:07 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> In-Reply-To: <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2015 18:16:20 -0000 [SNIPS] > file://2130706433/foo > file://[2001::1]/foo > file://=EF=BC=90=EF=BC=B8=EF=BD=83=EF=BC=90=EF=BC=8E=EF=BC=90=EF=BC=92=EF= =BC=95=EF=BC=90=EF=BC=8E=EF=BC=90=EF=BC=91/foo > > Note that RFC 3986 requires square brackets around IPv6 names, but > your >> draft does not. The final example involves IDNA processing. >> Unfortunately, IDNA processing can't be avoided, nor does RFC 3986 >> specify it. > Sam > > I part company with you here. IDNA processing can be avoided - don't d= o > it! > > Many of the IETF standards have no i18n in general, or IDNA in > particular, just as the early standards' views of security would have > hackers licking their lips with glee. > > Retrospectively, security has been added to most protocols, i18n has > been added to many. The lack of security is a show stopper for most, > but the lack of i18n limits the scope but still renders it useful for > many so Matthew's I-D I see as a good step forward, all it needs to say= > is on this is that i18n (or IDNA) is for further study and we would > still have a valuable RFC. (+1...?) Look here's the deal as I see it. URIs are made of the following=20 *characters* only: ALPHA DIGIT - . _ ~ : / ? # [ ] @ ! $ & ' ( ) * + , ; =3D % That's it. Folks are confusing the "web browser text box at the top" with URIs. Web = browsers can display and accept whatever characters they want in the=20 address box. How they do that is not an RFC 3986 issue. It might be=20 governed by some de-jure or de-facto Web "standards" (or RFC 3987?), but = it's not directly relevant to URIs. The end. Nowadays it's not even a "URL bar" or "address bar". It's variously=20 called an "omnibox" and has a lot of code running behind it to do=20 context-sensitive things with lots of additional user experience=20 widgets. For example if you type "? ietf" in Chrome (and others...I=20 believe Internet Explorer 6 had this) it's going to do something that=20 has nothing to do with URIs. With respect to file: URIs, if this is a draft about file: URIs, stick=20 with what URIs are. See RFC 3986. (Notably, an advantage of clean=20 specifications around RFC 3986 is that you can broadly detect what=20 things are NOT URIs. E.g., "? ietf" is NOT a URI so a magic box can put=20 it in a different category, and a command-line tool can do something=20 intelligent that is not related to URI retrieval.) Thanks, Sean From nobody Sat Jan 10 10:28:47 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9306C1A1BEC for ; Sat, 10 Jan 2015 10:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.154 X-Spam-Level: * X-Spam-Status: No, score=1.154 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIifuFgLOAeB for ; Sat, 10 Jan 2015 10:28:42 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0772.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::772]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CCA11A0373 for ; Sat, 10 Jan 2015 10:28:42 -0800 (PST) Received: from pc6 (81.151.167.59) by DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) with Microsoft SMTP Server (TLS) id 15.1.53.17; Sat, 10 Jan 2015 18:26:36 +0000 Message-ID: <023b01d02d02$d73e1920$4001a8c0@gateway.2wire.net> From: t.petch To: Larry Masinter , Matthew Kerwin References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> Date: Sat, 10 Jan 2015 18:24:29 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: AMSPR02CA0036.eurprd02.prod.outlook.com (10.242.225.164) To DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DBXPR07MB063; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DBXPR07MB063; X-Forefront-PRVS: 0452022BE1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(13464003)(199003)(377454003)(51704005)(64706001)(101416001)(66066001)(2420400003)(81686999)(50986999)(81816999)(76176999)(77156002)(561944003)(47776003)(46102003)(1456003)(62966003)(77096005)(61296003)(68736005)(92566002)(50466002)(23676002)(19580395003)(19580405001)(40100003)(105586002)(97736003)(84392001)(93886004)(122386002)(42186005)(50226001)(14496001)(15975445007)(62236002)(44716002)(230783001)(33646002)(106356001)(86362001)(87976001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB063; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB063; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2015 18:26:36.5975 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB063 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2015 18:28:45 -0000 ----- Original Message ----- From: "Larry Masinter" To: "t.petch" ; "Sam Ruby" ; "Matthew Kerwin" Cc: "IETF Apps Discuss" Sent: Saturday, January 10, 2015 5:33 PM > t.petch Sent: Saturday, January 10, 2015 3:23 AM > > > I part company with you here. IDNA processing can be avoided - don't > > do it! > > > > Many of the IETF standards have no i18n in general, or IDNA in > > particular, just as the early standards' views of security would have > > hackers licking their lips with glee. > > > > Retrospectively, security has been added to most protocols, i18n has > > been added to many. The lack of security is a show stopper for most, > > but the lack of i18n limits the scope but still renders it useful for > > many so Matthew's I-D I see as a good step forward, all it needs to say > > is on this is that i18n (or IDNA) is for further study and we would > > still have a valuable RFC. > > I'm not sure, but I think you're arguing that the "file:" URL scheme not specify the behavior of dealing with non-ASCII filenames. I don't think a document that didn't spec something would meet the criteria for Proposed Standard. > > There is a serious proposal to make some of the options of handling "file:" into "implementation dependent", but with leaving some kinds of relative path names interoperable, and a discussion about how to structure the document so that implementations can be considered, registered, or described independently. About whether some of the specifications needed for normative reference are proprietary. > > We actually have data about how implementations respond. There is an opportunity to make this corner of the web more openly specified so application writers can build platform-independent code using an interoperable subset, and platform builders and maintainers can know what to code to. > > "for further study" is not generally found in IETF standards, although it is a technique used in academic papers and seen in other SDOs. We've studied. We're making progress. Keep going. Larry, Indeed we do not but we do have Applicability Statements which seem to me to be semantically the same. Thinking laterally, I see that http://tools.ietf.org/html/draft-ietf-nfsv4-rfc3530bis-35#section-12 is in the RFC Editor's Queue and so has IETF consensus. And by our IPR rules we can lift any text we like from it, and it seems a very good summary of the situation, perhaps a bit long for our purposes but the basis of a way forward. (not just for file:// but for any other scheme or indeed for other IETF work). I am fine with vendor extensions - where would a vendor be if they did not have them? - but am resistant to making them a standard, rather a non-normative appendix - some WGs would have a separate I-D for an implementation repoirt but I find that overcomplex. Equally, if such examples cover three or more widely differing approaches, I find the argument that we have omitted Brand X spurious. Let Brand X raise their own ISE submission, do not let them delay the production of a useful RFC. Tom Petch > Larry > -- > http://larry.masinter.net From nobody Sat Jan 10 10:54:03 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAD41A6F22 for ; Sat, 10 Jan 2015 10:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAF-mTy6PUhQ for ; Sat, 10 Jan 2015 10:53:59 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0743.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::743]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0261A6F20 for ; Sat, 10 Jan 2015 10:53:58 -0800 (PST) Received: from pc6 (81.151.167.59) by AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) with Microsoft SMTP Server (TLS) id 15.1.53.17; Sat, 10 Jan 2015 18:51:52 +0000 Message-ID: <000701d02d06$5f028a00$4001a8c0@gateway.2wire.net> From: t.petch To: Sean Leonard , References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> Date: Sat, 10 Jan 2015 18:50:52 +0000 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: [81.151.167.59] X-ClientProxiedBy: AM3PR01CA033.eurprd01.prod.exchangelabs.com (10.141.191.23) To AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:AMSPR07MB051; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:AMSPR07MB051; X-Forefront-PRVS: 0452022BE1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(51704005)(189002)(199003)(13464003)(377454003)(2473001)(230783001)(50986999)(76176999)(46102003)(86362001)(77156002)(62966003)(106356001)(44736004)(97736003)(81686999)(81816999)(92566002)(116806002)(50226001)(107886001)(84392001)(50466002)(40100003)(42186005)(93886004)(64706001)(1456003)(19580395003)(19580405001)(15975445007)(77096005)(33646002)(68736005)(61296003)(44716002)(87976001)(105586002)(101416001)(47776003)(66066001)(23676002)(122386002); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB051; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB051; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2015 18:51:52.8070 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB051 Archived-At: Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2015 18:54:01 -0000 ----- Original Message ----- From: "Sean Leonard" To: Sent: Saturday, January 10, 2015 6:15 PM > [SNIPS] > > file://2130706433/foo > > file://[2001::1]/foo > > file://０Ｘｃ０．０２５０．０１/foo > > > > Note that RFC 3986 requires square brackets around IPv6 names, but > > your > >> draft does not. The final example involves IDNA processing. > >> Unfortunately, IDNA processing can't be avoided, nor does RFC 3986 > >> specify it. > > Sam > > > > I part company with you here. IDNA processing can be avoided - don't do > > it! > > > > Many of the IETF standards have no i18n in general, or IDNA in > > particular, just as the early standards' views of security would have > > hackers licking their lips with glee. > > > > Retrospectively, security has been added to most protocols, i18n has > > been added to many. The lack of security is a show stopper for most, > > but the lack of i18n limits the scope but still renders it useful for > > many so Matthew's I-D I see as a good step forward, all it needs to say > > is on this is that i18n (or IDNA) is for further study and we would > > still have a valuable RFC. > (+1...?) > > Look here's the deal as I see it. URIs are made of the following > *characters* only: > ALPHA DIGIT - . _ ~ > : / ? # [ ] @ > ! $ & ' ( ) * + , ; = > % > > That's it. > > Folks are confusing the "web browser text box at the top" with URIs. Web > browsers can display and accept whatever characters they want in the > address box. How they do that is not an RFC 3986 issue. It might be > governed by some de-jure or de-facto Web "standards" (or RFC 3987?), but > it's not directly relevant to URIs. The end. > > Nowadays it's not even a "URL bar" or "address bar". It's variously > called an "omnibox" and has a lot of code running behind it to do > context-sensitive things with lots of additional user experience > widgets. For example if you type "? ietf" in Chrome (and others...I > believe Internet Explorer 6 had this) it's going to do something that > has nothing to do with URIs. Sean Indeed it does. Firing up my trusty IE6 and entering '? ietf', I am taken to bing with q=ietf and there is all I need. Great vendor extension but no way should a Standards Track RFC go to such a level of detail (not that you were suggesting it should).. Tom Petch > With respect to file: URIs, if this is a draft about file: URIs, stick > with what URIs are. See RFC 3986. (Notably, an advantage of clean > specifications around RFC 3986 is that you can broadly detect what > things are NOT URIs. E.g., "? ietf" is NOT a URI so a magic box can put > it in a different category, and a command-line tool can do something > intelligent that is not related to URI retrieval.) > > Thanks, > > Sean > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Sat Jan 10 11:21:41 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2C41A6FFC for ; Sat, 10 Jan 2015 11:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ON7jQRYExlFf for ; Sat, 10 Jan 2015 11:21:36 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.229]) by ietfa.amsl.com (Postfix) with ESMTP id 847DA1A7002 for ; Sat, 10 Jan 2015 11:21:36 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:26190] helo=rubix) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id DD/2C-09074-FBB71B45; Sat, 10 Jan 2015 19:21:36 +0000 Received: from rubymacb.local (cpe-098-027-051-253.nc.res.rr.com [98.27.51.253]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 1591B140101 for ; Sat, 10 Jan 2015 14:21:36 -0500 (EST) Message-ID: <54B17BBE.4000900@intertwingly.net> Date: Sat, 10 Jan 2015 14:21:34 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> In-Reply-To: <54B16C2B.9050604@seantek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2015 19:21:39 -0000 On 1/10/15 1:15 PM, Sean Leonard wrote: > [SNIPS] >> file://2130706433/foo >> file://[2001::1]/foo >> file://０Ｘｃ０．０２５０．０１/foo >> >> Note that RFC 3986 requires square brackets around IPv6 names, but >> your >>> draft does not. The final example involves IDNA processing. >>> Unfortunately, IDNA processing can't be avoided, nor does RFC 3986 >>> specify it. >> Sam >> >> I part company with you here. IDNA processing can be avoided - don't do >> it! >> >> Many of the IETF standards have no i18n in general, or IDNA in >> particular, just as the early standards' views of security would have >> hackers licking their lips with glee. >> >> Retrospectively, security has been added to most protocols, i18n has >> been added to many. The lack of security is a show stopper for most, >> but the lack of i18n limits the scope but still renders it useful for >> many so Matthew's I-D I see as a good step forward, all it needs to say >> is on this is that i18n (or IDNA) is for further study and we would >> still have a valuable RFC. > (+1...?) > > Look here's the deal as I see it. URIs are made of the following > *characters* only: > ALPHA DIGIT - . _ ~ > : / ? # [ ] @ > ! $ & ' ( ) * + , ; = > % > > That's it. > > Folks are confusing the "web browser text box at the top" with URIs. Web > browsers can display and accept whatever characters they want in the > address box. How they do that is not an RFC 3986 issue. It might be > governed by some de-jure or de-facto Web "standards" (or RFC 3987?), but > it's not directly relevant to URIs. The end. > > Nowadays it's not even a "URL bar" or "address bar". It's variously > called an "omnibox" and has a lot of code running behind it to do > context-sensitive things with lots of additional user experience > widgets. For example if you type "? ietf" in Chrome (and others...I > believe Internet Explorer 6 had this) it's going to do something that > has nothing to do with URIs. I call strawman. Nobody here mentioned a quote "web browser text box at the top" end-quote. > With respect to file: URIs, if this is a draft about file: URIs, stick > with what URIs are. See RFC 3986. (Notably, an advantage of clean > specifications around RFC 3986 is that you can broadly detect what > things are NOT URIs. E.g., "? ietf" is NOT a URI so a magic box can put > it in a different category, and a command-line tool can do something > intelligent that is not related to URI retrieval.) I'm working on a specification how strings that can found in the href attribute of HTML elements like , , and . Some of those strings may start with "file:". I think it would be a good idea for us to explore whether there is a relationship between those strings and RFC 3986. I'll go further and state that it is in nobody's best interest for there to be overlapping and conflicting standards in this area. > Thanks, > > Sean - Sam Ruby From nobody Sat Jan 10 12:29:37 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C591A8837 for ; Sat, 10 Jan 2015 12:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.061 X-Spam-Level: X-Spam-Status: No, score=0.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, J_CHICKENPOX_21=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_48=0.6, MANY_SPAN_IN_TEXT=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbluYJuy1cic for ; Sat, 10 Jan 2015 12:29:30 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 121191A8828 for ; Sat, 10 Jan 2015 12:29:28 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F15FB22E261 for ; Sat, 10 Jan 2015 15:29:25 -0500 (EST) Message-ID: <54B18B61.8010308@seantek.com> Date: Sat, 10 Jan 2015 12:28:17 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> In-Reply-To: <54B17BBE.4000900@intertwingly.net> Content-Type: multipart/alternative; boundary="------------060702010501050501030505" Archived-At: Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2015 20:29:35 -0000 This is a multi-part message in MIME format. --------------060702010501050501030505 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/10/2015 11:21 AM, Sam Ruby wrote: > On 1/10/15 1:15 PM, Sean Leonard wrote: >> [SNIPS] >>> file://2130706433/foo >>> file://[2001::1]/foo >>> file://０Ｘｃ０．０２５０．０１/foo >>> >>> Note that RFC 3986 requires square brackets around IPv6 names, but >>> your >>>> draft does not. The final example involves IDNA processing. >>>> Unfortunately, IDNA processing can't be avoided, nor does RFC 3986 >>>> specify it. >>> Sam >>> >>> I part company with you here. IDNA processing can be avoided - >>> don't do >>> it! >>> >>> Many of the IETF standards have no i18n in general, or IDNA in >>> particular, just as the early standards' views of security would have >>> hackers licking their lips with glee. >>> >>> Retrospectively, security has been added to most protocols, i18n has >>> been added to many. The lack of security is a show stopper for most, >>> but the lack of i18n limits the scope but still renders it useful for >>> many so Matthew's I-D I see as a good step forward, all it needs to say >>> is on this is that i18n (or IDNA) is for further study and we would >>> still have a valuable RFC. >> (+1...?) >> >> Look here's the deal as I see it. URIs are made of the following >> *characters* only: >> ALPHA DIGIT - . _ ~ >> : / ? # [ ] @ >> ! $ & ' ( ) * + , ; = >> % >> >> That's it. >> >> Folks are confusing the "web browser text box at the top" with URIs. Web >> browsers can display and accept whatever characters they want in the >> address box. How they do that is not an RFC 3986 issue. It might be >> governed by some de-jure or de-facto Web "standards" (or RFC 3987?), but >> it's not directly relevant to URIs. The end. >> >> Nowadays it's not even a "URL bar" or "address bar". It's variously >> called an "omnibox" and has a lot of code running behind it to do >> context-sensitive things with lots of additional user experience >> widgets. For example if you type "? ietf" in Chrome (and others...I >> believe Internet Explorer 6 had this) it's going to do something that >> has nothing to do with URIs. > > I call strawman. Nobody here mentioned a quote "web browser text box > at the top" end-quote. > >> With respect to file: URIs, if this is a draft about file: URIs, stick >> with what URIs are. See RFC 3986. (Notably, an advantage of clean >> specifications around RFC 3986 is that you can broadly detect what >> things are NOT URIs. E.g., "? ietf" is NOT a URI so a magic box can put >> it in a different category, and a command-line tool can do something >> intelligent that is not related to URI retrieval.) > > I'm working on a specification how strings that can found in the href > attribute of HTML elements like , , and . Some of > those strings may start with "file:". > > I think it would be a good idea for us to explore whether there is a > relationship between those strings and RFC 3986. I'll go further and > state that it is in nobody's best interest for there to be overlapping > and conflicting standards in this area. http://www.w3.org/TR/html401/struct/links.html#h-12.1 http://www.w3.org/TR/html401/types.html#type-uri "This specification uses the term URI as defined in[URI] (see also[RFC1630] )." [URI] = RFC 2396 "Uniform Resource Identifiers (URI): Generic Syntax" , T. Berners-Lee, R. Fielding, L. Masinter, August 1998. Note that RFC 2396 updates[RFC1738] and[RFC1808] . From the DTD: %URI; #IMPLIED -- URI for linked resource -- ... " -- a Uniform Resource Identifier, see[URI] --> ********** HTML5: http://www.w3.org/TR/html5/links.html#attr-hyperlink-href The|href|attribute on|a |and|area |elements must have a value that is avalid URL potentially surrounded by spaces . A string is avalid URL potentially surrounded by spacesif, afterstripping leading and trailing whitespace from it, it is avalid URL . AURLis avalid URLif it conforms to the authoring conformance requirements in the URL standard.[URL] [URL] *Note:*URLs can be used in numerous different manners, in many differing contexts. For the purpose of producing strict URLs one may wish to consider[RFC3986] [RFC3987] . The W3C URL specification defines the term URL, various algorithms for dealing with URLs, and an API for constructing, parsing, and resolving URLs. Developers of Web browsers are advised to keep abreast of the latest URL developments by tracking the progress ofhttps://url.spec.whatwg.org/. We expect that the W3C URL draft will evolve along the Recommendation track as the community converges on a definition of URL processing. Most of the URL-related terms used in the HTML specification (*URL*,*absolute URL *,*relative URL *,*relative schemes*,*scheme component*,*scheme data*,*username*,*password*,*host*,*port*,*path*,*query*,*fragment*,*percent encode *,*get the base*, and*UTF-8 percent encode *) can be straightforwardly mapped to the terminology of[RFC3986] [RFC3987] . The|URLUtils |(formerly known as|URL|) collection of attributes (e.g.|href|and|protocol|) and its required definitions (*input *,*query encoding*,*url*,*update steps*,*set the input*) are considered common practice nowadays. Some of the URL-related terms are still being refined (e.g.*URL parser *,*parse errors*,*URL serializer*,*default encode set *, and*percent decode *). As a word of caution, there are notable differences in the manner in which Web browsers and other software stacks outside the HTML context handle URLs. While no changes would be accepted to URL processing that would break existing Web content, some important parts of URL processing should therefore be considered as implementation-defined (e.g. parsing file: URLs or operating on URLs that would be syntax errors under the[RFC3986] [RFC3987] syntax). URL (URL:http://www.w3.org/TR/url/), E. Arvidsson, M.[tm] Smith. W3C. ****************************** --------------060702010501050501030505 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 1/10/2015 11:21 AM, Sam Ruby wrote:
On 1/10/15 1:15 PM, Sean Leonard wrote:
[SNIPS]
file://2130706433/foo
file://[2001::1]/foo
file://０Ｘｃ０．０２５０．０１/foo

Note that RFC 3986 requires square brackets around IPv6 names, but
your
draft does not.  The final example involves IDNA processing.
Unfortunately, IDNA processing can't be avoided, nor does RFC 3986
specify it.
Sam

I part company with you here.  IDNA processing can be avoided - don't do
it!

Many of the IETF standards have no i18n in general, or IDNA in
particular, just as the early standards' views of security would have
hackers licking their lips with glee.

Retrospectively, security has been added to most protocols, i18n has
been added to many.  The lack of security is a show stopper for most,
but the lack of i18n limits the scope but still renders it useful for
many so Matthew's I-D I see as a good step forward, all it needs to say
is on this is that i18n (or IDNA) is for further study and we would
still have a valuable RFC.
(+1...?)

Look here's the deal as I see it. URIs are made of the following
*characters* only:
ALPHA DIGIT - . _ ~
: / ? # [ ] @
! $ & ' ( ) * + , ; =
%

That's it.

Folks are confusing the "web browser text box at the top" with URIs. Web
browsers can display and accept whatever characters they want in the
address box. How they do that is not an RFC 3986 issue. It might be
governed by some de-jure or de-facto Web "standards" (or RFC 3987?), but
it's not directly relevant to URIs. The end.

Nowadays it's not even a "URL bar" or "address bar". It's variously
called an "omnibox" and has a lot of code running behind it to do
context-sensitive things with lots of additional user experience
widgets. For example if you type "? ietf" in Chrome (and others...I
believe Internet Explorer 6 had this) it's going to do something that
has nothing to do with URIs.

I call strawman.  Nobody here mentioned a quote "web browser text box at the top" end-quote.

With respect to file: URIs, if this is a draft about file: URIs, stick
with what URIs are. See RFC 3986. (Notably, an advantage of clean
specifications around RFC 3986 is that you can broadly detect what
things are NOT URIs. E.g., "? ietf" is NOT a URI so a magic box can put
it in a different category, and a command-line tool can do something
intelligent that is not related to URI retrieval.)

I'm working on a specification how strings that can found in the href attribute of HTML elements like <link>, <base>, and <a>.  Some of those strings may start with "file:".

I think it would be a good idea for us to explore whether there is a relationship between those strings and RFC 3986.  I'll go further and state that it is in nobody's best interest for there to be overlapping and conflicting standards in this area.
http://www.w3.org/TR/html401/struct/links.html#h-12.1

http://www.w3.org/TR/html401/types.html#type-uri

"This specification uses the term URI as defined in [URI] (see also [RFC1630])."


[URI] = RFC 2396
"Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, August 1998. Note that RFC 2396 updates [RFC1738] and [RFC1808].

From the DTD:

<!ATTLIST A
...
  href        %URI;          #IMPLIED  -- URI for linked resource --
...
<!ENTITY % URI "CDATA"
    -- a Uniform Resource Identifier,
       see [URI]
    -->

**********
HTML5:

http://www.w3.org/TR/html5/links.html#attr-hyperlink-href

The href attribute on a and area elements must have a value that is a valid URL potentially surrounded by spaces.

A string is a valid URL potentially surrounded by spaces if, after stripping leading and trailing whitespace from it, it is a valid URL.

A URL is a valid URL if it conforms to the authoring conformance requirements in the URL standard. [URL]

[URL]

Note: URLs can be used in numerous different manners, in many differing contexts. For the purpose of producing strict URLs one may wish to consider[RFC3986] [RFC3987]. The W3C URL specification defines the term URL, various algorithms for dealing with URLs, and an API for constructing, parsing, and resolving URLs. Developers of Web browsers are advised to keep abreast of the latest URL developments by tracking the progress ofhttps://url.spec.whatwg.org/. We expect that the W3C URL draft will evolve along the Recommendation track as the community converges on a definition of URL processing.

Most of the URL-related terms used in the HTML specification (URL, absolute URL, relative URL, relative schemes, scheme component, scheme data,username, password, host, port, path, query, fragment, percent encode, get the base, and UTF-8 percent encode) can be straightforwardly mapped to the terminology of [RFC3986] [RFC3987]. The URLUtils (formerly known as URL) collection of attributes (e.g. href and protocol) and its required definitions (input, query encoding, url, update steps, set the input) are considered common practice nowadays. Some of the URL-related terms are still being refined (e.g. URL parser, parse errors, URL serializer, default encode set, and percent decode).

As a word of caution, there are notable differences in the manner in which Web browsers and other software stacks outside the HTML context handle URLs. While no changes would be accepted to URL processing that would break existing Web content, some important parts of URL processing should therefore be considered as implementation-defined (e.g. parsing file: URLs or operating on URLs that would be syntax errors under the [RFC3986] [RFC3987] syntax).

URL (URL: http://www.w3.org/TR/url/), E. Arvidsson, M.[tm] Smith. W3C.

******************************

--------------060702010501050501030505-- From nobody Sat Jan 10 12:40:27 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A255D1A8828 for ; Sat, 10 Jan 2015 12:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qS3PiGu4KVAG for ; Sat, 10 Jan 2015 12:40:23 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 825911A036D for ; Sat, 10 Jan 2015 12:40:23 -0800 (PST) Received: from netb ([89.204.137.193]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M1BMy-1XuZLc0fPM-00tF2L; Sat, 10 Jan 2015 21:40:17 +0100 From: Bjoern Hoehrmann To: Matthew Kerwin Date: Sat, 10 Jan 2015 21:40:14 +0100 Message-ID: <2e33balagh0scqtgaf87vh48vc8l9jm7g7@hive.bjoern.hoehrmann.de> References: <54922C81.4030908@intertwingly.net> <5494C6AF.4070902@intertwingly.net> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:NyeP2MX7ay7gCNkpfgDtobRS6TckW9K5kFsCh+vRMoVyvjITunv CrEsjSbF29MnuTMZU/LYMx9QZie76nZgvSBtYmEswY9SdnhdeWHgnWznCT7ylXnyisGLERN SKXl/y0BairzVRQZM+gYVX6R6AdZ7zXpx34/CvNXYrtftoEAWoRafT1NAj5FEHDdgqJczt7 sl2ltIkBYm2hf7g9Y/Yig== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-kerwin-file-scheme and hosts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2015 20:40:25 -0000 * Matthew Kerwin wrote: >On 20 December 2014 at 10:45, Sam Ruby wrote: >> file://[2001::1]/foo > >I thought this already worked with RFC 3986..? See the "IP-literal" >construct in , which is >used in "host". With the RFC 3986 grammar it would parse as ["URI", [ ["scheme", [ ["ALPHA", [], 0, 1], ["ALPHA", [], 1, 2], ["ALPHA", [], 2, 3], ["ALPHA", [], 3, 4]], 0, 4], ["hier-part", [ ["authority", [ ["host", [ ["IP-literal", [ ["IPv6address", [ ["h16", [ ... ["h16", [ ... ["path-abempty", [ ["segment", [ ["pchar", [ ... -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de D-10243 Berlin PGP Pub. KeyID: 0xA4357E78 http://www.bjoernsworld.de Available for hire in Berlin (early 2015) http://www.websitedev.de/ From nobody Sat Jan 10 12:57:12 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178701A876C for ; Sat, 10 Jan 2015 12:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6l0q-Vlqmyet for ; Sat, 10 Jan 2015 12:57:08 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.228]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6171A1A34 for ; Sat, 10 Jan 2015 12:57:08 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:36695] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 51/2B-03035-22291B45; Sat, 10 Jan 2015 20:57:07 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id CE92014006A; Sat, 10 Jan 2015 15:57:06 -0500 (EST) Message-ID: <54B19221.2080203@intertwingly.net> Date: Sat, 10 Jan 2015 15:57:05 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Bjoern Hoehrmann , Matthew Kerwin References: <54922C81.4030908@intertwingly.net> <5494C6AF.4070902@intertwingly.net> <2e33balagh0scqtgaf87vh48vc8l9jm7g7@hive.bjoern.hoehrmann.de> In-Reply-To: <2e33balagh0scqtgaf87vh48vc8l9jm7g7@hive.bjoern.hoehrmann.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-kerwin-file-scheme and hosts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2015 20:57:10 -0000 [never saw Matthew's reply. still can't find it. weird] On 01/10/2015 03:40 PM, Bjoern Hoehrmann wrote: > * Matthew Kerwin wrote: >> On 20 December 2014 at 10:45, Sam Ruby wrote: > >>> file://[2001::1]/foo >> >> I thought this already worked with RFC 3986..? See the "IP-literal" >> construct in , which is >> used in "host". My point was that it works with RFC 3986, but doesn't work with draft-kerwin-file-scheme. I encourage you to look at section 2.2 of RFC 4291. There is a very simple fix for this. I believe that what you want to refer to instead is section 2 of RFC 6874. - Sam Ruby From nobody Sat Jan 10 13:06:02 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83DC1A8837 for ; Sat, 10 Jan 2015 13:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsXzkBmzHxMV for ; Sat, 10 Jan 2015 13:05:58 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.225]) by ietfa.amsl.com (Postfix) with ESMTP id A87491A876C for ; Sat, 10 Jan 2015 13:05:58 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:38191] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id BC/72-03035-53491B45; Sat, 10 Jan 2015 21:05:58 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 05E2B14006A; Sat, 10 Jan 2015 16:05:57 -0500 (EST) Message-ID: <54B19435.8070401@intertwingly.net> Date: Sat, 10 Jan 2015 16:05:57 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sean Leonard , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> In-Reply-To: <54B18B61.8010308@seantek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2015 21:06:02 -0000 On 01/10/2015 03:28 PM, Sean Leonard wrote: > On 1/10/2015 11:21 AM, Sam Ruby wrote: >> On 1/10/15 1:15 PM, Sean Leonard wrote: >>> [SNIPS] >>>> file://2130706433/foo >>>> file://[2001::1]/foo >>>> file://０Ｘｃ０．０２５０．０１/foo >>>> >>>> Note that RFC 3986 requires square brackets around IPv6 names, but >>>> your >>>>> draft does not. The final example involves IDNA processing. >>>>> Unfortunately, IDNA processing can't be avoided, nor does RFC 3986 >>>>> specify it. >>>> Sam >>>> >>>> I part company with you here. IDNA processing can be avoided - >>>> don't do >>>> it! >>>> >>>> Many of the IETF standards have no i18n in general, or IDNA in >>>> particular, just as the early standards' views of security would have >>>> hackers licking their lips with glee. >>>> >>>> Retrospectively, security has been added to most protocols, i18n has >>>> been added to many. The lack of security is a show stopper for most, >>>> but the lack of i18n limits the scope but still renders it useful for >>>> many so Matthew's I-D I see as a good step forward, all it needs to say >>>> is on this is that i18n (or IDNA) is for further study and we would >>>> still have a valuable RFC. >>> (+1...?) >>> >>> Look here's the deal as I see it. URIs are made of the following >>> *characters* only: >>> ALPHA DIGIT - . _ ~ >>> : / ? # [ ] @ >>> ! $ & ' ( ) * + , ; = >>> % >>> >>> That's it. >>> >>> Folks are confusing the "web browser text box at the top" with URIs. Web >>> browsers can display and accept whatever characters they want in the >>> address box. How they do that is not an RFC 3986 issue. It might be >>> governed by some de-jure or de-facto Web "standards" (or RFC 3987?), but >>> it's not directly relevant to URIs. The end. >>> >>> Nowadays it's not even a "URL bar" or "address bar". It's variously >>> called an "omnibox" and has a lot of code running behind it to do >>> context-sensitive things with lots of additional user experience >>> widgets. For example if you type "? ietf" in Chrome (and others...I >>> believe Internet Explorer 6 had this) it's going to do something that >>> has nothing to do with URIs. >> >> I call strawman. Nobody here mentioned a quote "web browser text box >> at the top" end-quote. >> >>> With respect to file: URIs, if this is a draft about file: URIs, stick >>> with what URIs are. See RFC 3986. (Notably, an advantage of clean >>> specifications around RFC 3986 is that you can broadly detect what >>> things are NOT URIs. E.g., "? ietf" is NOT a URI so a magic box can put >>> it in a different category, and a command-line tool can do something >>> intelligent that is not related to URI retrieval.) >> >> I'm working on a specification how strings that can found in the href >> attribute of HTML elements like , , and . Some of >> those strings may start with "file:". >> >> I think it would be a good idea for us to explore whether there is a >> relationship between those strings and RFC 3986. I'll go further and >> state that it is in nobody's best interest for there to be overlapping >> and conflicting standards in this area. I'm not sure what point you are trying to make as all you have provided are links and excerpts. But I'll try to provide some background on the information you quoted. > http://www.w3.org/TR/html401/struct/links.html#h-12.1 > > http://www.w3.org/TR/html401/types.html#type-uri > > "This specification uses the term URI as defined in[URI] > (see also[RFC1630] > )." > > [URI] = RFC 2396 > "Uniform Resource Identifiers (URI): Generic Syntax" > , T. Berners-Lee, R. Fielding, L. > Masinter, August 1998. Note that RFC 2396 updates[RFC1738] > and[RFC1808] > . > > From the DTD: > > ... > href %URI; #IMPLIED -- URI for linked resource -- > > ... > > " > -- a Uniform Resource Identifier, > see[URI] > --> An obsolete W3C recommendation indeed points to an obsolete RFC. > ********** > HTML5: > > http://www.w3.org/TR/html5/links.html#attr-hyperlink-href > > The|href|attribute on|a > |and|area > |elements > must have a value that is avalid URL potentially surrounded by spaces > . > > A string is avalid URL potentially surrounded by spacesif, > afterstripping leading and trailing whitespace > from > it, it is avalid URL > . > > AURLis avalid URLif it conforms to the authoring conformance > requirements in the URL standard.[URL] > Permit me to introduce myself. I'm one of the co-chairs of the W3C HTML Working group. I am indeed aware of this work. > [URL] > > *Note:*URLs can be used in numerous different manners, in many > differing contexts. For the purpose of producing strict URLs one may > wish to consider[RFC3986] > [RFC3987] > . The W3C > URL specification defines the term URL, various algorithms for > dealing with URLs, and an API for constructing, parsing, and > resolving URLs. Developers of Web browsers are advised to keep > abreast of the latest URL developments by tracking the progress > ofhttps://url.spec.whatwg.org/. We expect that the W3C URL draft > will evolve along the Recommendation track as the community > converges on a definition of URL processing. > > Most of the URL-related terms used in the HTML specification > (*URL*,*absolute URL > *,*relative > URL > *,*relative > schemes*,*scheme component*,*scheme > data*,*username*,*password*,*host*,*port*,*path*,*query*,*fragment*,*percent > encode > *,*get the > base*, and*UTF-8 percent encode > *) > can be straightforwardly mapped to the terminology of[RFC3986] > [RFC3987] > . > The|URLUtils > |(formerly > known as|URL|) collection of attributes (e.g.|href|and|protocol|) > and its required definitions (*input > *,*query > encoding*,*url*,*update steps*,*set the input*) are considered > common practice nowadays. Some of the URL-related terms are still > being refined (e.g.*URL parser > *,*parse errors*,*URL > serializer*,*default encode set > *, and*percent > decode > *). > > As a word of caution, there are notable differences in the manner in > which Web browsers and other software stacks outside the HTML > context handle URLs. While no changes would be accepted to URL > processing that would break existing Web content, some important > parts of URL processing should therefore be considered as > implementation-defined (e.g. parsing file: URLs or operating on URLs > that would be syntax errors under the[RFC3986] > [RFC3987] > syntax). > > URL (URL:http://www.w3.org/TR/url/), E. > Arvidsson, M.[tm] Smith. W3C. I'm indeed aware of much of that text as I contributed to it. I'm also actively working to make that text unnecessary. Since that has been published, I've personally updated two of the documents mentioned in that prose: https://url.spec.whatwg.org/ and http://www.w3.org/TR/url/. I've also gathered a fair amount of data looking into interop issues: https://url.spec.whatwg.org/interop/test-results/ More background can be found here: https://github.com/webspecs/url#the-url-standard - Sam Ruby From nobody Sat Jan 10 15:14:36 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987401A03A3 for ; Sat, 10 Jan 2015 15:14:33 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CN3YzJglMipr for ; Sat, 10 Jan 2015 15:14:30 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 B4C121A0076 for ; Sat, 10 Jan 2015 15:14:30 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 70D5C22E260; Sat, 10 Jan 2015 18:14:29 -0500 (EST) Message-ID: <54B1B211.3050807@seantek.com> Date: Sat, 10 Jan 2015 15:13:21 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> In-Reply-To: <54B19435.8070401@intertwingly.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2015 23:14:33 -0000 On 1/10/2015 1:05 PM, Sam Ruby wrote: > > Permit me to introduce myself. I'm one of the co-chairs of the W3C=20 > HTML Working group. I am indeed aware of this work. Pleased to meet you! [various other text] I believe that the relevant prompting text is: --- I'm working on a specification how strings that can found in the href attribute of HTML elements like , , and . Some of those strings may start with "file:". I think it would be a good idea for us to explore whether there is a relationship between those strings and RFC 3986. I'll go further and state that it is in nobody's best interest for there to be overlapping and conflicting standards in this area. --- Let us agree that RFC 3986 =3D=3D=3D "URI". A URI is supposed to be made = up of=20 characters *entirely within* the repertoire I previously posted (taken=20 from RFC 3986). The issue at hand is that a lot of software uses Unicode, and in=20 particular, there are protocol slots and data entry fields that are=20 labeled "URI" or "URL" in some fashion, but do not limit themselves to=20 the RFC 3986 repertoire. I.e., in etc. you can have Unicode= =20 characters, so the question is, what should you do with them? That is a very interesting question and one that I do not particularly=20 care to wade into. So, I guess I am sidestepping the prompt. :) But the subject of this thread is about registering the file: URI scheme = under the current rules in force, which are RFC 3986 and RFC 4395. (And, = I suppose, RFC 3987.) So it seems to me that the first and "most important" part of=20 draft-kerwin-file-scheme should clearly state how file: URIs work,=20 according to the character repertoire permitted by RFC 3986. Then if the author wants to get into the other issues, i.e., dealing=20 with the presence of non-URI characters (including Unicode characters=20 that keep the string following IRI), that can be done in a subsequent=20 section. (Which can be a "normative" section of the main text, if we can = get agreement on all of that.) Note that RFC 4395 says: 2.6 . Internationalization and Character Encoding When describing URI schemes in which (some of) the elements of the URI are actually representations of human-readable text, care should be taken not to introduce unnecessary variety in the ways in which characters are encoded into octets and then into URI characters; see RFC 3987 [6 ] andSection 2.5 of RFC 3986 [5 ] for guidelines. If URIs of a scheme contain any text fields, the scheme definition MUST describe the ways in which characters are encoded, and any compatibility issues with IRIs of the scheme. ****** The text says not to introduce "unnecessary variety", but in the file:=20 case, maybe some variety is natural and therefore necessary. Sean From nobody Sat Jan 10 15:29:06 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BE41A1A09 for ; Sat, 10 Jan 2015 15:29:04 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVG0RYse530z for ; Sat, 10 Jan 2015 15:29:02 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 4AEA71A0076 for ; Sat, 10 Jan 2015 15:29:02 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2960122E200; Sat, 10 Jan 2015 18:29:01 -0500 (EST) Message-ID: <54B1B578.2090607@seantek.com> Date: Sat, 10 Jan 2015 15:27:52 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> In-Reply-To: <54B17BBE.4000900@intertwingly.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2015 23:29:04 -0000 On 1/10/2015 11:21 AM, Sam Ruby wrote: > On 1/10/15 1:15 PM, Sean Leonard wrote: >> [SNIPS] >>> >>> I part company with you here. IDNA processing can be avoided -=20 >>> don't do >>> it! >>> >>> Many of the IETF standards have no i18n in general, or IDNA in >>> particular, [SNIP] >> Folks are confusing the "web browser text box at the top" with URIs. W= eb >> browsers can display and accept whatever characters they want in the >> address box. How they do that is not an RFC 3986 issue. It might be >> governed by some de-jure or de-facto Web "standards" (or RFC 3987?), b= ut >> it's not directly relevant to URIs. The end. >> >> Nowadays it's not even a "URL bar" or "address bar". It's variously >> called an "omnibox" and has a lot of code running behind it to do >> context-sensitive things with lots of additional user experience >> widgets. For example if you type "? ietf" in Chrome (and others...I >> believe Internet Explorer 6 had this) it's going to do something that >> has nothing to do with URIs. > > I call strawman. Nobody here mentioned a quote "web browser text box=20 > at the top" end-quote. It's not really a strawman: there are different experiences at play. I=20 do a lot of security work; in certificates, a URI (GeneralName ->=20 uniformResourceIdentifier) is stored in an IA5String data type, which is = US-ASCII only. Therefore unlike a blob of HTML, arbitrary Unicode=20 characters cannot possibly be present. The example=20 provided literally cannot= exist in=20 that format; it would be treated as a decoding error. Under the (obsolete...but still widely used) HTML 4.01, it says is supposed to have only %URI characters, so the presence of=20 non-URI characters is either an error (if the DTD is strictly enforced), = or results in undefined/implementation-defined behavior (which is what=20 actually happens, since the DTD almost never gets strictly enforced...by = web browsers). I suppose that the newer standards are intended to clean=20 that up... Sean From nobody Sat Jan 10 15:31:43 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BBF1A0277 for ; Sat, 10 Jan 2015 15:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfrbrpYVtzRN for ; Sat, 10 Jan 2015 15:31:39 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9440D1A0076 for ; Sat, 10 Jan 2015 15:31:39 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id m20so13960604qcx.3 for ; Sat, 10 Jan 2015 15:31:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gJVUUdzqQwNL1+2AP3shxuOYDAlZ+odgvbXd+hDUVLY=; b=aGa8Leqpw9WrihGmnopCwm8qZUdxMqaBAtD9oAwQn0ZK9Bu4ozWJjbwv0BamPSO62z EUDPpSTcx/mqYWtdqbI57fK45ajcODKGgW/qRBzZ/HShr2+jDIkmSMgxmZj43rNRfNDf pgmLBJTgZGUFmWv1JKVCOI6a5AlIQJJT4TPj2xbYKQiZOJ/vEwU6gedjjNJpNUbjPH8d pR6if1FbYrIKrwWBuuxla10/+KVu9B1Gd/hCMqmRu6+MqO1+vwzVgPYbzeGDMnJ2qRhP EGTpuGFiBSsAzJjyOn+/WJaMhfvoWgToxjoUOqbEC92gjgnYNVJo4osx96YAmzVAjaxJ tZrA== MIME-Version: 1.0 X-Received: by 10.224.128.196 with SMTP id l4mr38885593qas.100.1420932698834; Sat, 10 Jan 2015 15:31:38 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Sat, 10 Jan 2015 15:31:38 -0800 (PST) In-Reply-To: <2e33balagh0scqtgaf87vh48vc8l9jm7g7@hive.bjoern.hoehrmann.de> References: <54922C81.4030908@intertwingly.net> <5494C6AF.4070902@intertwingly.net> <2e33balagh0scqtgaf87vh48vc8l9jm7g7@hive.bjoern.hoehrmann.de> Date: Sun, 11 Jan 2015 09:31:38 +1000 X-Google-Sender-Auth: FIR4UbVFZBOjd3Y14zs4Tn5QvPc Message-ID: From: Matthew Kerwin To: Bjoern Hoehrmann Content-Type: multipart/alternative; boundary=001a11c2c358c38c25050c54ac9c Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-kerwin-file-scheme and hosts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2015 23:31:41 -0000 --001a11c2c358c38c25050c54ac9c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11 January 2015 at 06:40, Bjoern Hoehrmann wrote: > * Matthew Kerwin wrote: > >On 20 December 2014 at 10:45, Sam Ruby wrote: > > >> file://[2001::1]/foo > > > >I thought this already worked with RFC 3986..? See the "IP-literal" > >construct in , which > is > >used in "host". > > With the RFC 3986 grammar it would parse as > > ["URI", [ > ["scheme", [ > ["ALPHA", [], 0, 1], > ["ALPHA", [], 1, 2], > ["ALPHA", [], 2, 3], > ["ALPHA", [], 3, 4]], 0, 4], > ["hier-part", [ > ["authority", [ > ["host", [ > ["IP-literal", [ > ["IPv6address", [ > ["h16", [ > ... > ["h16", [ > ... > ["path-abempty", [ > ["segment", [ > ["pchar", [ > ... > Doesn't it match the pattern `[ *5( h16 ":" ) h16 ] "::" h16`? I.e. zero of the (h16 ":") part, then h16=3D"2001", "::", h16=3D"1" =E2=80=8BIs that what you're saying? If so, is that somehow wrong?=E2=80=8B --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11c2c358c38c25050c54ac9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 11 January 2015 at 06:40, Bjoern Hoehrmann <derhoermi@= gmx.net> wrote:
* Matthe= w Kerwin wrote:
>On 20 December 2014 at 10:45, Sam Ruby <rubys@intertwingly.net> wrote:

>> file://[2001::1]/foo
>
>I thought this already worked with RFC 3986..? See the "IP-literal= "
>construct in <https://tools.ietf.org/html/rfc3986#section-3.2.2= >, which is
>used in "host".

With the RFC 3986 grammar it would parse as

=C2=A0 ["URI", [
=C2=A0 =C2=A0 ["scheme", [
=C2=A0 =C2=A0 =C2=A0 ["ALPHA", [], 0, 1],
=C2=A0 =C2=A0 =C2=A0 ["ALPHA", [], 1, 2],
=C2=A0 =C2=A0 =C2=A0 ["ALPHA", [], 2, 3],
=C2=A0 =C2=A0 =C2=A0 ["ALPHA", [], 3, 4]], 0, 4],
=C2=A0 =C2=A0 ["hier-part", [
=C2=A0 =C2=A0 =C2=A0 ["authority", [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ["host", [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ["IP-literal", [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ["IPv6address", [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ["h16", [
=C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ["h16", [
=C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 ["path-abempty", [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ["segment", [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ["pchar", [
=C2=A0 ...

Doesn't it match the pattern `[ *5( h16 ":" ) h16 ] &quo= t;::" h16`? I.e. zero of the (h16 ":") p= art, then h16=3D"2001", "::", h16=3D"1"
=

=E2=80=8BIs that what you'= ;re saying? If so, is that somehow wrong?=E2=80=8B

<= div>
--
=C2=A0= Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a11c2c358c38c25050c54ac9c-- From nobody Sat Jan 10 15:32:26 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B431A0231 for ; Sat, 10 Jan 2015 15:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krVR9piagVw8 for ; Sat, 10 Jan 2015 15:32:21 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.226]) by ietfa.amsl.com (Postfix) with ESMTP id 141181A0076 for ; Sat, 10 Jan 2015 15:32:21 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:59312] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id DD/A6-03035-486B1B45; Sat, 10 Jan 2015 23:32:20 +0000 Received: from [192.168.1.115] (unknown [192.168.1.115]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 62943140A15; Sat, 10 Jan 2015 18:32:20 -0500 (EST) Message-ID: <54B1B682.3070609@intertwingly.net> Date: Sat, 10 Jan 2015 18:32:18 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sean Leonard , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> In-Reply-To: <54B1B211.3050807@seantek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2015 23:32:23 -0000 On 01/10/2015 06:13 PM, Sean Leonard wrote: > On 1/10/2015 1:05 PM, Sam Ruby wrote: >> >> Permit me to introduce myself. I'm one of the co-chairs of the W3C >> HTML Working group. I am indeed aware of this work. > > Pleased to meet you! Likewise! > [various other text] > > I believe that the relevant prompting text is: > --- > I'm working on a specification how strings that can found in the href > attribute of HTML elements like , , and . Some of > those strings may start with "file:". > > I think it would be a good idea for us to explore whether there is a > relationship between those strings and RFC 3986. I'll go further and > state that it is in nobody's best interest for there to be overlapping > and conflicting standards in this area. > --- > > Let us agree that RFC 3986 === "URI". A URI is supposed to be made up of > characters *entirely within* the repertoire I previously posted (taken > from RFC 3986). Let's not. I believe that there needs to be a RFC 3986bis created, and therefore a Working Group chartered. As a concrete example, I believe that the repertoire of characters available for fragment identifiers should be expanded. And related to the original discussion, domains containing Unicode characters do now exist, and IDNA specifies the mapping of those characters to the set of characters that RFC 3986 allows. RFC 3986 needs to be updated to cover this. > The issue at hand is that a lot of software uses Unicode, and in > particular, there are protocol slots and data entry fields that are > labeled "URI" or "URL" in some fashion, but do not limit themselves to > the RFC 3986 repertoire. I.e., in etc. you can have Unicode > characters, so the question is, what should you do with them? > > That is a very interesting question and one that I do not particularly > care to wade into. So, I guess I am sidestepping the prompt. :) > > But the subject of this thread is about registering the file: URI scheme > under the current rules in force, which are RFC 3986 and RFC 4395. (And, > I suppose, RFC 3987.) > > So it seems to me that the first and "most important" part of > draft-kerwin-file-scheme should clearly state how file: URIs work, > according to the character repertoire permitted by RFC 3986. This very question changes when the possibility of a RFC 3986bis enters the discussion. > Then if the author wants to get into the other issues, i.e., dealing > with the presence of non-URI characters (including Unicode characters > that keep the string following IRI), that can be done in a subsequent > section. (Which can be a "normative" section of the main text, if we can > get agreement on all of that.) > > Note that RFC 4395 says: > > 2.6 . > Internationalization and Character Encoding > > When describing URI schemes in which (some of) the elements of the > URI are actually representations of human-readable text, care should > be taken not to introduce unnecessary variety in the ways in which > characters are encoded into octets and then into URI characters; see > RFC 3987 [6 > ] andSection 2.5 of RFC 3986 > [5 > ] for guidelines. If URIs > of a scheme contain any text fields, the scheme definition MUST > describe the ways in which characters are encoded, and any > compatibility issues with IRIs of the scheme. > > ****** > > The text says not to introduce "unnecessary variety", but in the file: > case, maybe some variety is natural and therefore necessary. I actually would argue that the advice RFC 4395 provides be followed. And that's precisely why IDNA is relevant here. > Sean - Sam Ruby From nobody Sat Jan 10 15:38:47 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B5B1A1A5E for ; Sat, 10 Jan 2015 15:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fDoVYLP0cKe for ; Sat, 10 Jan 2015 15:38:44 -0800 (PST) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1131A1A72 for ; Sat, 10 Jan 2015 15:38:40 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id w8so3813843qac.3 for ; Sat, 10 Jan 2015 15:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=EomcV1nG0JRcyalBDPuemwzWDRD2ZZyhnwKkZ0pHXv0=; b=UB2euLMvJ4V5vgQUEHHY625GMCPiBaVpi0I1iQB8w1BYComS7FkAcy+B887oSOmwyP x0BiPaAKrS3IXuc0jxkLcnANCT10QaS5WemNu9JMM5ea9dQpV3OttfGfVbW/F0xXYFaA bv5gqSgA+WY8mOy0DjJa5ZHjVk9P457WvtpGGb2j9HpR0GY3KL9IhM5o8eJfr2wM+yQD wy9RM1LFAmWwbK0Tl2nEoWbBPviIRiXzd2Ew5GjFs53S61lVJ46VOoyOs005DRmKvx0D rqyfSns9SCIreoxKf54bNiTrqbs5B+p8aNYgXwtdSVAMyMw16EC6RrmHjlK5kSuaDRhn dx/g== MIME-Version: 1.0 X-Received: by 10.229.130.65 with SMTP id r1mr38724428qcs.16.1420933119540; Sat, 10 Jan 2015 15:38:39 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Sat, 10 Jan 2015 15:38:39 -0800 (PST) In-Reply-To: <54B19221.2080203@intertwingly.net> References: <54922C81.4030908@intertwingly.net> <5494C6AF.4070902@intertwingly.net> <2e33balagh0scqtgaf87vh48vc8l9jm7g7@hive.bjoern.hoehrmann.de> <54B19221.2080203@intertwingly.net> Date: Sun, 11 Jan 2015 09:38:39 +1000 X-Google-Sender-Auth: 4x0TKXVa3ATWw_ItZTJRe6p2moc Message-ID: From: Matthew Kerwin To: Sam Ruby Content-Type: multipart/alternative; boundary=001a1133d79ad705ef050c54c5cc Archived-At: Cc: Bjoern Hoehrmann , IETF Apps Discuss Subject: Re: [apps-discuss] draft-kerwin-file-scheme and hosts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2015 23:38:46 -0000 --001a1133d79ad705ef050c54c5cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11 January 2015 at 06:57, Sam Ruby wrote: > [never saw Matthew's reply. still can't find it. weird] > > On 01/10/2015 03:40 PM, Bjoern Hoehrmann wrote: > >> * Matthew Kerwin wrote: >> >>> On 20 December 2014 at 10:45, Sam Ruby wrote: >>> >> >> file://[2001::1]/foo >>>> >>> >>> I thought this already worked with RFC 3986..? See the "IP-literal" >>> construct in , which >>> is >>> used in "host". >>> >> > My point was that it works with RFC 3986, but doesn't work with > draft-kerwin-file-scheme. I encourage you to look at section 2.2 of RFC > 4291. > =E2=80=8B > =E2=80=8B > =E2=80=8B > > > How does it not work? Consider that I may not be an IPv6 guru, and possibly [2001::1] means something to you that it doesn't to me. > > =E2=80=8B=E2=80=8B > There is a very simple fix for this. I believe that what you want to > refer to instead is section 2 of RFC 6874. > > It says "...and importing the "userinfo", "host", "path-absolute", and "query" rules from [RFC3986] (as updated by [RFC6874].)" --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a1133d79ad705ef050c54c5cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 11 January 2015 at 06:57, Sam Ruby <rubys@intertwingly.net= > wrote:
[never saw Matthew's reply.=C2=A0 still can= 9;t find it.=C2=A0 weird]

On 01/10/2015 03:40 PM, Bjoern Hoehrmann wrote:
* Matthew Kerwin wrote:
On 20 December 2014 at 10:45, Sam Ruby <rubys@intertwingly.net> wrote:

file://[2001::1]/foo

I thought this already worked with RFC 3986..? See the "IP-literal&quo= t;
construct in <https://tools.ietf.org/html/rfc3986#section-3.= 2.2>, which is
used in "host".

 My point was that it works with RFC 3986, but doesn't work with draft-k= erwin-file-scheme.=C2=A0 I encourage you to look at section 2.2 of RFC 4291= .
=E2=80=8B
=E2=80=8B<= /div>
=E2=80=8B



<= /div>
How does it not work? Consider that I may not be an IPv6= guru, and possibly [2001::1] means something to you that it doesn't to= me.

=C2=A0

=E2=80=8B=E2=80=8B
There is a very simple fix for this.=C2=A0 I= believe that what you want to refer to instead is section 2 of RFC 6874.


It says "...and importing the "userinfo", "host&quo= t;, "path-absolute", and "query" rules from [RFC3986] (= as updated by [RFC6874].)"



-= -
=C2=A0 Matthew Kerwin=
=C2=A0 http= ://matthew.kerwin.net.au/
--001a1133d79ad705ef050c54c5cc-- From nobody Sat Jan 10 15:52:21 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3C81A01FA for ; Sat, 10 Jan 2015 15:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29w54Ot3ybyP for ; Sat, 10 Jan 2015 15:52:18 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2A42C1A01C6 for ; Sat, 10 Jan 2015 15:52:18 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:63952] helo=rubix) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id D1/95-09074-13BB1B45; Sat, 10 Jan 2015 23:52:17 +0000 Received: from [192.168.1.115] (unknown [192.168.1.115]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 64016140035; Sat, 10 Jan 2015 18:52:17 -0500 (EST) Message-ID: <54B1BB30.5000207@intertwingly.net> Date: Sat, 10 Jan 2015 18:52:16 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin References: <54922C81.4030908@intertwingly.net> <5494C6AF.4070902@intertwingly.net> <2e33balagh0scqtgaf87vh48vc8l9jm7g7@hive.bjoern.hoehrmann.de> <54B19221.2080203@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: Cc: Bjoern Hoehrmann , IETF Apps Discuss Subject: Re: [apps-discuss] draft-kerwin-file-scheme and hosts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2015 23:52:20 -0000 On 01/10/2015 06:38 PM, Matthew Kerwin wrote: > On 11 January 2015 at 06:57, Sam Ruby >wrote: > > [never saw Matthew's reply. still can't find it. weird] > > On 01/10/2015 03:40 PM, Bjoern Hoehrmann wrote: > > * Matthew Kerwin wrote: > > On 20 December 2014 at 10:45, Sam Ruby > > wrote: > > file://[2001::1]/foo > > > I thought this already worked with RFC 3986..? See the > "IP-literal" > construct in > >, which is > used in "host". > > My point was that it works with RFC 3986, but doesn't work with > draft-kerwin-file-scheme. I encourage you to look at section 2.2 of > RFC 4291. > > How does it not work? Consider that I may not be an IPv6 guru, and > possibly [2001::1] means something to you that it doesn't to me. > > There is a very simple fix for this. I believe that what you want > to refer to instead is section 2 of RFC 6874. > > It says "...and importing the "userinfo", "host", "path-absolute", and > "query" rules from [RFC3986] (as updated by [RFC6874].)" That's section 2. My comment relates to Appendix A. Sorry if I wasn't clear before. > -- > Matthew Kerwin > http://matthew.kerwin.net.au/ - Sam Ruby From nobody Sat Jan 10 15:55:49 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742861A01FA for ; Sat, 10 Jan 2015 15:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOIYE9X88ViE for ; Sat, 10 Jan 2015 15:55:45 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 54BE01A0095 for ; Sat, 10 Jan 2015 15:55:45 -0800 (PST) Received: from netb ([89.204.137.193]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LcSWg-1XTZmg1KI2-00jtAD; Sun, 11 Jan 2015 00:55:38 +0100 From: Bjoern Hoehrmann To: Matthew Kerwin Date: Sun, 11 Jan 2015 00:55:34 +0100 Message-ID: <0re3bappapp7ehunfhkjuekieohkob9d59@hive.bjoern.hoehrmann.de> References: <54922C81.4030908@intertwingly.net> <5494C6AF.4070902@intertwingly.net> <2e33balagh0scqtgaf87vh48vc8l9jm7g7@hive.bjoern.hoehrmann.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:RBVPMnUReFotqM/ANLAsC1pTwpAb+oORJTqwVbZHEpEa+lrcKTd sMOAcz5HAtr7CeTksVsHNA8iHa7z2HDwZyXoOZASyjLPq1GY99UPtDOSmxuAFsiGckX+fhw hgrOQeFBsfqRTzgWFRgzEpG5DTQ3pQLH4Z+H3eklFljptqBrkxwWKjvULiiwia3N6sA0H6B 0xFsV/wt8VG//p73E8o6A== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-kerwin-file-scheme and hosts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jan 2015 23:55:47 -0000 * Matthew Kerwin wrote: >On 11 January 2015 at 06:40, Bjoern Hoehrmann wrote: > >> * Matthew Kerwin wrote: >> >On 20 December 2014 at 10:45, Sam Ruby wrote: >> >> >> file://[2001::1]/foo >> > >> >I thought this already worked with RFC 3986..? See the "IP-literal" >> >construct in , which >> is >> >used in "host". >> >> With the RFC 3986 grammar it would parse as >> >> ["URI", [ >> ["scheme", [ >> ["ALPHA", [], 0, 1], >> ["ALPHA", [], 1, 2], >> ["ALPHA", [], 2, 3], >> ["ALPHA", [], 3, 4]], 0, 4], >> ["hier-part", [ >> ["authority", [ >> ["host", [ >> ["IP-literal", [ >> ["IPv6address", [ >> ["h16", [ >> ... >> ["h16", [ >> ... >> ["path-abempty", [ >> ["segment", [ >> ["pchar", [ >> ... >> > >Doesn't it match the pattern `[ *5( h16 ":" ) h16 ] "::" h16`? I.e. zero of >the (h16 ":") part, then h16="2001", "::", h16="1" > >?Is that what you're saying? If so, is that somehow wrong?? Yes, that is how it matches, and no, that is not wrong. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de D-10243 Berlin PGP Pub. KeyID: 0xA4357E78 http://www.bjoernsworld.de Available for hire in Berlin (early 2015) http://www.websitedev.de/ From nobody Sat Jan 10 16:05:56 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F631A1A5E for ; Sat, 10 Jan 2015 16:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRNclCw5nXjc for ; Sat, 10 Jan 2015 16:05:50 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98631A1A50 for ; Sat, 10 Jan 2015 16:05:49 -0800 (PST) Received: by mail-qg0-f44.google.com with SMTP id q107so13716109qgd.3 for ; Sat, 10 Jan 2015 16:05:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6eMw+sxMSzax4X2dCKUnB1Mvds73IFwYM9gYIbGMA7Q=; b=IZB+AG56y/zgmPVVhO+i2T/K1ZNB1t50EAnKGQD8zlPuze7/TgL6CqrSJUx1Lc11KC 1vor9L/n4sFWrQYCOTI/71rOzcWfske1tUEBMA0fTEIkhd4EDgv0PX3TgXayKNEeSVoN wlcTa3a+JU1E/mnZNy6gAkM8Ka89GTiwzxa9X1A4aS0G5jggxx8t9WTwrcJ2K9TXK9Mg p9WXX1saPRivq9GC5AIKtIOVJg71iuuPF0MZfhn32X9cVlKGsN7BL0q9Rh9QGWQdxyCo 4pVmr5WGlM60wv5Ld+Lk9wh412VOiBtnod9IC19XVWHAZXNiO9ColQWvVWKLK0SUEBaU SH6A== MIME-Version: 1.0 X-Received: by 10.229.130.65 with SMTP id r1mr38826721qcs.16.1420934737081; Sat, 10 Jan 2015 16:05:37 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Sat, 10 Jan 2015 16:05:36 -0800 (PST) In-Reply-To: <54B1B682.3070609@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> Date: Sun, 11 Jan 2015 10:05:36 +1000 X-Google-Sender-Auth: RUMKyYddfFlFz_pEj0eT4blg-YM Message-ID: From: Matthew Kerwin To: Sam Ruby Content-Type: multipart/alternative; boundary=001a1133d79a40bda6050c55260a Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 00:05:54 -0000 --001a1133d79a40bda6050c55260a Content-Type: text/plain; charset=UTF-8 On 11 January 2015 at 09:32, Sam Ruby wrote: > On 01/10/2015 06:13 PM, Sean Leonard wrote: > >> >> Let us agree that RFC 3986 === "URI". A URI is supposed to be made up of >> characters *entirely within* the repertoire I previously posted (taken >> from RFC 3986). >> > > Let's not. I believe that there needs to be a RFC 3986bis created, and > therefore a Working Group chartered. > > So, if and when such a group is chartered, and if it's subsequently determined that work produced by that group should pause all ongoing work with specifying URI schemes, and if a new 'file' spec isn't already published before that, then of course we'd roadblock a new 'file' draft/spec. But we're not there yet. I've no intention to rewrite 3986, nor do I want to publish a draft that counters it. Least of all 'file', which has such a history of going against the grain -- the whole point of doing this is to pull it back into the flock. -- Matthew Kerwin http://matthew.kerwin.net.au/ --001a1133d79a40bda6050c55260a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 11 January 2015 at 09:32, Sam Ruby <rubys@intertwingly.net&g= t; = wrote:
On 01/10/2015 06:13 PM, S= ean Leonard wrote:

 Let us agree that RFC 3986 =3D=3D=3D "URI". A URI is supposed to = be made up of
characters *entirely within* the repertoire I previously posted (taken
from RFC 3986).

Let's not.=C2=A0 I believe that there needs to be a RFC 3986bis created= , and therefore a Working Group chartered.


So, if= and when such a group is chartered, and if it's subsequently determine= d that work produced by that group should pause all ongoing work with speci= fying URI schemes, and if a new 'file' spec isn't already publi= shed before that, then of course we'd roadblock a new 'file' dr= aft/spec.

But we're not there yet. I&#= 39;ve no intention to rewrite 3986, nor do I want to publish a draft that c= ounters it. Least of all 'file', which has such a history of going = against the grain -- the whole point of doing this is to pull it back into = the flock.

--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a1133d79a40bda6050c55260a-- From nobody Sat Jan 10 16:10:59 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8381A00AE for ; Sat, 10 Jan 2015 16:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NN13j4gjWLBS for ; Sat, 10 Jan 2015 16:10:54 -0800 (PST) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F891A005C for ; Sat, 10 Jan 2015 16:10:53 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id f12so11535046qad.4 for ; Sat, 10 Jan 2015 16:10:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=bWWc6kGf8S3u8ShrFTYoJV/F8aMq/DgpQoUTPJ5irgo=; b=yaPX1V5zBUctNJryPKYYesk1abKUqzTxYGSrepsPqj7C8GPztZIpSYRrWsAw/sWPTh 37iGKGZ+j7DBVqvu6WThYRswnikTFVo6HeY621+OjOc8hPcQ0CbYUaCbizzMZiZzSiCL nNixr9wnpGPMl2O2BMd+RKhkMU/ywTiMj+4d7gCUiU2o8cbM8FxpUE8aEJ3T15rWLgEo 0QE0xkM8XnnWQHzyXWdvJEMy5a7z5wJVYMbT6g/D26y51IGcHgUZu1XnuDyITWmklVkv 3j8K3tCXrmidFa+JOe+zDlwjfr6hMUoZ1WNHs/G8f1z/120fZlJyRTcFJEUOUz3S7yoj 0U9g== MIME-Version: 1.0 X-Received: by 10.224.88.129 with SMTP id a1mr16627137qam.92.1420935053149; Sat, 10 Jan 2015 16:10:53 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Sat, 10 Jan 2015 16:10:53 -0800 (PST) In-Reply-To: <54B1BB30.5000207@intertwingly.net> References: <54922C81.4030908@intertwingly.net> <5494C6AF.4070902@intertwingly.net> <2e33balagh0scqtgaf87vh48vc8l9jm7g7@hive.bjoern.hoehrmann.de> <54B19221.2080203@intertwingly.net> <54B1BB30.5000207@intertwingly.net> Date: Sun, 11 Jan 2015 10:10:53 +1000 X-Google-Sender-Auth: ABcD__7lP_IGt7Pp6jjEvoumvB0 Message-ID: From: Matthew Kerwin To: Sam Ruby Content-Type: multipart/alternative; boundary=001a11c2c31e178d60050c5539eb Archived-At: Cc: Bjoern Hoehrmann , IETF Apps Discuss Subject: Re: [apps-discuss] draft-kerwin-file-scheme and hosts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 00:10:57 -0000 --001a11c2c31e178d60050c5539eb Content-Type: text/plain; charset=UTF-8 On 11 January 2015 at 09:52, Sam Ruby wrote: > On 01/10/2015 06:38 PM, Matthew Kerwin wrote: > >> >> It says "...and importing the "userinfo", "host", "path-absolute", and >> "query" rules from [RFC3986] (as updated by [RFC6874].)" >> > > That's section 2. My comment relates to Appendix A. Sorry if I wasn't > clear before. > > Oh, I see. Well, Appendix A isn't my text, it's a copy-paste from the reference The easier fix is to drop the appendix altogether. That said, [2001::1] still matches the MS UNC syntax. RFC 6874 adds some percent stuff for zones, but that doesn't seem relevant to any example you've provided here. -- Matthew Kerwin http://matthew.kerwin.net.au/ --001a11c2c31e178d60050c5539eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 11 January 2015 at 09:52, Sam Ruby <rubys@intertwingly.net= > wrote:
On 01/10/2015 06:38 PM, Matthew K= erwin wrote:

It says "...and importing the "userinfo", "host", = "path-absolute", and
"query" rules from [RFC3986] (as updated by [RFC6874].)"

That's section 2.=C2=A0 My comment relates to Appendix A.=C2=A0 Sorry i= f I wasn't clear before.


Oh, I s= ee. Well, Appendix A isn't my text, it's a copy-paste from the refe= rence <http://msdn.microsoft.com/en-us/library/gg465305.aspx>

The easier fix is to drop the appendix altogether.

That said, [2001::1] still matches the MS UNC= syntax. RFC 6874 adds some percent stuff for zones, but that doesn't s= eem relevant to any example you've provided here.


--
=C2= =A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a11c2c31e178d60050c5539eb-- From nobody Sat Jan 10 16:11:28 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318811A1A22 for ; Sat, 10 Jan 2015 16:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qieoY7c4YSCV for ; Sat, 10 Jan 2015 16:11:13 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 89BC41A0231 for ; Sat, 10 Jan 2015 16:11:13 -0800 (PST) Received: from netb ([89.204.137.193]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LcBPV-1XSkQT0hnR-00jcBd; Sun, 11 Jan 2015 01:11:02 +0100 From: Bjoern Hoehrmann To: Sam Ruby Date: Sun, 11 Jan 2015 01:10:58 +0100 Message-ID: References: <54922C81.4030908@intertwingly.net> <5494C6AF.4070902@intertwingly.net> <2e33balagh0scqtgaf87vh48vc8l9jm7g7@hive.bjoern.hoehrmann.de> <54B19221.2080203@intertwingly.net> In-Reply-To: <54B19221.2080203@intertwingly.net> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:eu87zywoFPm1YADBKcJyFhdv+vEXm6nvQ1BgJpcLZvRLixWFD/x eczYqE4nYjAYvWTJUxMsbLk6GlYV0YPaqYVzZVHcRy2s9EGosSR8Fff3sHp1XKNaMIm45lf gdCLXPvHJ/zp7AATvopl6xXPlIbsDSQ21FVJniKT9S05qs5xMpcF7X6Tv2ppDbxx4ooeT/k t8+/IaXg2lNIWa79Ecy7Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-kerwin-file-scheme and hosts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 00:11:19 -0000 * Sam Ruby wrote: >On 01/10/2015 03:40 PM, Bjoern Hoehrmann wrote: >> * Matthew Kerwin wrote: >>> On 20 December 2014 at 10:45, Sam Ruby wrote: >> >>>> file://[2001::1]/foo >>> >>> I thought this already worked with RFC 3986..? See the "IP-literal" >>> construct in , which is >>> used in "host". > >My point was that it works with RFC 3986, but doesn't work with >draft-kerwin-file-scheme. I encourage you to look at section 2.2 of RFC >4291. > >There is a very simple fix for this. I believe that what you want to >refer to instead is section 2 of RFC 6874. Per https://tools.ietf.org/html/draft-kerwin-file-scheme-13 the string parses as ["file-URI", [ ["f-scheme", [], 0, 4], ["f-hier-part", [ ["auth-path", [ ["f-auth", [ ["host", [ ["IP-literal", [ ["IPv6address", [ ["h16", [ ["HEXDIG", [ ["DIGIT", [], 8, 9]], 8, 9], ["HEXDIG", [ ["DIGIT", [], 9, 10]], 9, 10], ["HEXDIG", [ ["DIGIT", [], 10, 11]], 10, 11], ["HEXDIG", [ ["DIGIT", [], 11, 12]], 11, 12]], 8, 12], ["h16", [ ["HEXDIG", [ ["DIGIT", [], 14, 15]], 14, 15]], 14, 15]], 8, 15]], 7, 16]], 7, 16]], 7, 16], ["path-absolute", [ ["segment-nz", [ ["pchar", [ ["unreserved", [ ["ALPHA", [], 17, 18]], 17, 18]], 17, 18], ["pchar", [ ["unreserved", [ ["ALPHA", [], 18, 19]], 18, 19]], 18, 19], ["pchar", [ ["unreserved", [ ["ALPHA", [], 19, 20]], 19, 20]], 19, 20]], 17, 20]], 16, 20]], 7, 20]], 5, 20]], 0, 20] where `host` comes from RFC 3986. I do not see anything in the draft calling for a different interpretation of `IPv6address` than what RFC 3986 calls for, so I am not sure what does not work here. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de D-10243 Berlin PGP Pub. KeyID: 0xA4357E78 http://www.bjoernsworld.de Available for hire in Berlin (early 2015) http://www.websitedev.de/ From nobody Sat Jan 10 18:24:36 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2841A0A85 for ; Sat, 10 Jan 2015 18:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5D1rcG5umuBE for ; Sat, 10 Jan 2015 18:24:32 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 C58321A01E1 for ; Sat, 10 Jan 2015 18:24:31 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D11A322E261; Sat, 10 Jan 2015 21:24:29 -0500 (EST) Message-ID: <54B1DE99.9060002@seantek.com> Date: Sat, 10 Jan 2015 18:23:21 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin , Sam Ruby References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080904010108070402000308" Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 02:24:33 -0000 This is a multi-part message in MIME format. --------------080904010108070402000308 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 1/10/2015 4:05 PM, Matthew Kerwin wrote: > On 11 January 2015 at 09:32, Sam Ruby >wrote: > > On 01/10/2015 06:13 PM, Sean Leonard wrote: > > > Let us agree that RFC 3986 === "URI". A URI is supposed to be > made up of > characters *entirely within* the repertoire I previously > posted (taken > from RFC 3986). > > > Let's not. I believe that there needs to be a RFC 3986bis > created, and therefore a Working Group chartered. > > > So, if and when such a group is chartered, and if it's subsequently > determined that work produced by that group should pause all ongoing > work with specifying URI schemes, and if a new 'file' spec isn't > already published before that, then of course we'd roadblock a new > 'file' draft/spec. > > But we're not there yet. I've no intention to rewrite 3986, nor do I > want to publish a draft that counters it. Least of all 'file', which > has such a history of going against the grain -- the whole point of > doing this is to pull it back into the flock. +1...my sentiments exactly...keep the train moving on the existing rails. Sean --------------080904010108070402000308 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 1/10/2015 4:05 PM, Matthew Kerwin wrote:
On 11 January 2015 at 09:32, Sam Ruby <rubys@intertwingly.net> wrote:
On 01/10/2015 06:13 PM, Sean Leonard wrote:
Let us agree that RFC 3986 === "URI". A URI is supposed to be made up of
characters *entirely within* the repertoire I previously posted (taken
from RFC 3986).

 Let's not.  I believe that there needs to be a RFC 3986bis created, and therefore a Working Group chartered.


So, if and when such a group is chartered, and if it's subsequently determined that work produced by that group should pause all ongoing work with specifying URI schemes, and if a new 'file' spec isn't already published before that, then of course we'd roadblock a new 'file' draft/spec.

But we're not there yet. I've no intention to rewrite 3986, nor do I want to publish a draft that counters it. Least of all 'file', which has such a history of going against the grain -- the whole point of doing this is to pull it back into the flock.

+1...my sentiments exactly...keep the train moving on the existing rails.

Sean
--------------080904010108070402000308-- From nobody Sun Jan 11 03:27:49 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590181A1B7D for ; Sun, 11 Jan 2015 03:27:47 -0800 (PST) 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, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mS-AzcPnmzC for ; Sun, 11 Jan 2015 03:27:44 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 300061A1B5D for ; Sun, 11 Jan 2015 03:27:43 -0800 (PST) Received: from pc6 (81.151.167.59) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.53.17; Sun, 11 Jan 2015 11:27:20 +0000 Message-ID: <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> From: t.petch To: Sam Ruby , Sean Leonard , References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> Date: Sun, 11 Jan 2015 11:22:02 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB4PR01CA0032.eurprd01.prod.exchangelabs.com (10.242.152.22) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DB3PR07MB060; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DB3PR07MB060; X-Forefront-PRVS: 045315E1EE X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(2473001)(51704005)(24454002)(189002)(479174004)(13464003)(92566002)(230783001)(116806002)(42186005)(62236002)(44716002)(50226001)(19580405001)(87976001)(77156002)(14496001)(46102003)(84392001)(19580395003)(33646002)(101416001)(93886004)(44736004)(61296003)(107886001)(122386002)(62966003)(106356001)(105586002)(40100003)(81816999)(77096005)(81686999)(50986999)(76176999)(23756003)(68736005)(50466002)(66066001)(97736003)(47776003)(64706001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2015 11:27:20.8359 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060 Archived-At: Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 11:27:47 -0000 ----- Original Message ----- From: "Sam Ruby" To: "Sean Leonard" ; Sent: Saturday, January 10, 2015 11:32 PM > On 01/10/2015 06:13 PM, Sean Leonard wrote: > > On 1/10/2015 1:05 PM, Sam Ruby wrote: > >> > >> Permit me to introduce myself. I'm one of the co-chairs of the W3C > >> HTML Working group. I am indeed aware of this work. > > > > Pleased to meet you! > > Likewise! > > > [various other text] > > > > I believe that the relevant prompting text is: > > --- > > I'm working on a specification how strings that can found in the href > > attribute of HTML elements like , , and . Some of > > those strings may start with "file:". > > > > I think it would be a good idea for us to explore whether there is a > > relationship between those strings and RFC 3986. I'll go further and > > state that it is in nobody's best interest for there to be overlapping > > and conflicting standards in this area. > > --- > > > > Let us agree that RFC 3986 === "URI". A URI is supposed to be made up of > > characters *entirely within* the repertoire I previously posted (taken > > from RFC 3986). > > Let's not. I believe that there needs to be a RFC 3986bis created, and > therefore a Working Group chartered. > > As a concrete example, I believe that the repertoire of characters > available for fragment identifiers should be expanded. > > And related to the original discussion, domains containing Unicode > characters do now exist, and IDNA specifies the mapping of those > characters to the set of characters that RFC 3986 allows. RFC 3986 > needs to be updated to cover this. An interesting idea. I have seen masses of Working Groups chartered while I have been contributing to the IETF and for all, I do not know where the first impetus comes from. Certainly it is up to the IESG to approve, approve the charter and so on, and most start with two IESG-approved BoFs at IETF meetings and these BoFs seem to come from WG Chairs or authors whose work I know well. The IETF website lists current BoFs. There is a deadline for requesting BoFs prior to any meeting such as IETF92 but I am not sure when that is. If you want it to happen, that is what needs to happen. I get the impression that the worst outcome is forming a WG which then decays, produces nothing, costs a lot, so the IESG looks for an awful lot of enthusiasm to start with, knowing that most of it will be gone within the year. Tom Petch From nobody Sun Jan 11 05:01:54 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786D01A1BEE for ; Sun, 11 Jan 2015 05:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fN9suLzYNtYG for ; Sun, 11 Jan 2015 05:01:47 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.228]) by ietfa.amsl.com (Postfix) with ESMTP id 9364F1A1BD7 for ; Sun, 11 Jan 2015 05:01:47 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:16812] helo=rubix) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 78/6E-30379-A3472B45; Sun, 11 Jan 2015 13:01:47 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 2EF16140035 for ; Sun, 11 Jan 2015 08:01:47 -0500 (EST) Message-ID: <54B2743A.7030905@intertwingly.net> Date: Sun, 11 Jan 2015 08:01:46 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: apps-discuss@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: Subject: [apps-discuss] Updated draft-ruby-url-problem-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 13:01:52 -0000 See http://www.ietf.org/id/draft-ruby-url-problem-01.txt There have been too many updates to enumerate. Biggest changes were in the next steps section; which instead of proposing a single solution outlines a number of partial solutions. The idea of a joint IETF/W3C WG is mentioned, though at this point I'm skeptical it will work out. - Sam Ruby From nobody Sun Jan 11 05:18:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773FC1A1EF2 for ; Sun, 11 Jan 2015 05:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Odf_mjhZT3pW for ; Sun, 11 Jan 2015 05:18:21 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.231]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6B51A1EEF for ; Sun, 11 Jan 2015 05:18:21 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:18995] helo=rubix) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id C8/6A-30379-C1872B45; Sun, 11 Jan 2015 13:18:21 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id DD652140D09; Sun, 11 Jan 2015 08:18:20 -0500 (EST) Message-ID: <54B2781C.4040505@intertwingly.net> Date: Sun, 11 Jan 2015 08:18:20 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "t.petch" , Sean Leonard , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> In-Reply-To: <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 13:18:23 -0000 On 01/11/2015 06:22 AM, t.petch wrote: > ----- Original Message ----- > From: "Sam Ruby" > To: "Sean Leonard" ; > Sent: Saturday, January 10, 2015 11:32 PM >> On 01/10/2015 06:13 PM, Sean Leonard wrote: >>> On 1/10/2015 1:05 PM, Sam Ruby wrote: >>>> >>>> Permit me to introduce myself. I'm one of the co-chairs of the W3C >>>> HTML Working group. I am indeed aware of this work. >>> >>> Pleased to meet you! >> >> Likewise! >> >>> [various other text] >>> >>> I believe that the relevant prompting text is: >>> --- >>> I'm working on a specification how strings that can found in the > href >>> attribute of HTML elements like , , and . Some of >>> those strings may start with "file:". >>> >>> I think it would be a good idea for us to explore whether there is a >>> relationship between those strings and RFC 3986. I'll go further > and >>> state that it is in nobody's best interest for there to be > overlapping >>> and conflicting standards in this area. >>> --- >>> >>> Let us agree that RFC 3986 === "URI". A URI is supposed to be made > up of >>> characters *entirely within* the repertoire I previously posted > (taken >>> from RFC 3986). >> >> Let's not. I believe that there needs to be a RFC 3986bis created, > and >> therefore a Working Group chartered. >> >> As a concrete example, I believe that the repertoire of characters >> available for fragment identifiers should be expanded. >> >> And related to the original discussion, domains containing Unicode >> characters do now exist, and IDNA specifies the mapping of those >> characters to the set of characters that RFC 3986 allows. RFC 3986 >> needs to be updated to cover this. > > An interesting idea. I have seen masses of Working Groups chartered > while I have been contributing to the IETF and for all, I do not know > where the first impetus comes from. Certainly it is up to the IESG to > approve, approve the charter and so on, and most start with two > IESG-approved BoFs at IETF meetings and these BoFs seem to come from WG > Chairs or authors whose work I know well. The IETF website lists > current BoFs. There is a deadline for requesting BoFs prior to any > meeting such as IETF92 but I am not sure when that is. If you want it > to happen, that is what needs to happen. 2015-02-06 (Friday): Cut-off date for BOF proposal requests to Area Directors at UTC 23:59. http://www.ietf.org/meeting/important-dates-2015.html > I get the impression that the worst outcome is forming a WG which then > decays, produces nothing, costs a lot, so the IESG looks for an awful > lot of enthusiasm to start with, knowing that most of it will be gone > within the year. By spring, I should be able to get browser vendors together in a room and we should be able to review the following results together: https://url.spec.whatwg.org/interop/test-results/ Based on those discussions, the following specs will be updated: https://url.spec.whatwg.org/ http://www.w3.org/TR/url/ I also plan to work with library authors for various popular programming languages with the intent of making their URI/URL libraries more web compatible. This work may take various forms: bug reports, patches, or even new libraries. This work is all being done in the open, and I'm making an attempt to reach out to everybody who may be interested in participating. - Sam Ruby From nobody Sun Jan 11 06:52:14 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531FE1A6F2A for ; Sun, 11 Jan 2015 06:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waovujR40Jyh for ; Sun, 11 Jan 2015 06:52:11 -0800 (PST) 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 8E29F1A6F02 for ; Sun, 11 Jan 2015 06:52:11 -0800 (PST) Received: from [192.168.2.175] ([93.217.100.224]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MVe87-1YHqo53HUF-00Yvjg; Sun, 11 Jan 2015 15:52:06 +0100 Message-ID: <54B28E0F.8070306@gmx.de> Date: Sun, 11 Jan 2015 15:51:59 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , Sean Leonard , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> In-Reply-To: <54B1B682.3070609@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:1xwspETcxvfIjX2S+jn3h0mUdWKIAbvIsDKkCCRcTlMQjnoZ82w EOXgkv3bep9KrtGJZahZ5ziV7xk6eyTDxUqtiBKq7yXrkwOG5gMBLH1PpFneViQmY44Bbpw EH7kiAJESquRJijUceI0uldLy/BNtHFNcpgi9+5cyFoJ4BQDmkWh6Vsx3CJZcQlabnTt/qs E1am7oGrumT3wIlSXlYBg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 14:52:13 -0000 On 2015-01-11 00:32, Sam Ruby wrote: > ... > As a concrete example, I believe that the repertoire of characters > available for fragment identifiers should be expanded. > ... Could you provide a bit more information? Example for a character missing? And the reason to add it? Best regards, Julian From nobody Sun Jan 11 07:06:27 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEDB1A6F2A for ; Sun, 11 Jan 2015 07:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.569 X-Spam-Level: ** X-Spam-Status: No, score=2.569 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DF_72rb0qPZC for ; Sun, 11 Jan 2015 07:06:23 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ECDA1A6F29 for ; Sun, 11 Jan 2015 07:06:22 -0800 (PST) Received: internal info suppressed Date: Sun, 11 Jan 2015 16:06:19 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.local To: apps-discuss@ietf.org Message-ID: User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1420988780; bh=gez2E+ijECmc060RSbw+sYgS9/oycoAU9zz+v/F806o=; h=Date:From:To:Subject; b=jeqC2GUeKVi0d+QpRa0nv9BJYIJTF1hMa0G9o1nj/Dxdv00newiNeruoQ0ym7Bd0J t6nNRASlHK8+++lNMWK3ZcslxCSdhx90pnvbAqAkr/KR/5tCkmAZSI9it/IHan+dJc G0L4Cw87VzoN/pZc9D+zoBkdTzVZ0BJC7eXaf3B0= Archived-At: Subject: [apps-discuss] generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 15:06:26 -0000 Hello all, I've been explicitly asked the question if the correct way to avoind the possible forgery of DSNs described in the Security Consideration sections of RFC3464 is to have the MTA sending S/MIME signed receipts instead of plain MIME/Multipart... Well, in theory that's the correct answer, and it looks more an implementation/support problem of MTAs than realted to protool specifications... it is just combining two specifcations to get the desidered result IMHO... and veryfying that there are s/w implementation which allow the administrator to do that... but better ask a wider opinion before answering... Comments? ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Sun Jan 11 07:14:57 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9D61A6F2A for ; Sun, 11 Jan 2015 07:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwTs_H9Z7VMC for ; Sun, 11 Jan 2015 07:14:53 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.230]) by ietfa.amsl.com (Postfix) with ESMTP id B36631A6F02 for ; Sun, 11 Jan 2015 07:14:53 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:25829] helo=rubix) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 36/0B-30974-C6392B45; Sun, 11 Jan 2015 15:14:53 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id F0AD6140035; Sun, 11 Jan 2015 10:14:52 -0500 (EST) Message-ID: <54B2936B.7030805@intertwingly.net> Date: Sun, 11 Jan 2015 10:14:51 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Julian Reschke , Sean Leonard , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> In-Reply-To: <54B28E0F.8070306@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 15:14:56 -0000 On 1/11/15 9:51 AM, Julian Reschke wrote: > On 2015-01-11 00:32, Sam Ruby wrote: >> ... >> As a concrete example, I believe that the repertoire of characters >> available for fragment identifiers should be expanded. >> ... > > Could you provide a bit more information? Example for a character > missing? And the reason to add it? More details available here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27252 As luck would have it, I had a chance to discuss this with Tim Berners-Lee in person on Wednesday. A typical URI parsing library will treat everything after the hash mark as a fragment. The current proposal can be found here: https://specs.webplatform.org/url/webspecs/develop/#fragment Here are the proposed set of conforming characters: https://specs.webplatform.org/url/webspecs/develop/#url-code-points Additionally, the presence of a percent sign not immediately followed by two ASCII hex digits would also be a conformance error. > Best regards, Julian - Sam Ruby From nobody Sun Jan 11 07:25:52 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937A81A6F2A for ; Sun, 11 Jan 2015 07:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNJrjiqFTqh9 for ; Sun, 11 Jan 2015 07:25:47 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 141431A6F02 for ; Sun, 11 Jan 2015 07:25:47 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PH6LV640U800EK79@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 11 Jan 2015 07:20:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1420989639; bh=9k51EHyy5v4IOC7WGIpo4FDXBotBz48yOCU/xeIeh7U=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=NQML/lv1pmXPREVEHtrsF2Fxf35vgKRvRJtenxGQcGwE0EK44x/SDnP4B7FVUCCBI lJ94DQMw+G0yuRT/tOAsx/iK5JpIci3oQJE/Zqn3VhGUf8clB2u4eqIctm9roaqBKf lO9TaHHgWMvcnuwtzWhUIfrFXvcD31gF786mjbBE= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PH4G1QXR7400FTL0@mauve.mrochek.com>; Sun, 11 Jan 2015 07:20:35 -0800 (PST) Message-id: <01PH6LUZUOFE00FTL0@mauve.mrochek.com> Date: Sun, 11 Jan 2015 07:11:49 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 11 Jan 2015 16:06:19 +0100 (CET)" References: To: Claudio Allocchio Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 15:25:48 -0000 > Hello all, > I've been explicitly asked the question if the correct way to avoind the > possible forgery of DSNs described in the Security Consideration sections > of RFC3464 is to have the MTA sending S/MIME signed receipts instead of > plain MIME/Multipart... > Well, in theory that's the correct answer, and it looks more an > implementation/support problem of MTAs than realted to protool > specifications... it is just combining two specifcations to get the > desidered result IMHO... and veryfying that there are s/w implementation > which allow the administrator to do that... but better ask a wider opinion > before answering... What mechanism are you supposed to use to validate the signature on such receipts? Absent a specification for such a mechanism - which as far as I know does not exist - I don't see how this really helps. The other question is what sort of forgery are you worried about? If you're talking about spam DSNs, then that can be dealt with by correlating DSNs with the messages a user actually sent. If, OTOH, you're worried about someone sending fake DSNs saying a message was bounced when it wasn't, or received when it wasn't, then I think a better understanding of the actual threat you're concerned with is needed before suggestions can be made. Ned From nobody Sun Jan 11 07:48:21 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5211A6FCB for ; Sun, 11 Jan 2015 07:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZuEFcjb0Yea for ; Sun, 11 Jan 2015 07:48:17 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2CC1A6F7C for ; Sun, 11 Jan 2015 07:48:16 -0800 (PST) Received: internal info suppressed Date: Sun, 11 Jan 2015 16:48:11 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.local To: Ned Freed In-Reply-To: <01PH6LUZUOFE00FTL0@mauve.mrochek.com> Message-ID: References: <01PH6LUZUOFE00FTL0@mauve.mrochek.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1420991292; bh=PRVBMXaUEy4lTiQz6IwvdGZr0BPxvrWQTAOyoB+bnvc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=GGtllF9VbWA14lCiZGeKJqjgoB+aCc7zImRU4SNOyVWgNQiqQpDKQq8iR+dUGuJKn QbssSRzumky4LFY+ayoUYDOwP42ZY9gCZ9bcaLsIsxx6jVciotkzV2N+l3N6X/oBd2 XhjhDafSxj+OM6yBBQZzgaCrbsYNa7Y6OwX24f2Q= Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 15:48:19 -0000 Hi Ned, On Sun, 11 Jan 2015, Ned Freed wrote: > >> Hello all, > >> I've been explicitly asked the question if the correct way to avoind the >> possible forgery of DSNs described in the Security Consideration sections >> of RFC3464 is to have the MTA sending S/MIME signed receipts instead of >> plain MIME/Multipart... > >> Well, in theory that's the correct answer, and it looks more an >> implementation/support problem of MTAs than realted to protool >> specifications... it is just combining two specifcations to get the >> desidered result IMHO... and veryfying that there are s/w implementation >> which allow the administrator to do that... but better ask a wider opinion >> before answering... > > What mechanism are you supposed to use to validate the signature on such > receipts? Absent a specification for such a mechanism - which as far as I > know > does not exist - I don't see how this really helps. I was thinking of a server-certificate issued to the MTA making the signature, and to use the certificate to sign with S/MIME the DSN message. So... is it not enough to use the same signiature verification mechanisms used when a human user send an S/MIME signed message? Or am I wrong? > The other question is what sort of forgery are you worried about? If you're > talking about spam DSNs, then that can be dealt with by correlating DSNs with > the messages a user actually sent. no, this was not the case. > If, OTOH, you're worried about someone sending fake DSNs saying a message > was bounced when it wasn't, or received when it wasn't, then I think a better > understanding of the actual threat you're concerned with is needed before > suggestions can be made. This was the case being asked indeed... the latter: - a message is sent asking for a DSN. - the message indeed is NOT delivered to the actual recipient (for example it is intercepted by somebody else via spoofed DNS MX records, or other DNS spoofing mechanisms), but the man-in-the-middle MTA issues a forged positive DSN to the sender. - the sender is convinced his message was delivered, but indeed it was not. In such a case, of case, there is of course the verification inside the MTA log of the real recipient which can identify the forgery, but the sender usually does not have access to this information, and trusts what the DSN he/she received say. (the other case, e.g. the message was delivered, but a forged negative DSN is issued, is not a real issue in such a case). Does this clarify the issue? > Ned > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Sun Jan 11 07:53:54 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F631A7001 for ; Sun, 11 Jan 2015 07:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZCU3i3vqlQD for ; Sun, 11 Jan 2015 07:53:51 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 C3F5B1A7000 for ; Sun, 11 Jan 2015 07:53:50 -0800 (PST) Received: from [192.168.2.175] ([84.187.47.145]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LbMmA-1XTsU20WsM-00kyk6; Sun, 11 Jan 2015 16:53:48 +0100 Message-ID: <54B29C84.8010709@gmx.de> Date: Sun, 11 Jan 2015 16:53:40 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , Sean Leonard , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> In-Reply-To: <54B2936B.7030805@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:E2HhIh0oPIhvvTNI0DLvov7+BZFrAsj7Mv4I3+oZnr7dOlr4RRF fpfiwHaQlCM+a+mXs7pRHL5MikWm6EhzYWNpD5hiBQK6RCvH1KeYY7lHV26xLtc4jg36H5K C1teNZIn91P6yhkVHyqjzL1nXTxXbI51cS1Dw62T8+uYi3+Y+UcB8rKwCROWytpgylMnW3k Dy7dYzqb8tOHxrgDT9HYQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 15:53:54 -0000 On 2015-01-11 16:14, Sam Ruby wrote: > On 1/11/15 9:51 AM, Julian Reschke wrote: >> On 2015-01-11 00:32, Sam Ruby wrote: >>> ... >>> As a concrete example, I believe that the repertoire of characters >>> available for fragment identifiers should be expanded. >>> ... >> >> Could you provide a bit more information? Example for a character >> missing? And the reason to add it? > > More details available here: > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=27252 > > As luck would have it, I had a chance to discuss this with Tim > Berners-Lee in person on Wednesday. A typical URI parsing library will > treat everything after the hash mark as a fragment. > > The current proposal can be found here: > > https://specs.webplatform.org/url/webspecs/develop/#fragment > > Here are the proposed set of conforming characters: > > https://specs.webplatform.org/url/webspecs/develop/#url-code-points > > Additionally, the presence of a percent sign not immediately followed by > two ASCII hex digits would also be a conformance error. > >> Best regards, Julian > > - Sam Ruby Now suffering from information overflow. We were discussing RFC 3986. Which *ASCII* characters that are currently forbidden in fragment identifiers do you want to allow? Best regards, Julian From nobody Sun Jan 11 07:57:45 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED8C1A6FF8 for ; Sun, 11 Jan 2015 07:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HITwwfGpc4ak for ; Sun, 11 Jan 2015 07:57:41 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 721BD1A6FE9 for ; Sun, 11 Jan 2015 07:57:41 -0800 (PST) Received: internal info suppressed Date: Sun, 11 Jan 2015 16:57:36 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.local To: Claudio Allocchio In-Reply-To: Message-ID: References: <01PH6LUZUOFE00FTL0@mauve.mrochek.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1420991857; bh=nRp6omESbvirpCRi7m8XJzrTLlMmHscOvO2KZ1axtLI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=VcbdgN5MYtLrVHyF0RJt+9FNa2jXcjJhnqmiCCTPpNECL2tZOfsK9I73o1Qg6tZRp QHz88KoREQ2CAKhWf4alP4ewten9WcEW69WndtFLzGjG16NGGN/qhZFTUHs6ZPtAM8 SA1a9pW9yBM4YB1Cq9ZwMTQ9uOv2M5lOgcEE7oQo= Archived-At: Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 15:57:44 -0000 in short... the question may be seen as: how can the sender be sure that the DSN he/she receives (when he/she ask one sending a message) really comes from the real recipient MTA, thus the message was really delivered? I'm talking about an average end user, with not idea of internals... of course, and of the current deployment, so Secure DNS is "not yet there" in many environments. On Sun, 11 Jan 2015, Claudio Allocchio wrote: > > Hi Ned, > > On Sun, 11 Jan 2015, Ned Freed wrote: > >> >>> Hello all, >> >>> I've been explicitly asked the question if the correct way to avoind the >>> possible forgery of DSNs described in the Security Consideration sections >>> of RFC3464 is to have the MTA sending S/MIME signed receipts instead of >>> plain MIME/Multipart... >> >>> Well, in theory that's the correct answer, and it looks more an >>> implementation/support problem of MTAs than realted to protool >>> specifications... it is just combining two specifcations to get the >>> desidered result IMHO... and veryfying that there are s/w implementation >>> which allow the administrator to do that... but better ask a wider opinion >>> before answering... >> >> What mechanism are you supposed to use to validate the signature on such >> receipts? Absent a specification for such a mechanism - which as far as I >> know >> does not exist - I don't see how this really helps. > > I was thinking of a server-certificate issued to the MTA making the > signature, and to use the certificate to sign with S/MIME the DSN message. > So... is it not enough to use the same signiature verification mechanisms > used when a human user send an S/MIME signed message? Or am I wrong? > >> The other question is what sort of forgery are you worried about? If you're >> talking about spam DSNs, then that can be dealt with by correlating DSNs >> with >> the messages a user actually sent. > > no, this was not the case. > >> If, OTOH, you're worried about someone sending fake DSNs saying a message >> was bounced when it wasn't, or received when it wasn't, then I think a >> better >> understanding of the actual threat you're concerned with is needed before >> suggestions can be made. > > This was the case being asked indeed... the latter: > > - a message is sent asking for a DSN. > > - the message indeed is NOT delivered to the actual recipient (for example it > is intercepted by somebody else via spoofed DNS MX records, or other DNS > spoofing mechanisms), but the man-in-the-middle MTA issues a forged positive > DSN to the sender. > > - the sender is convinced his message was delivered, but indeed it was not. > > In such a case, of case, there is of course the verification inside the MTA > log of the real recipient which can identify the forgery, but the sender > usually does not have access to this information, and trusts what the DSN > he/she received say. > > (the other case, e.g. the message was delivered, but a forged negative DSN is > issued, is not a real issue in such a case). > > Does this clarify the issue? > > > >> Ned >> > > ------------------------------------------------------------------------------ > Claudio Allocchio G A R R > Claudio.Allocchio@garr.it > Senior Technical Officer > tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; > fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; > > PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Sun Jan 11 08:04:46 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C501A7005 for ; Sun, 11 Jan 2015 08:04:45 -0800 (PST) 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 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 KenHLMEzQpsu for ; Sun, 11 Jan 2015 08:04:43 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 E6DD01A6FE9 for ; Sun, 11 Jan 2015 08:04:42 -0800 (PST) Received: from [172.20.3.176] (unknown [66.228.68.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 56A4C509BE; Sun, 11 Jan 2015 11:04:41 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Mark Nottingham In-Reply-To: <54B2936B.7030805@intertwingly.net> Date: Sun, 11 Jan 2015 11:04:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> To: Sam Ruby X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "Julian F. Reschke" , apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 16:04:46 -0000 One more point of data -=20 https://indiewebcamp.com/fragmention Note that they=E2=80=99re using a second #, which isn=E2=80=99t = conformant to the URI ABNF. Cheers, > On 11 Jan 2015, at 10:14 am, Sam Ruby wrote: >=20 > On 1/11/15 9:51 AM, Julian Reschke wrote: >> On 2015-01-11 00:32, Sam Ruby wrote: >>> ... >>> As a concrete example, I believe that the repertoire of characters >>> available for fragment identifiers should be expanded. >>> ... >>=20 >> Could you provide a bit more information? Example for a character >> missing? And the reason to add it? >=20 > More details available here: >=20 > https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D27252 >=20 > As luck would have it, I had a chance to discuss this with Tim = Berners-Lee in person on Wednesday. A typical URI parsing library will = treat everything after the hash mark as a fragment. >=20 > The current proposal can be found here: >=20 > https://specs.webplatform.org/url/webspecs/develop/#fragment >=20 > Here are the proposed set of conforming characters: >=20 > https://specs.webplatform.org/url/webspecs/develop/#url-code-points >=20 > Additionally, the presence of a percent sign not immediately followed = by two ASCII hex digits would also be a conformance error. >=20 >> Best regards, Julian >=20 > - Sam Ruby >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From nobody Sun Jan 11 08:19:31 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106C51A7021 for ; Sun, 11 Jan 2015 08:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNElMcAEU3Bw for ; Sun, 11 Jan 2015 08:19:27 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.231]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1491A7009 for ; Sun, 11 Jan 2015 08:19:26 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:32328] helo=rubix) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 2F/EF-30379-E82A2B45; Sun, 11 Jan 2015 16:19:26 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 79AE5140D09; Sun, 11 Jan 2015 11:19:26 -0500 (EST) Message-ID: <54B2A28D.40003@intertwingly.net> Date: Sun, 11 Jan 2015 11:19:25 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Julian Reschke , Sean Leonard , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <54B29C84.8010709@gmx.de> In-Reply-To: <54B29C84.8010709@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 16:19:29 -0000 On 01/11/2015 10:53 AM, Julian Reschke wrote: > On 2015-01-11 16:14, Sam Ruby wrote: >> On 1/11/15 9:51 AM, Julian Reschke wrote: >>> On 2015-01-11 00:32, Sam Ruby wrote: >>>> ... >>>> As a concrete example, I believe that the repertoire of characters >>>> available for fragment identifiers should be expanded. >>>> ... >>> >>> Could you provide a bit more information? Example for a character >>> missing? And the reason to add it? >> >> More details available here: >> >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27252 >> >> As luck would have it, I had a chance to discuss this with Tim >> Berners-Lee in person on Wednesday. A typical URI parsing library will >> treat everything after the hash mark as a fragment. >> >> The current proposal can be found here: >> >> https://specs.webplatform.org/url/webspecs/develop/#fragment >> >> Here are the proposed set of conforming characters: >> >> https://specs.webplatform.org/url/webspecs/develop/#url-code-points >> >> Additionally, the presence of a percent sign not immediately followed by >> two ASCII hex digits would also be a conformance error. >> >>> Best regards, Julian >> >> - Sam Ruby > > Now suffering from information overflow. > > We were discussing RFC 3986. Which *ASCII* characters that are currently > forbidden in fragment identifiers do you want to allow? We seem to be in a loop. To you, RFC 3986 (including potential errata and/or bis work) implies ASCII. I point out that that restriction does not seem to make sense for fragments. You return back to asking about ASCII. To help break this loop, permit me to turn this question around. Restricting the scope of the conversation to fragments, why do you believe it makes sense to limit such to ASCII only? What problems do non-ASCII characters in fragments cause? > Best regards, Julian - Sam Ruby From nobody Sun Jan 11 08:20:47 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD291A7012 for ; Sun, 11 Jan 2015 08:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRYqMLux-WU8 for ; Sun, 11 Jan 2015 08:20:41 -0800 (PST) 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 A7F7D1A7005 for ; Sun, 11 Jan 2015 08:20:40 -0800 (PST) Received: from [192.168.2.175] ([84.187.47.145]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MXIcX-1YGAnQ2R8f-00WAsZ; Sun, 11 Jan 2015 17:20:37 +0100 Message-ID: <54B2A2CD.5080502@gmx.de> Date: Sun, 11 Jan 2015 17:20:29 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Mark Nottingham , Sam Ruby References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> In-Reply-To: <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:+uBv8Y6rSxCWBcJfxr6Kt+pwxa/m2arAjWPtBERiytfggTMx/2W zscRQSAr9fMDG/OGrK9fHJf2Gk2tfrSUR9RwFnbuG8uumOwUxhC+z3iNO1x58rVeDb/tAQM sZYBne/2drRcNBxAIwDNJAjIxgn0i55Yz5YGjevze8a4OXCgilUqUG2NO2/YKewEAtcFOsd Q+aptf4Z3zvrlFLj5OU9A== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 16:20:44 -0000 On 2015-01-11 17:04, Mark Nottingham wrote: > One more point of data - > https://indiewebcamp.com/fragmention > > Note that they’re using a second #, which isn’t conformant to the URI ABNF. > ... Well, this is new work, right. Why don't they use something that *is* conforming? Best regards, Julian From nobody Sun Jan 11 08:25:15 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380341A7021 for ; Sun, 11 Jan 2015 08:25:13 -0800 (PST) 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 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 90_I_iW8Djx2 for ; Sun, 11 Jan 2015 08:25:11 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 1AAB61A7012 for ; Sun, 11 Jan 2015 08:25:11 -0800 (PST) Received: from [172.20.3.176] (unknown [66.228.68.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E10ED509BD; Sun, 11 Jan 2015 11:25:09 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Mark Nottingham In-Reply-To: <54B2A2CD.5080502@gmx.de> Date: Sun, 11 Jan 2015 11:25:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> To: "Julian F. Reschke" X-Mailer: Apple Mail (2.1993) Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 16:25:13 -0000 I and others have brought that up. What=E2=80=99s interesting is that = they say it=E2=80=99s reasonably interoperable with deployed = implementations. Cheers, > On 11 Jan 2015, at 11:20 am, Julian Reschke = wrote: >=20 > On 2015-01-11 17:04, Mark Nottingham wrote: >> One more point of data - >> https://indiewebcamp.com/fragmention >>=20 >> Note that they=E2=80=99re using a second #, which isn=E2=80=99t = conformant to the URI ABNF. >> ... >=20 > Well, this is new work, right. Why don't they use something that *is* = conforming? >=20 > Best regards, Julian -- Mark Nottingham http://www.mnot.net/ From nobody Sun Jan 11 08:28:58 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297DB1A7012 for ; Sun, 11 Jan 2015 08:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xKhZj7krG3b for ; Sun, 11 Jan 2015 08:28:55 -0800 (PST) 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 24A561A7009 for ; Sun, 11 Jan 2015 08:28:55 -0800 (PST) Received: from [192.168.2.175] ([84.187.47.145]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MC4VE-1Y1Vfy1GSW-008teA; Sun, 11 Jan 2015 17:28:46 +0100 Message-ID: <54B2A4B6.1090509@gmx.de> Date: Sun, 11 Jan 2015 17:28:38 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , Sean Leonard , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <54B29C84.8010709@gmx.de> <54B2A28D.40003@intertwingly.net> In-Reply-To: <54B2A28D.40003@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:DicR+gIfZoC14lbhK2WFfCnM0Lgnm7GVwfYmi1133ciZTDQr4k4 LuZhd7O4ncgApA1QBzh0Bl+lwNPlNkDAt6qnxx3J5/kJSlRVV7LG5/cVI2rOvif56DSLenP be3ioSK98o/ZqUi/qhWlDDLksCjBzYyHFXisHKkbi67/YJH1fy9VQUGmQVxS0apKkO6kLJg 7q9V+Jk2aRhLZtRW+Z4vw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 16:28:57 -0000 On 2015-01-11 17:19, Sam Ruby wrote: > ... >> Now suffering from information overflow. >> >> We were discussing RFC 3986. Which *ASCII* characters that are currently >> forbidden in fragment identifiers do you want to allow? > > We seem to be in a loop. > > To you, RFC 3986 (including potential errata and/or bis work) implies > ASCII. > > I point out that that restriction does not seem to make sense for > fragments. Actually, you did not. Instead you pointed to lots of material somewhere else that I didn't want to parse just to find out what you're proposing. > You return back to asking about ASCII. Because that's what RFC 3986 is concerned with. > To help break this loop, permit me to turn this question around. > Restricting the scope of the conversation to fragments, why do you > believe it makes sense to limit such to ASCII only? What problems do > non-ASCII characters in fragments cause? I fail to see how fragments are special here compared to, say, the path. I fully agree that work on what we used to call IRIs is something that needs to be done. However right now I'm trying to figure out what's wrong with RFC *3986*. I hear you saying that URIs should allow non-ASCII characters in certain places. This may break code where these characters are put on the wire (such as HTTP) or stored in places that do not allow non-ASCII characters (say, a database column). The fact that it's hard to extend the URI character repertoire beyond ASCII is why the IETF attempted to do it in a separate spec/construct. I'm not convinced that the situation has changed sufficiently to invalidate that approach. Best regards, Julian From nobody Sun Jan 11 08:30:08 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5D31A7026 for ; Sun, 11 Jan 2015 08:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ8T930nGXxe for ; Sun, 11 Jan 2015 08:30:01 -0800 (PST) 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 75C291A7021 for ; Sun, 11 Jan 2015 08:30:01 -0800 (PST) Received: from [192.168.2.175] ([84.187.47.145]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MU0pN-1YJS6K2bBp-00Qh0L; Sun, 11 Jan 2015 17:29:53 +0100 Message-ID: <54B2A4F9.2070909@gmx.de> Date: Sun, 11 Jan 2015 17:29:45 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Mark Nottingham References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> In-Reply-To: <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:0rz5QRJyGZBF/K60nF17vq3o0YtAn0BnJuWp44HTy42IW6cAuEY yg4p55zzMAMI2dxae503cuVfbyzq44B4PiSvW4vk58ulRgnXzPE699dPaiYbXtvQFA4TTzq Lc0886lDESR9Cc2oZEuGQGNR/bP9i8VoqFNs3QyoUIBsvtRFUYbmGEm4MlYJHkLEo+ehm3M MSoEzJa9gj+EYQtAS6U+g== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 16:30:07 -0000 On 2015-01-11 17:25, Mark Nottingham wrote: > I and others have brought that up. What’s interesting is that they say it’s reasonably interoperable with deployed implementations. > > Cheers, > ... Let me guess: "deployed implementations" == "what current browsers do". Best regards, Julian From nobody Sun Jan 11 08:35:45 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3672E1A7026 for ; Sun, 11 Jan 2015 08:35:43 -0800 (PST) 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 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 oA5EyejvU6Kr for ; Sun, 11 Jan 2015 08:35:41 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 6A28D1A7021 for ; Sun, 11 Jan 2015 08:35:41 -0800 (PST) Received: from [172.20.3.176] (unknown [66.228.68.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 22749509BF; Sun, 11 Jan 2015 11:35:40 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Mark Nottingham In-Reply-To: <54B2A4F9.2070909@gmx.de> Date: Sun, 11 Jan 2015 11:35:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <583755D8-3FEC-4144-838D-F67BB80D6165@mnot.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> To: "Julian F. Reschke" X-Mailer: Apple Mail (2.1993) Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 16:35:43 -0000 =E2=80=A6 and Curl, IIRC.=20 > On 11 Jan 2015, at 11:29 am, Julian Reschke = wrote: >=20 > On 2015-01-11 17:25, Mark Nottingham wrote: >> I and others have brought that up. What=E2=80=99s interesting is that = they say it=E2=80=99s reasonably interoperable with deployed = implementations. >>=20 >> Cheers, >> ... >=20 > Let me guess: "deployed implementations" =3D=3D "what current browsers = do". >=20 > Best regards, Julian -- Mark Nottingham http://www.mnot.net/ From nobody Sun Jan 11 08:45:14 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1D11A7032 for ; Sun, 11 Jan 2015 08:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X60qGm5FOdIw for ; Sun, 11 Jan 2015 08:45:10 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.230]) by ietfa.amsl.com (Postfix) with ESMTP id 021961A7029 for ; Sun, 11 Jan 2015 08:45:09 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:38271] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 52/EE-03035-598A2B45; Sun, 11 Jan 2015 16:45:09 +0000 Received: from [192.168.1.115] (unknown [192.168.1.115]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 7CC24140B53; Sun, 11 Jan 2015 11:45:09 -0500 (EST) Message-ID: <54B2A894.4020201@intertwingly.net> Date: Sun, 11 Jan 2015 11:45:08 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Julian Reschke , Mark Nottingham References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> In-Reply-To: <54B2A4F9.2070909@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 16:45:13 -0000 On 01/11/2015 11:29 AM, Julian Reschke wrote: > On 2015-01-11 17:25, Mark Nottingham wrote: >> I and others have brought that up. What’s interesting is that they say >> it’s reasonably interoperable with deployed implementations. >> >> Cheers, >> ... > > Let me guess: "deployed implementations" == "what current browsers do". Your sarcasm is not appreciated. I encourage you to actually look at test results: https://url.spec.whatwg.org/interop/test-results/7b83ef3682 > Best regards, Julian - Sam Ruby From nobody Sun Jan 11 08:52:40 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5033E1A70FD for ; Sun, 11 Jan 2015 08:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBrg88eer8Zu for ; Sun, 11 Jan 2015 08:52:36 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 48F471A702F for ; Sun, 11 Jan 2015 08:52:36 -0800 (PST) Received: from [192.168.2.175] ([84.187.47.145]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MGFz9-1XxxhE1ZiB-00FCd0; Sun, 11 Jan 2015 17:52:27 +0100 Message-ID: <54B2AA43.20600@gmx.de> Date: Sun, 11 Jan 2015 17:52:19 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Mark Nottingham References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <583755D8-3FEC-4144-838D-F67BB80D6165@mnot.net> In-Reply-To: <583755D8-3FEC-4144-838D-F67BB80D6165@mnot.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:Nj0NyjDeQC2k+wO5rDyI78nLCKXQqwXaycXgKf48GyAVSdLm9RL f541Kk1BWMXqrp34T+ptOnYXev6BNLacfV1o5X7DzsFrA2B1y1bOuYbBcm63cGhUR+esRRX 0r/nNBMAHi+MI5ixAy8+Y1Rvw8dOyH/H7OKYIli8gZ/0aoBdq7HufSje0vZpOC6rW8T9CNI 1G8GNihYgPyAukcFipJjw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 16:52:38 -0000 On 2015-01-11 17:35, Mark Nottingham wrote: > … and Curl, IIRC. > ... I'm sure it is true for many implementations. However, given the URI spec, scanning for the "#" from the *end* would be entirely conforming and reasonable, and code like that would be broken. Also, people shouldn't forget that there already is a framework for using fragment identifiers that are not based on document anchors; and that is XPointer. There's a reason why certain characters were disallowed in anchors (such as HTML's @id); it's to preserve an extension point for new addressing schemes. Best regards, Julian From nobody Sun Jan 11 08:58:31 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC561A86E4 for ; Sun, 11 Jan 2015 08:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ga7NpbDmuefX for ; Sun, 11 Jan 2015 08:58:28 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 BA60F1A802E for ; Sun, 11 Jan 2015 08:58:27 -0800 (PST) Received: from [192.168.2.175] ([84.187.47.145]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MTfZc-1YJBY02yQq-00QThf; Sun, 11 Jan 2015 17:58:24 +0100 Message-ID: <54B2ABA8.6030205@gmx.de> Date: Sun, 11 Jan 2015 17:58:16 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , Mark Nottingham References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> In-Reply-To: <54B2A894.4020201@intertwingly.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:RnScZ1ajd/pwrL2MULiEfPO0noO1moSsO8pZ1SYxG28kv2sxh1/ VYZkQJ2wmVcHOCzkBOkBNXzA2TFRpe81IWHTRZ6Kxr5amoWgDH+O6i3jzz2wEJv5NRzY1Mi rs4/gAnICjfLkgf/UdpyeE354zw1RXwMWplHU9cFmtoqh7uSCxwLfUJ9d48wHJiKL+uBa/e wrGHmta5jr9Pmx+ODd1fQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 16:58:30 -0000 On 2015-01-11 17:45, Sam Ruby wrote: > On 01/11/2015 11:29 AM, Julian Reschke wrote: >> On 2015-01-11 17:25, Mark Nottingham wrote: >>> I and others have brought that up. What’s interesting is that they say >>> it’s reasonably interoperable with deployed implementations. >>> >>> Cheers, >>> ... >> >> Let me guess: "deployed implementations" == "what current browsers do". > > Your sarcasm is not appreciated. > > I encourage you to actually look at test results: > > https://url.spec.whatwg.org/interop/test-results/7b83ef3682 > >> Best regards, Julian > > - Sam Ruby Sam, I was referring to what Mark linked to (the use of a leading "#" inside a fragment identifier). The test above tests something else. Looking at *that* test: it tests a non-ASCII character in a fragment (not allowed per RFC 3986). The tests show that it's accepted, but some implementations subsequently UTF8-encode-then-percent-escape. So non-ASCII is indeed not interoperable, unless you normalize the result. UTF8PercentEscaping non-ASCII characters *before* putting them inside a URI's fragment identifier would be another test; it would be interesting to see whether the implementations consistently treat the escaping. Best regards, Julian From nobody Sun Jan 11 09:17:51 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108BE1A802E for ; Sun, 11 Jan 2015 09:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 774pntU58RcT for ; Sun, 11 Jan 2015 09:17:46 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF7F1A7034 for ; Sun, 11 Jan 2015 09:17:46 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PH6PS08ARK00FNQ0@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 11 Jan 2015 09:12:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1420996359; bh=y8oO5OrAV79s2pZglYG3bLYu5wXfZb3QybR8qG3C6/o=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=KXGU/+x/vShv4RF435TyYnxVSxxi4IQ+jgX7ykC/j/QcJ3b4WVjetzbxLdwKMZSsM Fz0QF9NItfvcBmZcEb0W8dJ7yjU5Y5q8qqSWhRfmbBrzafTRzQ1c90DpgmRv/ZqeWu VnLYmYnGYp6rWoAR+1J/3eq33iuGAg2P4nCbuHUM= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PH4G1QXR7400FTL0@mauve.mrochek.com>; Sun, 11 Jan 2015 09:12:33 -0800 (PST) Message-id: <01PH6PRW81Y600FTL0@mauve.mrochek.com> Date: Sun, 11 Jan 2015 08:45:41 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 11 Jan 2015 16:48:11 +0100 (CET)" References: <01PH6LUZUOFE00FTL0@mauve.mrochek.com> To: Claudio Allocchio Archived-At: Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 17:17:49 -0000 > Hi Ned, > On Sun, 11 Jan 2015, Ned Freed wrote: > > > >> Hello all, > > > >> I've been explicitly asked the question if the correct way to avoind the > >> possible forgery of DSNs described in the Security Consideration sections > >> of RFC3464 is to have the MTA sending S/MIME signed receipts instead of > >> plain MIME/Multipart... > > > >> Well, in theory that's the correct answer, and it looks more an > >> implementation/support problem of MTAs than realted to protool > >> specifications... it is just combining two specifcations to get the > >> desidered result IMHO... and veryfying that there are s/w implementation > >> which allow the administrator to do that... but better ask a wider opinion > >> before answering... > > > > What mechanism are you supposed to use to validate the signature on such > > receipts? Absent a specification for such a mechanism - which as far as I > > know > > does not exist - I don't see how this really helps. > I was thinking of a server-certificate issued to the MTA making the > signature, and to use the certificate to sign with S/MIME the DSN message. > So... is it not enough to use the same signiature verification mechanisms > used when a human user send an S/MIME signed message? Or am I wrong? OK, so I have a proper server certificate with a proper chain of trust in place. How do you know that that certificate is authorized to sign DSNs for a given recipient address? If your response is to say that the domain in the certificate and the domain of the recipient address must match, that's not going to work because mail servers routinely handle hundreds, thousands, even tens of thousands of recipient domains. > > The other question is what sort of forgery are you worried about? If you're > > talking about spam DSNs, then that can be dealt with by correlating DSNs with > > the messages a user actually sent. > no, this was not the case. > > If, OTOH, you're worried about someone sending fake DSNs saying a message > > was bounced when it wasn't, or received when it wasn't, then I think a better > > understanding of the actual threat you're concerned with is needed before > > suggestions can be made. > This was the case being asked indeed... the latter: > - a message is sent asking for a DSN. > - the message indeed is NOT delivered to the actual recipient (for example > it is intercepted by somebody else via spoofed DNS MX records, or other > DNS spoofing mechanisms), but the man-in-the-middle MTA issues a forged > positive DSN to the sender. If you're talking about general Internet mail, why bother with the forgery of a success DSN? The chances of success DSNs working in today's Internet are low - they create far too much blowback spam. And if you're in a position to mandate support for and generation of success DSNs by your recipients, you're also in a position to mandate the use of a particular certificate for signing those DSNs, and your problem is solved - sort of. I also note that you'd probably also be in a position to mandate the use of secure DNS, server certificate validation, and so on, eliminating the ability to intercept the mail in the first place. But this has now shifted into the area of bilateral agreements, not Internet email in general, and I no longer see it as having much relevance to the IETF, whose responsibility is to create solutions that operate at true Internet scale. > - the sender is convinced his message was delivered, but indeed it was > not. > In such a case, of case, there is of course the verification inside the > MTA log of the real recipient which can identify the forgery, but the > sender usually does not have access to this information, and trusts what > the DSN he/she received say. > (the other case, e.g. the message was delivered, but a forged negative DSN > is issued, is not a real issue in such a case). > Does this clarify the issue? The reason I said "sort of" is while you may have mitigated the ability of an intermediary to intercept mail and lie about it having been delivered, you still do not have true nonrepudication of delivery, which it seems to me is what you're really after. Specifically, you're still trusting some other set of administrative domains - the domains receiving these messages, not to lie their little asses off. The solution to this is to use a trusted third party, and I were implementing something like this this is the approach I'd use. There are various commercial offerings that provide various sorts of funcitonality in thie general area. The one I know for sure has an offering in this area is RPost, but I think Cisco also has something. Ned From nobody Sun Jan 11 09:44:56 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA0C1A86E4 for ; Sun, 11 Jan 2015 09:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGFvsdwHxq2D for ; Sun, 11 Jan 2015 09:44:51 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0733.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA22A1A1F01 for ; Sun, 11 Jan 2015 09:44:50 -0800 (PST) Received: from pc6 (81.151.167.59) by DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) with Microsoft SMTP Server (TLS) id 15.1.53.17; Sun, 11 Jan 2015 17:44:27 +0000 Message-ID: <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> From: t.petch To: Sam Ruby , References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> Date: Sun, 11 Jan 2015 17:43:20 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB4PR01CA0042.eurprd01.prod.exchangelabs.com (10.242.152.32) To DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DBXPR07MB064; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DBXPR07MB064; X-Forefront-PRVS: 045315E1EE X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(199003)(2473001)(189002)(479174004)(51704005)(377424004)(13464003)(377454003)(87976001)(50226001)(106356001)(122386002)(68736005)(107886001)(40100003)(1556002)(101416001)(561944003)(1456003)(47776003)(81686999)(33646002)(15975445007)(77096005)(2420400003)(76176999)(50986999)(50466002)(62236002)(44716002)(64706001)(61296003)(23746002)(230783001)(93886004)(66066001)(42186005)(81816999)(14496001)(86362001)(46102003)(19580395003)(105586002)(19580405001)(97736003)(77156002)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB064; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB064; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2015 17:44:27.2052 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB064 Archived-At: Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 17:44:54 -0000 ----- Original Message ----- From: "Sam Ruby" To: "t.petch" ; "Sean Leonard" ; Sent: Sunday, January 11, 2015 1:18 PM > On 01/11/2015 06:22 AM, t.petch wrote: > > From: "Sam Ruby" > > To: "Sean Leonard" ; > > Sent: Saturday, January 10, 2015 11:32 PM > >> On 01/10/2015 06:13 PM, Sean Leonard wrote: > >>> On 1/10/2015 1:05 PM, Sam Ruby wrote: > >>>> > >>>> Permit me to introduce myself. I'm one of the co-chairs of the W3C > >>>> HTML Working group. I am indeed aware of this work. > >>> > >>> Pleased to meet you! > >> > >> Likewise! > >> > >>> [various other text] > >>> > > An interesting idea. I have seen masses of Working Groups chartered > > while I have been contributing to the IETF and for all, I do not know > > where the first impetus comes from. Certainly it is up to the IESG to > > approve, approve the charter and so on, and most start with two > > IESG-approved BoFs at IETF meetings and these BoFs seem to come from WG > > Chairs or authors whose work I know well. The IETF website lists > > current BoFs. There is a deadline for requesting BoFs prior to any > > meeting such as IETF92 but I am not sure when that is. If you want it > > to happen, that is what needs to happen. > > 2015-02-06 (Friday): Cut-off date for BOF proposal requests to Area > Directors at UTC 23:59. > > http://www.ietf.org/meeting/important-dates-2015.html > > > I get the impression that the worst outcome is forming a WG which then > > decays, produces nothing, costs a lot, so the IESG looks for an awful > > lot of enthusiasm to start with, knowing that most of it will be gone > > within the year. > > By spring, I should be able to get browser vendors together in a room > and we should be able to review the following results together: > > https://url.spec.whatwg.org/interop/test-results/ > > Based on those discussions, the following specs will be updated: > > https://url.spec.whatwg.org/ > http://www.w3.org/TR/url/ > > I also plan to work with library authors for various popular programming > languages with the intent of making their URI/URL libraries more web > compatible. This work may take various forms: bug reports, patches, or > even new libraries. > > This work is all being done in the open, and I'm making an attempt to > reach out to everybody who may be interested in participating. Sam The sense I get from your e-mails is a concern with the http: scheme and perhaps not with other ones. As I am sure you know, there are hundreds of registered schemes, several of which are key to the operation of the Internet so in a sense, the http: scheme is almost insignificant in the scheme(!) of things. Perhaps RFC3986 could be thought of as an object class from which hundreds of specific schemes have inherited their generic syntax. To make an incompatible change to RFC3986, allowing separator characters to appear where previously prohibited or allowing additional characters not to be percent encoded, would need evaluating against all those hundreds of schemes to verify that the schemes still work, an interesting challenge. Of course, if a proposed change, and I am unclear what specific changes you propose, is upwards compatible, allowing all interpreters of other schemes to continue unaffected, then this would not apply. Tom Petch > - Sam Ruby From nobody Sun Jan 11 10:55:05 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFA31A87DB for ; Sun, 11 Jan 2015 10:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ikw14ucl6BK for ; Sun, 11 Jan 2015 10:54:52 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.228]) by ietfa.amsl.com (Postfix) with ESMTP id 77BD91A87CB for ; Sun, 11 Jan 2015 10:54:52 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:57030] helo=rubix) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 19/9C-30974-BF6C2B45; Sun, 11 Jan 2015 18:54:51 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id F3D39140B53; Sun, 11 Jan 2015 13:54:51 -0500 (EST) Message-ID: <54B2C6FA.80802@intertwingly.net> Date: Sun, 11 Jan 2015 13:54:50 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Julian Reschke , Mark Nottingham References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2ABA8.6030205@gmx.de> In-Reply-To: <54B2ABA8.6030205@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 18:55:04 -0000 On 01/11/2015 11:58 AM, Julian Reschke wrote: >> >> I encourage you to actually look at test results: >> >> https://url.spec.whatwg.org/interop/test-results/7b83ef3682 > > Looking at *that* test: it tests a non-ASCII character in a fragment > (not allowed per RFC 3986). The tests show that it's accepted, but some > implementations subsequently UTF8-encode-then-percent-escape. At some point, I would like to discuss what characters should be allowed in a fragment, and would like RFC 3986 either to match the set we come up with, or for RFC 3986 to be obsoleted by a specification that does. I've been proceeding by testing actual implementations and actually talking to at least two authors of RFC 3986. And, trust me, I plan to have conversations with the third author. Each time I try to have this discussion, you keep returning to what RFC 3986 currently says as of this moment. If and when you are ready to talk about what RFC 3986 or its successors should say at some point in the future, I'll be here. Meanwhile, it is my intention to produce a spec that matches reality, and to do so by meeting with people who produce tools and meeting them half-way. Meeting them half-way doesn't mean re-quoting what a decade old specification says, it means determining whether the specs need to be updated or the implementations need to be updated. On this particular test, I believe that it is quite likely that firefox, galimatias and rusturl will be updated to match the URL specification this year. It is my hope that safari will too. Getting agreement isn't easy, and it doesn't happen quickly. It, however, does require people who participate to agree that change is possible. - Sam Ruby From nobody Sun Jan 11 11:18:20 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABEF1A87D5 for ; Sun, 11 Jan 2015 11:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0p3d_jxPaoV for ; Sun, 11 Jan 2015 11:18:15 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.231]) by ietfa.amsl.com (Postfix) with ESMTP id 7021D1A7006 for ; Sun, 11 Jan 2015 11:18:15 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:58274] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 9B/DE-08411-57CC2B45; Sun, 11 Jan 2015 19:18:15 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 232AB140D93; Sun, 11 Jan 2015 14:18:14 -0500 (EST) Message-ID: <54B2CC75.5080900@intertwingly.net> Date: Sun, 11 Jan 2015 14:18:13 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "t.petch" , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> In-Reply-To: <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 19:18:16 -0000 On 01/11/2015 12:43 PM, t.petch wrote: > > The sense I get from your e-mails is a concern with the http: scheme and > perhaps not with other ones. I'm not sure where you got that impression, but I will assure you that that is not the case. I'd like the following Perl expression: URI->new_abs(input, base)->scheme . ":" ... to produce the same value as the following JavaScript expression: new URL(input, base).protocol ... for all sets of input and bases. Whether that means getting Perl to change, one or more web browsers to change, or one or more specs to change (and quite possibly, a combination of the above), is yet to be determined. - Sam Ruby From nobody Sun Jan 11 13:19:16 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBE21A7023 for ; Sun, 11 Jan 2015 13:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qY6MQJIyoL7P for ; Sun, 11 Jan 2015 13:19:12 -0800 (PST) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389671A7006 for ; Sun, 11 Jan 2015 13:19:11 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 6EE98FA0068; Sun, 11 Jan 2015 21:19:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1421011149; bh=RjfjpCgpKVuj4iBB1ls6vUS1s/8n8/kBq7SDEl5gzDs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=c6zZuZwSdLhUMGjbCJmyuai+S6rCCo3rfLIdtozp0CxhDz6IeOpmm6bsSQ2XemGg+ vf0onh1oHsiaCPj9LKcC9Povs719ykrdXOwHzoQF7Rw7L183HkYXGQ8qJrvwkogyvh 4PmLtB8Dj+P1B+KvRxGzILAlvdy/2dEj3mAiKySw= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1421011147-3758-3757/12/91; Sun, 11 Jan 2015 21:19:07 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Sun, 11 Jan 2015 22:19:07 +0100 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.6; X11; Linux; Ubuntu 14.04.1 LTS Mime-Version: 1.0 Message-Id: In-Reply-To: References: Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [apps-discuss] generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 21:19:14 -0000 IMNSHO: The proper way for a sender is to use an ENVID containing a rich dose of entropy, for a DSN generator to quote ENVID in all DSNs, and for a DSN parser to check ENVID and be appropriately distrustful if not supplied. These behaviour changes are cheap and simple to implement, require no semantic or syntactical changes, and harm compatbility with nothing. Arnt From nobody Sun Jan 11 13:41:41 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3885C1A1ACE for ; Sun, 11 Jan 2015 13:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TI9jphZesctB for ; Sun, 11 Jan 2015 13:41:37 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 63E8A1A1A86 for ; Sun, 11 Jan 2015 13:41:37 -0800 (PST) Received: from [192.168.2.175] ([84.187.47.145]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MXEs5-1YG6n93kzF-00WBiT; Sun, 11 Jan 2015 22:41:31 +0100 Message-ID: <54B2EE08.9040705@gmx.de> Date: Sun, 11 Jan 2015 22:41:28 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , Mark Nottingham References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2ABA8.6030205@gmx.de> <54B2C6FA.80802@intertwingly.net> In-Reply-To: <54B2C6FA.80802@intertwingly.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:lqfOPpjcwXx95heOsn22zvjfW1V/c9+P0CWqRxOwJur4ZorybF/ 9Z/K2bREdwrFykc7JNqvYBA7CUKdg8gvBndHL/k+9Ewv4ODw5szWEDDQgdTULu2MbmVi1Qm 5aampHEOka0/i/zfJv1+t+ExUlrY5JWNdkgE8QHP/QAesAeI/HULsLqn83iMg6l1TClKD7o 8JHOKLL8P2gDJcD0FDgmw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 21:41:39 -0000 On 2015-01-11 19:54, Sam Ruby wrote: > ... > At some point, I would like to discuss what characters should be allowed > in a fragment, and would like RFC 3986 either to match the set we come > up with, or for RFC 3986 to be obsoleted by a specification that does. > > I've been proceeding by testing actual implementations and actually > talking to at least two authors of RFC 3986. And, trust me, I plan to > have conversations with the third author. > > Each time I try to have this discussion, you keep returning to what RFC > 3986 currently says as of this moment. > ... I keep returning to URIs as things consisting of ASCII code points. If you want to talk about URI-like identifiers that can contain non-ASCII characters, we'll need to discuss RFC *3987*. As far as I can recall, there's more or less agreement that this needs to happen, but that's IMHO a different conversation than the one about RFC 3986. > ... Best regards, Julian From nobody Sun Jan 11 13:49:15 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677A51A1A86 for ; Sun, 11 Jan 2015 13:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTTwZSbAUBs1 for ; Sun, 11 Jan 2015 13:49:12 -0800 (PST) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B871A0BE8 for ; Sun, 11 Jan 2015 13:49:12 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id i13so13341025qae.13 for ; Sun, 11 Jan 2015 13:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:from:to:subject:importance:date:in-reply-to :references:content-type; bh=fyo6nddJ5og9wbgcQvX7tnWgakBSUrZurFGR6Npu4wE=; b=MCvEIojH2jgT/uICW0RBV9IvH5P1dE7KcThE4g8tFggNpcpKq88UeX9tfPSim6o1M3 +z03qC45BCZXWYiDpzRfFxArkGJcst0KmDkLryOBBm4ch3GmXmh5Jrwde78zeDadX48K YHeu/VkZXm08NOmMjqB95Z6zbvf/AjM79fujenyz2IaD/BVcmPq8E4cwMWvmdZ0350gh NhlxIP/ig1kcuYPZLfecDr7njY2llrtUlI1GeEley2My4pLZVWlMicRhBHJrI72OGfD0 H/UVan9+C5V43uZas7qOIshsbs+bf4E14dBvcZ7hRBSjq7fQWFcgGUFF3ftpYYkyr5aq 4A8w== X-Received: by 10.224.166.71 with SMTP id l7mr20618368qay.50.1421012951787; Sun, 11 Jan 2015 13:49:11 -0800 (PST) Received: from Pecan (static-207-253-111-30.vtl.net. [207.253.111.30]) by mx.google.com with ESMTPSA id o59sm13140413qga.0.2015.01.11.13.49.10 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 11 Jan 2015 13:49:11 -0800 (PST) Message-ID: <54b2efd7.c1308c0a.2b65.47f7@mx.google.com> MIME-Version: 1.0 From: To: "=?utf-8?Q?apps-discuss@ietf.org?=" Importance: Normal Date: Sun, 11 Jan 2015 21:24:27 +0000 In-Reply-To: <54B2C6FA.80802@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2ABA8.6030205@gmx.de>,<54B2C6FA.80802@intertwingly.net> Content-Type: multipart/alternative; boundary="_DE553726-AC86-491D-99F0-0C7C09D63C16_" Archived-At: Subject: Re: [apps-discuss] =?utf-8?q?Parsing_text_into_URLs_that_doesn=27t_co?= =?utf-8?q?nform_to_RFC_3986?= X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 21:49:14 -0000 --_DE553726-AC86-491D-99F0-0C7C09D63C16_ Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" V2hhdCByZWFsbHkgY29uY2VybnMgbWUgYWJvdXQgdGhlIGFwcGFyZW50IG9iamVjdGl2ZSBvZiBt YWtpbmcgYWxsIFVSTCBwYXJzZXJzIHByb2R1Y2UgaWRlbnRpY2FsIHJlc3VsdHMgZnJvbSB0aGUg c2V0IG9mIHRlc3RzIHByb2R1Y2VkIGJ5IFdoYXR3ZywgaXMgdGhhdCBpdCBzZWVtcyB0byBpZ25v cmUgdGhlIGZhY3QgdGhhdCBVUkxzIGFyZSBjcmVhdGVkIGFuZCBjb25zdW1lZCBpbiB2ZXJ5IGRp ZmZlcmVudCBjb250ZXh0cy4NCg0KDQoNCg0KV2hlbiB0ZXh0IGlzIGVudGVyZWQgaW4gdGhlIGFk ZHJlc3MgYmFyIG9mIGEgd2ViIGJyb3dzZXIgYW5kIGl0IGlzIHBhcnNlZCBhcyBhIFVSTCwgdGhl biBJIHVuZGVyc3RhbmQgdGhlIGRlc2lyZSB0byBiZSBhcyB0b2xlcmFudCBhcyBwb3NzaWJsZSBv ZiBlcnJvcnMuICBJIHNlZSBtaW5pbWFsIGRhbmdlciBpbiBtYWtpbmcgYW4gZWR1Y2F0ZWQgZ3Vl c3MgYXMgdG8gd2hhdCB0aGUgdXNlciBpbnRlbmRlZCBiZWNhdXNlIHRoZSBicm93c2VyIHdpbGwg bGlrZWx5IGNvcnJlY3QgdGhlIGVycm9yIGFuZCBzaG93IHRoZSB1c2VyIHdoYXQgdGhlIGNvcnJl Y3RlZCBVUkwgaXMsIGJlZm9yZSBtYWtpbmcgdGhlIHNhZmUgcmVxdWVzdC4NCg0KDQoNCg0KSG93 ZXZlciwgd2hlbiBJIHVzZSB0aGUgU3lzdGVtLlVyaSBjbGFzcyB0byBwYXJzZSBzb21lIHRleHQg dGhhdCBJIGZpbmQgaW4gYSBIVFRQIHJlc3BvbnNlIG9yIGNvbmZpZ3VyYXRpb24gZmlsZSwgaXQg d291bGQgcmVhbGx5IGNvbmNlcm4gbWUgaWYgdGhlIHBhcnNlciBzdGFydGVkIG1ha2luZyBzaWdu aWZpY2FudCBhc3N1bXB0aW9ucyBhYm91dCBob3cgdG8gZ2VuZXJhdGUgdmFsaWQgVVJMcyBmcm9t IHRleHQgdGhhdCBkb2VzbuKAmXQgY29uZm9ybSB0byB0aGUgc3ludGF4IG9mIFJGQyAzOTg2Lg0K DQoNCg0KDQpJIHdvdWxkIGJlIHJlYWxseSBpbnRlcmVzdGVkIGluIHNlZWluZyB0aGUgZGV2ZWxv cG1lbnQgb2YgYSBzcGVjaWZpY2F0aW9uIHRoYXQgZGVzY3JpYmVzIHRoZSBvcHRpbXVtIHdheSBv ZiBjb252ZXJ0aW5nIGEgc3RyaW5nIHRoYXQgZG9lc24ndCBjb25mb3JtIHRvIFJGQyAzOTg2IHN5 bnRheCBpbnRvIG9uZSB0aGF0IGRvZXMuICBUaGF0IEkgY2FuIGdldCBiZWhpbmQuICBDaGFuZ2lu ZyAuTkVUJ3MgU3lzdGVtLlVyaSB0byBtYWtlIGJlc3QgZ3Vlc3NlcywgSSBjYW4ndC4NCg0KDQoN Cg0KRGFycmVs --_DE553726-AC86-491D-99F0-0C7C09D63C16_ Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" CjxodG1sPgo8aGVhZD4KPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJXaW5kb3dzIE1h aWwgMTcuNS45NjAwLjIwNjg5Ij4KPHN0eWxlPjwhLS0KaHRtbCB7CmZvbnQtZmFtaWx5OiJDb2xv ciBFbW9qaSIsICJDYWxpYnJpIiwgIlNlZ29lIFVJIiwgIk1laXJ5byIsICJNaWNyb3NvZnQgWWFI ZWkgVUkiLCAiTWljcm9zb2Z0IEpoZW5nSGVpIFVJIiwgIk1hbGd1biBHb3RoaWMiLCAic2Fucy1z ZXJpZiI7Cn0KLS0+PC9zdHlsZT48c3R5bGUgZGF0YS1leHRlcm5hbHN0eWxlPSJ0cnVlIj48IS0t CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGggewptYXJnaW4tdG9wOjBpbjsKbWFyZ2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTow aW47Cm1hcmdpbi1sZWZ0Oi41aW47Cm1hcmdpbi1ib3R0b206LjAwMDFwdDsKfQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsIHsKbWFyZ2luOjBpbjsKbWFyZ2luLWJvdHRv bTouMDAwMXB0Owp9CnAuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgbGkuTXNvTGlzdFBhcmFn cmFwaEN4U3BGaXJzdCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIApwLk1zb0xpc3RQ YXJhZ3JhcGhDeFNwTWlkZGxlLCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCAKcC5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QsIGxp Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCB7 Cm1hcmdpbi10b3A6MGluOwptYXJnaW4tcmlnaHQ6MGluOwptYXJnaW4tYm90dG9tOjBpbjsKbWFy Z2luLWxlZnQ6LjVpbjsKbWFyZ2luLWJvdHRvbTouMDAwMXB0OwpsaW5lLWhlaWdodDoxMTUlOwp9 Ci0tPjwvc3R5bGU+PC9oZWFkPgo8Ym9keSBkaXI9Imx0ciI+CjxkaXYgZGF0YS1leHRlcm5hbHN0 eWxlPSJmYWxzZSIgZGlyPSJsdHIiIHN0eWxlPSJmb250LWZhbWlseTogJ0NhbGlicmknLCAnU2Vn b2UgVUknLCAnTWVpcnlvJywgJ01pY3Jvc29mdCBZYUhlaSBVSScsICdNaWNyb3NvZnQgSmhlbmdI ZWkgVUknLCAnTWFsZ3VuIEdvdGhpYycsICdzYW5zLXNlcmlmJztmb250LXNpemU6MTJwdDsiPgo8 ZGl2PldoYXQgcmVhbGx5IGNvbmNlcm5zIG1lIGFib3V0IHRoZSBhcHBhcmVudCBvYmplY3RpdmUg b2YgbWFraW5nIGFsbCBVUkwgcGFyc2VycyBwcm9kdWNlIGlkZW50aWNhbCByZXN1bHRzIGZyb20g dGhlIHNldCBvZiB0ZXN0cyBwcm9kdWNlZCBieSBXaGF0d2csIGlzIHRoYXQgaXQgc2VlbXMgdG8g aWdub3JlIHRoZSBmYWN0IHRoYXQgVVJMcyBhcmUgY3JlYXRlZCBhbmQgY29uc3VtZWQgaW4gdmVy eSBkaWZmZXJlbnQgY29udGV4dHMuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5XaGVuJm5ic3A7 dGV4dCZuYnNwO2lzIGVudGVyZWQgaW4gdGhlIGFkZHJlc3MgYmFyIG9mIGEgd2ViIGJyb3dzZXIg YW5kIGl0IGlzIHBhcnNlZCBhcyBhIFVSTCwgdGhlbiBJIHVuZGVyc3RhbmQgdGhlIGRlc2lyZSB0 byBiZSBhcyB0b2xlcmFudCBhcyBwb3NzaWJsZSBvZiBlcnJvcnMuJm5ic3A7IEkgc2VlIG1pbmlt YWwgZGFuZ2VyJm5ic3A7aW4gbWFraW5nIGFuIGVkdWNhdGVkIGd1ZXNzIGFzIHRvIHdoYXQgdGhl IHVzZXIgaW50ZW5kZWQgYmVjYXVzZSB0aGUgYnJvd3NlciB3aWxsIGxpa2VseSBjb3JyZWN0IHRo ZSBlcnJvciBhbmQgc2hvdyB0aGUgdXNlciB3aGF0IHRoZSBjb3JyZWN0ZWQgVVJMIGlzLCBiZWZv cmUgbWFraW5nIHRoZSBzYWZlIHJlcXVlc3QuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Ib3dl dmVyLCB3aGVuIEkgdXNlIHRoZSBTeXN0ZW0uVXJpIGNsYXNzIHRvIHBhcnNlIHNvbWUgdGV4dCB0 aGF0IEkmbmJzcDtmaW5kIGluIGEgSFRUUCByZXNwb25zZSBvciBjb25maWd1cmF0aW9uIGZpbGUs IGl0IHdvdWxkIHJlYWxseSBjb25jZXJuIG1lIGlmIHRoZSBwYXJzZXIgc3RhcnRlZCBtYWtpbmcg c2lnbmlmaWNhbnQgYXNzdW1wdGlvbnMgYWJvdXQgaG93Jm5ic3A7dG8gZ2VuZXJhdGUgdmFsaWQg VVJMcyBmcm9tIHRleHQgdGhhdCBkb2VzbuKAmXQgY29uZm9ybSB0byB0aGUgc3ludGF4IG9mIFJG QyAzOTg2LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSB3b3VsZCBiZSByZWFsbHkgaW50ZXJl c3RlZCBpbiBzZWVpbmcgdGhlIGRldmVsb3BtZW50IG9mIGEgc3BlY2lmaWNhdGlvbiB0aGF0IGRl c2NyaWJlcyB0aGUgb3B0aW11bSB3YXkgb2YgY29udmVydGluZyBhIHN0cmluZyB0aGF0IGRvZXNu J3QgY29uZm9ybSB0byBSRkMgMzk4NiBzeW50YXggaW50byBvbmUgdGhhdCBkb2VzLiZuYnNwOyBU aGF0IEkgY2FuIGdldCBiZWhpbmQuJm5ic3A7IENoYW5naW5nIC5ORVQncyBTeXN0ZW0uVXJpIHRv IG1ha2UgYmVzdCBndWVzc2VzLCBJIGNhbid0LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+RGFy cmVsJm5ic3A7IDxicj48L2Rpdj48ZGl2IGRhdGEtc2lnbmF0dXJlYmxvY2s9InRydWUiPjxkaXY+ PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2PgoKCjwvZGl2Pgo8L2JvZHk+CjwvaHRtbD4K --_DE553726-AC86-491D-99F0-0C7C09D63C16_-- From nobody Sun Jan 11 13:54:54 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153D01A1A86 for ; Sun, 11 Jan 2015 13:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U45Neh96H76L for ; Sun, 11 Jan 2015 13:54:51 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 863B91A0BE8 for ; Sun, 11 Jan 2015 13:54:51 -0800 (PST) Received: (qmail 11258 invoked from network); 11 Jan 2015 21:54:50 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 11 Jan 2015 21:54:50 -0000 Date: 11 Jan 2015 21:54:28 -0000 Message-ID: <20150111215428.13470.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 21:54:53 -0000 >how can the sender be sure that the DSN he/she receives (when he/she ask >one sending a message) really comes from the real recipient MTA, thus the >message was really delivered? That's easy: you can't, but it doesn't matter. As as too often the case, the security considerations section of 3464 didn't consider the realities of the modern Internet. Since most DSNs are real responses to fake spam, most of the work is picking out the DSNs that are responses to real messages. Mailing list software spends enormous effort on heuristics to do this, which boil down to looking for some distinctive characteristic of the real mail you send in the message enclosed in the bounce. Next, you have no idea where a message might legitimately go. Most mail services handle mail for anywhere from dozens to tens of thousands of domains, and mail is routinely forwarded from one system to another, e.g. mail to uucp@computer.org goes to me, so a DSN would come from my host miucha.iecc.com. In fact, anyone with access to a copy of a message can provoke a 100% genuine DSN merely by remailing it to a bad address. It is common for a message to be both delivered and forwarded, so if you get a DSN, it's quite possible that the message was also delivered successfully somewhere else. As Ned noted, there is no way to tell what MTA is supposed to be sending DSNs for what mail domains. My tiny system handles mail for a couple of dozen domains, none of which have any obvious connection to me other than the MX records. It is not rare for a system to handle mail for a domain and not know it, e.g., someone stops paying for hosted mail, but doesn't change the MX. In that case, the DSN would say something like "not an open relay" or "use your own mail system". Fortunately, fake DSNs have never been a problem other than the ones from spam bounce storms, which don't seem to be what you're asking about. What problem are we supposed to solve here? R's, John From nobody Sun Jan 11 14:11:32 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8161A1A3B; Sun, 11 Jan 2015 14:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 032nKCohgF8t; Sun, 11 Jan 2015 14:11:22 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 F3CD81A0396; Sun, 11 Jan 2015 14:11:21 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1333222E200; Sun, 11 Jan 2015 17:11:19 -0500 (EST) Message-ID: <54B2F4C3.5020008@seantek.com> Date: Sun, 11 Jan 2015 14:10:11 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , Julian Reschke , Mark Nottingham References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> In-Reply-To: <54B2A894.4020201@intertwingly.net> Content-Type: multipart/alternative; boundary="------------010706050003040906040904" Archived-At: Cc: "pkix@ietf.org" , apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 22:11:25 -0000 This is a multi-part message in MIME format. --------------010706050003040906040904 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable [Adding pkix@] On the two intertwined points: On 1/11/2015 8:28 AM, Julian Reschke wrote: > On 2015-01-11 17:19, Sam Ruby wrote: >> ... >>> Now suffering from information overflow. >>> >>> We were discussing RFC 3986. Which *ASCII* characters that are=20 >>> currently >>> forbidden in fragment identifiers do you want to allow? >> >> We seem to be in a loop. >> >> To you, RFC 3986 (including potential errata and/or bis work) implies >> ASCII. >> >> I point out that that restriction does not seem to make sense for >> fragments. > > Actually, you did not. Instead you pointed to lots of material=20 > somewhere else that I didn't want to parse just to find out what=20 > you're proposing. > >> You return back to asking about ASCII. > > Because that's what RFC 3986 is concerned with. > >> To help break this loop, permit me to turn this question around. >> Restricting the scope of the conversation to fragments, why do you >> believe it makes sense to limit such to ASCII only? What problems do >> non-ASCII characters in fragments cause? > > I fail to see how fragments are special here compared to, say, the path= =2E > > I fully agree that work on what we used to call IRIs is something that = > needs to be done. However right now I'm trying to figure out what's=20 > wrong with RFC *3986*. > > I hear you saying that URIs should allow non-ASCII characters in=20 > certain places. This may break code where these characters are put on=20 > the wire (such as HTTP) or stored in places that do not allow=20 > non-ASCII characters (say, a database column). > > The fact that it's hard to extend the URI character repertoire beyond=20 > ASCII is why the IETF attempted to do it in a separate spec/construct. = > I'm not convinced that the situation has changed sufficiently to=20 > invalidate that approach. On 1/11/2015 8:45 AM, Sam Ruby wrote: > On 01/11/2015 11:29 AM, Julian Reschke wrote: >> On 2015-01-11 17:25, Mark Nottingham wrote: >>> I and others have brought that up. What=E2=80=99s interesting is that= they say >>> it=E2=80=99s reasonably interoperable with deployed implementations. >>> >>> Cheers, >>> ... >> >> Let me guess: "deployed implementations" =3D=3D "what current browsers= do". > > Your sarcasm is not appreciated. > > I encourage you to actually look at test results: > > https://url.spec.whatwg.org/interop/test-results/7b83ef3682 *** I fully agree with Julian on the matter of US-ASCII for URIs. URIs (RFC=20 3986) are only made of US-ASCII characters. If someone wishes to extend URIs (as opposed to IRIs or whatever) to=20 include non-US-ASCII characters, that's a problem for web browsers and=20 all other Internet software alike. This goes exactly to my point about=20 protocol slots. Certificates, CRLs, and other security objects are just as fundamentally = a part of the Web (and web browser) infrastructure as HTML. In=20 X.509/PKIX security objects, the GeneralName uniformResourceIdentifier=20 construct is US-ASCII only (IA5String). If you extend "URIs" to be=20 beyond US-ASCII, RFC 5280 has to be updated...and all the security=20 libraries that depend upon it. Just because HTML(5) can be served as=20 UTF-8 or use & encoding or whatever, doesn't make the problem go away= =2E Does the URL Interop test-results explicitly test for certificates? I=20 suggest attempting to put some non-US-ASCII characters in a GeneralName=20 protocol slot (say, for revocation) and see what happens. HTML 4.01 is at least consistent in saying (for its time) that hrefs and = other things are URIs. For interoperable behavior, use US-ASCII=20 characters only and stick with % encoding. The security angle brings up another problem: the interoperable=20 transcription of URIs across systems. The ASCII range is a limited=20 repertoire, so it is easy to write it out unambiguously on paper,=20 display it on a TV screen, say it over the radio or a public service=20 announcement, or memorize it on your smartphone, in order to type it=20 into your web browser, the command-line, or any other system of choice. If you allow the enormous (and ever-expanding) range of Unicode=20 characters in "URIs", all of those use cases become fundamentally=20 ambiguous, inviting homograph attacks. Which smiley face out of nearly a = hundred smiley emoji do you mean when you say "http://foo.com/=F0=9F=98=8B= " ?? How=20 about an URI containing "=E1=BF=97" (U+1FD7 GREEK SMALL LETTER IOTA WITH = DIALYTIKA AND PERISPOMENI)--what composition or decomposition mode? What = if the combining accent mark code points are in a different order? *** I have empathy for what Sam/the W3C wants, since the HTML protocol slots = basically beg to be filled with Unicode strings like (instead of ). But maybe the more interoperable approach is to define a format and=20 mechanism (e.g., IRIs, or something like IRIs v2) to map /from ///the=20 Unicode-capable protocol slots, /to/ the well-standardized RFC 3986 URI=20 format. My 2=C2=A2. Sean --------------010706050003040906040904 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
[Adding pkix@]
On the two intertwined points:

On 1/11/2015 8:28 AM, Julian Reschke wrote:
On 2015-01-11 17:19, Sam Ruby wrote:
...
Now suffering from information overflow.

We were discussing RFC 3986. Which *ASCII* characters that are currently
forbidden in fragment identifiers do you want to allow?

We seem to be in a loop.

To you, RFC 3986 (including potential errata and/or bis work) implies
ASCII.

I point out that that restriction does not seem to make sense for
fragments.

Actually, you did not. Instead you pointed to lots of material somewhere else that I didn't want to parse just to find out what you're proposing.

You return back to asking about ASCII.

Because that's what RFC 3986 is concerned with.

To help break this loop, permit me to turn this question around.
Restricting the scope of the conversation to fragments, why do you
believe it makes sense to limit such to ASCII only?  What problems do
non-ASCII characters in fragments cause?

I fail to see how fragments are special here compared to, say, the path.

I fully agree that work on what we used to call IRIs is something that needs to be done. However right now I'm trying to figure out what's wrong with RFC *3986*.

I hear you saying that URIs should allow non-ASCII characters in certain places. This may break code where these characters are put on the wire (such as HTTP) or stored in places that do not allow non-ASCII characters (say, a database column).

The fact that it's hard to extend the URI character repertoire beyond ASCII is why the IETF attempted to do it in a separate spec/construct. I'm not convinced that the situation has changed sufficiently to invalidate that approach.
On 1/11/2015 8:45 AM, Sam Ruby wrote:
On 01/11/2015 11:29 AM, Julian Reschke wrote:
On 2015-01-11 17:25, Mark Nottingham wrote:
I and others have brought that up. What’s interesting is that they say
it’s reasonably interoperable with deployed implementations.

Cheers,
...

Let me guess: "deployed implementations" == "what current browsers do".

Your sarcasm is not appreciated.

I encourage you to actually look at test results:

https://url.spec.whatwg.org/interop/test-results/7b83ef3682

***

I fully agree with Julian on the matter of US-ASCII for URIs. URIs (RFC 3986) are only made of US-ASCII characters.

If someone wishes to extend URIs (as opposed to IRIs or whatever) to include non-US-ASCII characters, that's a problem for web browsers and all other Internet software alike. This goes exactly to my point about protocol slots.

Certificates, CRLs, and other security objects are just as fundamentally a part of the Web (and web browser) infrastructure as HTML. In X.509/PKIX security objects, the GeneralName uniformResourceIdentifier construct is US-ASCII only (IA5String). If you extend "URIs" to be beyond US-ASCII, RFC 5280 has to be updated...and all the security libraries that depend upon it. Just because HTML(5) can be served as UTF-8 or use &amp; encoding or whatever, doesn't make the problem go away.

Does the URL Interop test-results explicitly test for certificates? I suggest attempting to put some non-US-ASCII characters in a GeneralName protocol slot (say, for revocation) and see what happens.

HTML 4.01 is at least consistent in saying (for its time) that hrefs and other things are URIs. For interoperable behavior, use US-ASCII characters only and stick with % encoding.

The security angle brings up another problem: the interoperable transcription of URIs across systems. The ASCII range is a limited repertoire, so it is easy to write it out unambiguously on paper, display it on a TV screen, say it over the radio or a public service announcement, or memorize it on your smartphone, in order to type it into your web browser, the command-line, or any other system of choice.

If you allow the enormous (and ever-expanding) range of Unicode characters in "URIs", all of those use cases become fundamentally ambiguous, inviting homograph attacks. Which smiley face out of nearly a hundred smiley emoji do you mean when you say "http://foo.com/😋" ?? How about an URI containing "ῗ" (U+1FD7 GREEK SMALL LETTER IOTA WITH DIALYTIKA AND PERISPOMENI)--what composition or decomposition mode? What if the combining accent mark code points are in a different order?

***
I have empathy for what Sam/the W3C wants, since the HTML protocol slots basically beg to be filled with Unicode strings like <a href="http://zh.wikipedia.org/wiki/巴泰勒米·波岡達"> (instead of <a href="http://zh.wikipedia.org/wiki/%E5%B7%B4%E6%B3%B0%E5%8B%92%E7%B1%B3%C2%B7%E6%B3%A2%E5%B2%A1%E9%81%94">).

But maybe the more interoperable approach is to define a format and mechanism (e.g., IRIs, or something like IRIs v2) to map from the Unicode-capable protocol slots, to the well-standardized RFC 3986 URI format.

My 2¢.

Sean
--------------010706050003040906040904-- From nobody Sun Jan 11 14:12:09 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD1F1A8820 for ; Sun, 11 Jan 2015 14:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zb4CGarkHA5O for ; Sun, 11 Jan 2015 14:11:57 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.227]) by ietfa.amsl.com (Postfix) with ESMTP id 4670E1A8824 for ; Sun, 11 Jan 2015 14:11:53 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:5054] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 5B/3D-08411-825F2B45; Sun, 11 Jan 2015 22:11:52 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 9101F140B53; Sun, 11 Jan 2015 17:11:52 -0500 (EST) Message-ID: <54B2F527.7040404@intertwingly.net> Date: Sun, 11 Jan 2015 17:11:51 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Julian Reschke References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2ABA8.6030205@gmx.de> <54B2C6FA.80802@intertwingly.net> <54B2EE08.9040705@gmx.de> In-Reply-To: <54B2EE08.9040705@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 22:11:59 -0000 On 01/11/2015 04:41 PM, Julian Reschke wrote: > On 2015-01-11 19:54, Sam Ruby wrote: >> ... >> At some point, I would like to discuss what characters should be allowed >> in a fragment, and would like RFC 3986 either to match the set we come >> up with, or for RFC 3986 to be obsoleted by a specification that does. >> >> I've been proceeding by testing actual implementations and actually >> talking to at least two authors of RFC 3986. And, trust me, I plan to >> have conversations with the third author. >> >> Each time I try to have this discussion, you keep returning to what RFC >> 3986 currently says as of this moment. >> ... > > I keep returning to URIs as things consisting of ASCII code points. Indeed you do. :-( > If you want to talk about URI-like identifiers that can contain > non-ASCII characters, we'll need to discuss RFC *3987*. As far as I can > recall, there's more or less agreement that this needs to happen, but > that's IMHO a different conversation than the one about RFC 3986. Let me compare what you suggest should happen with what Roy Fielding suggests should happen. For whatever reason, Roy's post didn't make the web archive, but my reply did, so I will Roy quote from: https://lists.w3.org/Archives/Public/public-ietf-w3c/2014Dec/0088.html >>> The problem with RFC3987 was that it tried to define a new >>> addressing format instead of simply defining an arbitrary >>> reference and how to get from there to an interoperable URI. It >>> did not work because it wasn't written to handle arbitrary input >>> and could not keep up with changes in IDNA. and > This does not mean there isn't value in coming up with a consistent > reference parsing model for HTML that reflects the browser > environment and results in a consistent URL DOM and address display. > It simply doesn't change what is in RFC3986, nor does it escape the > fact that a browser is still dependent on RFC3986 to produce a valid > URI out of whatever it happens to parse when it eventually chooses to > use that URI in an IETF protocol like HTTP. I'd like to explore what Roy is suggesting: layering URLs on URIs, without going through a URL layered on IRI layered on URI approach. Doing so may require changes to both the definition of URLs and URIs. In particular, I'd like to see how close we can come to a goal where the output of URL parsing followed by URL stringification is always a valid URI. There is no question that a change to the "ASCII-ness" of schemes is clearly a non-starter. But I would hope that we could discuss whether a change to the "ASCII-ness" of fragments is a possibility. In particular, I don't believe that there is any reason why a URL parser (in a browser or elsewhere) needs to percent encode fragments. It may come to pass that Roy is the only person who shares the goals that he described. In which case, the end result will be an appendix to the URL standard which describes the real world use cases that RFC 3986 does not address which prevent a proper layering. Additionally, there would be a description of what the set of outputs from a URL parse/stringification process does produce, i.e., a description of what RFC 3986 should have said. - Sam Ruby From nobody Sun Jan 11 14:24:12 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFB81A8746 for ; Sun, 11 Jan 2015 14:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbz3ZM43btaF for ; Sun, 11 Jan 2015 14:24:08 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.227]) by ietfa.amsl.com (Postfix) with ESMTP id C902D1A1AF5 for ; Sun, 11 Jan 2015 14:24:07 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:5734] helo=rubix) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 92/72-23646-708F2B45; Sun, 11 Jan 2015 22:24:07 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 74802140C4E; Sun, 11 Jan 2015 17:24:07 -0500 (EST) Message-ID: <54B2F806.2090509@intertwingly.net> Date: Sun, 11 Jan 2015 17:24:06 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sean Leonard References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2F4C3.5020008@seantek.com> In-Reply-To: <54B2F4C3.5020008@seantek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: Cc: "pkix@ietf.org" , apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 22:24:11 -0000 On 01/11/2015 05:10 PM, Sean Leonard wrote: > > I fully agree with Julian on the matter of US-ASCII for URIs. URIs (RFC > 3986) are only made of US-ASCII characters. > > If someone wishes to extend URIs (as opposed to IRIs or whatever) to > include non-US-ASCII characters, that's a problem for web browsers and > all other Internet software alike. This goes exactly to my point about > protocol slots. > > Certificates, CRLs, and other security objects are just as fundamentally > a part of the Web (and web browser) infrastructure as HTML. In > X.509/PKIX security objects, the GeneralName uniformResourceIdentifier > construct is US-ASCII only (IA5String). If you extend "URIs" to be > beyond US-ASCII, RFC 5280 has to be updated...and all the security > libraries that depend upon it. Just because HTML(5) can be served as > UTF-8 or use & encoding or whatever, doesn't make the problem go away. > > Does the URL Interop test-results explicitly test for certificates? I > suggest attempting to put some non-US-ASCII characters in a GeneralName > protocol slot (say, for revocation) and see what happens. The topic is character repertoire for fragment identifiers, not schemes. I am not suggesting that we allow non-US-ASCII protocols. I am willing to accept that GeneralName's that are expressed in the form of a URI must be ASCII-only. The next question is: are all possible URIs valid GeneralNames? Here are two examples: data:image/gif;base64,R0lGODlhyAAiALM...DfD0QAADs= https://www.ietf.org/#related Are both valid GeneralNames? If not, why not? - Sam Ruby From nobody Sun Jan 11 14:38:56 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5A71A1A9A for ; Sun, 11 Jan 2015 14:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQlj4e1fo5Fv for ; Sun, 11 Jan 2015 14:38:52 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 B7F3E1A1AFA for ; Sun, 11 Jan 2015 14:38:51 -0800 (PST) Received: from [192.168.2.175] ([84.187.47.145]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0McEDD-1YSnDc1e6x-00JWX2; Sun, 11 Jan 2015 23:38:47 +0100 Message-ID: <54B2FB76.6040208@gmx.de> Date: Sun, 11 Jan 2015 23:38:46 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2ABA8.6030205@gmx.de> <54B2C6FA.80802@intertwingly.net> <54B2EE08.9040705@gmx.de> <54B2F527.7040404@intertwingly.net> In-Reply-To: <54B2F527.7040404@intertwingly.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:pAScAsGjhgQHjJ550VbEgb29pmMpM3wi5EzVRd1V6xhTJr3e8uF RVucAIjW9wYirem4fbR7uTT22MupiM3/Z9kYkyDh5IXPvtvs/0Sq7+Ca1owagPUntmfIGfH /Cv1L7BODc7gsSje9BUKfW+R75fLnEmnPKSINi4WKQyrCa+7cDnyxmlV/1QQEoFGKp7bbXF 3EXUsnQzX786gUzrVWApA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 22:38:55 -0000 On 2015-01-11 23:11, Sam Ruby wrote: > On 01/11/2015 04:41 PM, Julian Reschke wrote: >> On 2015-01-11 19:54, Sam Ruby wrote: >>> ... >>> At some point, I would like to discuss what characters should be allowed >>> in a fragment, and would like RFC 3986 either to match the set we come >>> up with, or for RFC 3986 to be obsoleted by a specification that does. >>> >>> I've been proceeding by testing actual implementations and actually >>> talking to at least two authors of RFC 3986. And, trust me, I plan to >>> have conversations with the third author. >>> >>> Each time I try to have this discussion, you keep returning to what RFC >>> 3986 currently says as of this moment. >>> ... >> >> I keep returning to URIs as things consisting of ASCII code points. > > Indeed you do. :-( > >> If you want to talk about URI-like identifiers that can contain >> non-ASCII characters, we'll need to discuss RFC *3987*. As far as I can >> recall, there's more or less agreement that this needs to happen, but >> that's IMHO a different conversation than the one about RFC 3986. > > Let me compare what you suggest should happen with what Roy Fielding > suggests should happen. For whatever reason, Roy's post didn't make the > web archive, but my reply did, so I will Roy quote from: > > https://lists.w3.org/Archives/Public/public-ietf-w3c/2014Dec/0088.html > > >>> The problem with RFC3987 was that it tried to define a new > >>> addressing format instead of simply defining an arbitrary > >>> reference and how to get from there to an interoperable URI. It > >>> did not work because it wasn't written to handle arbitrary input > >>> and could not keep up with changes in IDNA. > > and > > > This does not mean there isn't value in coming up with a consistent > > reference parsing model for HTML that reflects the browser > > environment and results in a consistent URL DOM and address display. > > It simply doesn't change what is in RFC3986, nor does it escape the > > fact that a browser is still dependent on RFC3986 to produce a valid > > URI out of whatever it happens to parse when it eventually chooses to > > use that URI in an IETF protocol like HTTP. > > I'd like to explore what Roy is suggesting: layering URLs on URIs, > without going through a URL layered on IRI layered on URI approach. > Doing so may require changes to both the definition of URLs and URIs. I'm totally fine with what Roy suggests. The point I was trying to make was not that we necessarily need to touch RFC 3987, but whatever introduces non-ASCII into identifiers ought to happen in something layered on top of RFC 3986. > In particular, I'd like to see how close we can come to a goal where the > output of URL parsing followed by URL stringification is always a valid > URI. > > There is no question that a change to the "ASCII-ness" of schemes is > clearly a non-starter. But I would hope that we could discuss whether a > change to the "ASCII-ness" of fragments is a possibility. In > particular, I don't believe that there is any reason why a URL parser > (in a browser or elsewhere) needs to percent encode fragments. a) I still do not see how fragments are special in general. They *are* special in the context of browsers and HTTP, but that doesn't mean we can generalize from that. b) The *parser* never needs to percent encode anything. A *sender* would need to percent-encode (*) if fragments stay the way thy are. Q: how is that a problem in practice? ((*) Maybe it's time to coin a term for the utf-8-encode-then-uri-percent-escape thingy) > It may come to pass that Roy is the only person who shares the goals > that he described. In which case, the end result will be an appendix to I believe I share these goals. > the URL standard which describes the real world use cases that RFC 3986 > does not address which prevent a proper layering. Additionally, there > would be a description of what the set of outputs from a URL > parse/stringification process does produce, i.e., a description of what > RFC 3986 should have said. Which brings us back to the question what exactly is wrong with RFC 3986. So far I heard "what it says about IDNA". What else? Best regards, Julian From nobody Sun Jan 11 14:41:04 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E638E1A1AFA for ; Sun, 11 Jan 2015 14:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4r_I16uCThf for ; Sun, 11 Jan 2015 14:41:00 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A9291A1A9A for ; Sun, 11 Jan 2015 14:41:00 -0800 (PST) Received: internal info suppressed Date: Sun, 11 Jan 2015 23:40:55 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.local To: John Levine In-Reply-To: <20150111215428.13470.qmail@ary.lan> Message-ID: References: <20150111215428.13470.qmail@ary.lan> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1421016056; bh=VSteejbtKALGgad2MYzxt6LqXJhMQV3DJHBgWxGW3I4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XsJxidIf22FFyHqUgP71whk3Jh1dfWIbLDTCO8haQoshhnkqw8q2HciBHDOQANKtQ NxdXCVsDqGjVUaeiS5wnjpRBCA0zZYrwl2WVIALYKtIa2SPre+iVlcHxJKYBzlNECi QbmbZvdvYLvYWvqF5W6VvTJr7Sv492AprE/sK6M4= Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 22:41:03 -0000 On Sun, 11 Jan 2015, John Levine wrote: >> how can the sender be sure that the DSN he/she receives (when he/she ask >> one sending a message) really comes from the real recipient MTA, thus the >> message was really delivered? > > That's easy: you can't, but it doesn't matter. As as too often the > case, the security considerations section of 3464 didn't consider the > realities of the modern Internet. > > Since most DSNs are real responses to fake spam, most of the work is > picking out the DSNs that are responses to real messages. Mailing > list software spends enormous effort on heuristics to do this, which > boil down to looking for some distinctive characteristic of the real > mail you send in the message enclosed in the bounce. > > Next, you have no idea where a message might legitimately go. Most > mail services handle mail for anywhere from dozens to tens of > thousands of domains, and mail is routinely forwarded from one system > to another, e.g. mail to uucp@computer.org goes to me, so a DSN would > come from my host miucha.iecc.com. In fact, anyone with access to a > copy of a message can provoke a 100% genuine DSN merely by remailing > it to a bad address. It is common for a message to be both delivered > and forwarded, so if you get a DSN, it's quite possible that the > message was also delivered successfully somewhere else. > > As Ned noted, there is no way to tell what MTA is supposed to be > sending DSNs for what mail domains. My tiny system handles mail for a > couple of dozen domains, none of which have any obvious connection to > me other than the MX records. It is not rare for a system to handle > mail for a domain and not know it, e.g., someone stops paying for > hosted mail, but doesn't change the MX. In that case, the DSN would > say something like "not an open relay" or "use your own mail system". > > Fortunately, fake DSNs have never been a problem other than the ones > from spam bounce storms, which don't seem to be what you're asking > about. What problem are we supposed to solve here? As Ned pointed out, in a "regulated (virtual) organisation" you can impose further administrative rules to solve most of the problems you correctly describe above... and this can also have quite strong implications leading to nearly (or completely) "legally valid" DSNs with strong value. My guess is that the question which came to me came with in mind such a regulated environment, whaere you can fix many things... and also the services with a third party notary service which exists prove this can be done. ... but I just tried to extend the question of "(positive) DSNs non repudiation" to the open Internet, trying to see if we have, if any, possible mechanisms to do so, without enforcing additional rules which you can apply only within a closed regulated environment. It is true... RFC3464 Security Consideration sections is quite in line with "ha ok... I also have to write this bothering security sections, let's write something....", thus useless in real life... but for example the idea of forcing also the ENVID request may be interesting (I've not yet tried to examin it in full detuils, but maybe Arne can provide a quicker transaction schema to explain it). Another consideration: even if a mail server handles thousands of domains, it is true that a sender can get a list of mail server associated to any domain (A, AAAA, or MX rcords) and just check that the DSN comes with a valid certificate of one of them. It is also true that "forwarding" is common practice (my Gmail address just forwards to my official address... sorry Google... no indexing on my messages), but if the mail server associated to the domain the message is sent supports correctly DSNs, for the sender it does not matter if a message is then forwarded somewhere else: I asked a deliery to THAT mailbox, and indeed it reached it... if the message then is forwarded elsewhere and get lost... it is the mailbox owner fault... if he did not received it... as the message was officially delivered where it was suppoused to go. So, the problems I'm trying to solve (or to see if there is workable solution) is a resonable non-repudiation mechanism for DSNs in the open Internet using existing specifications, without imposing additional rules which only a closed regulated environment can force. This is of course a wider topic that the one which came to me from some users... but as said, their "virtual organisation problem" can be solved imposing some rules and restrictions... and thus it is not so interesting. It may be that we just cannot have a "reasonable" solution for the real open Internet... but as I'm not sure and a solution may exist, I started this (sunday) brainstorming... :-) all the best! > > R's, > John > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Sun Jan 11 14:46:13 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26041A1A9A; Sun, 11 Jan 2015 14:46:09 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYw6FY95jvGk; Sun, 11 Jan 2015 14:46:07 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 C32F21A882B; Sun, 11 Jan 2015 14:45:45 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D484122E25F; Sun, 11 Jan 2015 17:45:38 -0500 (EST) Message-ID: <54B2FCCE.4000304@seantek.com> Date: Sun, 11 Jan 2015 14:44:30 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2F4C3.5020008@seantek.com> <54B2F806.2090509@intertwingly. net> In-Reply-To: <54B2F806.2090509@intertwingly.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "pkix@ietf.org" , apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 22:46:10 -0000 On 1/11/2015 2:24 PM, Sam Ruby wrote: > On 01/11/2015 05:10 PM, Sean Leonard wrote: >> >> I fully agree with Julian on the matter of US-ASCII for URIs. URIs (RFC >> 3986) are only made of US-ASCII characters. >> >> If someone wishes to extend URIs (as opposed to IRIs or whatever) to >> include non-US-ASCII characters, that's a problem for web browsers and >> all other Internet software alike. This goes exactly to my point about >> protocol slots. >> >> Certificates, CRLs, and other security objects are just as fundamentally >> a part of the Web (and web browser) infrastructure as HTML. In >> X.509/PKIX security objects, the GeneralName uniformResourceIdentifier >> construct is US-ASCII only (IA5String). If you extend "URIs" to be >> beyond US-ASCII, RFC 5280 has to be updated...and all the security >> libraries that depend upon it. Just because HTML(5) can be served as >> UTF-8 or use & encoding or whatever, doesn't make the problem go >> away. >> >> Does the URL Interop test-results explicitly test for certificates? I >> suggest attempting to put some non-US-ASCII characters in a GeneralName >> protocol slot (say, for revocation) and see what happens. > > The topic is character repertoire for fragment identifiers, not > schemes. I am not suggesting that we allow non-US-ASCII protocols. > > I am willing to accept that GeneralName's that are expressed in the > form of a URI must be ASCII-only. > > The next question is: are all possible URIs valid GeneralNames? > > Here are two examples: > > data:image/gif;base64,R0lGODlhyAAiALM...DfD0QAADs= Yes. Use case: Certificate Image. RFC 6170 (previously RFC 3709). > https://www.ietf.org/#related Yes. Use case: Certification Practice Statement (CPS) Pointer (Certificate Policies, id-qt-cps). Section 4.2.1.4 of RFC 5280. I have seen fragments in there in the wild. Both examples are valid. Note: the examples I provide here are actually examples where the URIs are encoded directly in IA5Strings; there is no GeneralName CHOICE. But the premise still stands. Others with PKIX experience can point to systems/protocols where uniformResourceIdentifier is in use with the appropriate. One offhand example that I was able to find, via a Google search, is the GS1 Certificate Profile Standard v2.0 . That happens to use GeneralName. It's a bit elliptical, and refers to RFC 4043 (which I rarely see), but...it's there. Sean From nobody Sun Jan 11 15:12:33 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB931A09CF for ; Sun, 11 Jan 2015 15:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OzQmLE7kqJy for ; Sun, 11 Jan 2015 15:12:29 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0599A1A1BF6 for ; Sun, 11 Jan 2015 15:12:27 -0800 (PST) Received: (qmail 17948 invoked from network); 11 Jan 2015 23:12:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=461b.54b30359.k1501; bh=pPf6Ymlc/U/HaCQYfbv0M65D/p+rqKynZyZBaFBEqw4=; b=AZ0DXUH3igN4MfwPVB1i7v7txc5Pbft3D9GKZj7/f5horx2N7w+JSGEJnsxBoEX92ZXMRNQGFf/OX+90FNyGGDajkNkUzPaYV4dTQUW2/eM8WI3i526t++9qLHYh8GTDfw2yF48vyqXnYt2/UmwtRaK4jLde6Ukkzq9IQwX2oQW8Bxzg7uZyDBPF0M+TE+FNmlHYDYNxzfBf+vR3VGMufkGkoKN/d7OFzmEzoWkeZIHtTVNtc69lpFLCgTu7yr0a DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=461b.54b30359.k1501; bh=pPf6Ymlc/U/HaCQYfbv0M65D/p+rqKynZyZBaFBEqw4=; b=M55wmhRmjs/BicHf0CnprmSdxHY9HfEKPhpaXqwn4WcDKL5DMfPnzfbmSZihFcaPz1RH995KRSIBszWvtYfW5e1ldX6+6eXFEpLBWrpspmejsHCeFlJfPMVvg+pYi0SqXP20QEgXRw6bbpQKZKhQg8XXuRH5s38HzV+O3/czFM20C6aF70UoBDrvDyYStXs18zJlKKRj/TXTeiGyOlxe4Al2wK9o7uCQxv9NgZEy6jqYuEUTEKcnmYjOSMlWkclk Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 11 Jan 2015 23:12:25 -0000 Date: 11 Jan 2015 18:12:25 -0500 Message-ID: From: "John R Levine" To: "Claudio Allocchio" In-Reply-To: References: <20150111215428.13470.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 23:12:31 -0000 > As Ned pointed out, in a "regulated (virtual) organisation" you can impose > further administrative rules to solve most of the problems you correctly > describe above... and this can also have quite strong implications leading to > nearly (or completely) "legally valid" DSNs with strong value. Oh, sure. Within a private system with its own rules, you can do this easily. Delivery reports within a single Exchange server are quite reliable, for example. > Another consideration: even if a mail server handles thousands of domains, it > is true that a sender can get a list of mail server associated to any domain > (A, AAAA, or MX rcords) and just check that the DSN comes with a valid > certificate of one of them. Nope. Mail servers have no idea what name you used to find them, and it is very common for inbound and outbound mail servers to be different. My inbound mail server is mail1.iecc.com, but bounces come from miucha.iecc.com. For hosted mail, it's common for customers to use MXes in their own domain that point to the host's mail server. Or see the MX for my client quarteracre.net. > indeed it reached it... if the message then is forwarded elsewhere and get > lost... it is the mailbox owner fault... if he did not received it... as the > message was officially delivered where it was supposed to go. This seems contrary to your previous question about whether a non-technical user could tell if her message was delivered successfully. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sun Jan 11 15:34:34 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27811A1AF0 for ; Sun, 11 Jan 2015 15:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L43EJIysgd48 for ; Sun, 11 Jan 2015 15:34:30 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56ED1A03A5 for ; Sun, 11 Jan 2015 15:34:29 -0800 (PST) Received: internal info suppressed Date: Mon, 12 Jan 2015 00:34:25 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.local To: John R Levine In-Reply-To: Message-ID: References: <20150111215428.13470.qmail@ary.lan> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1421019265; bh=Ex7CdvqvHgA68bjhkQJZx+hR7+7/NclvYcIRIkCUD8k=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=nG0L9zkS7CUtKonocAHdZclJaEgDzacq5olZMNTmNEttm1pZ9TYzp9T/g/wrW50Ia KNBM9qlNH2Se7Pp9skhuUt+cYqAt1d4yJskKrfFHbs9gMaPj4pjnvL1lopIma9hG99 scnZQ6kNpNoxu35O7eahjX45SdlQHy4DIlnIkI7s= Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jan 2015 23:34:33 -0000 >> Another consideration: even if a mail server handles thousands of domains, >> it is true that a sender can get a list of mail server associated to any >> domain (A, AAAA, or MX rcords) and just check that the DSN comes with a >> valid certificate of one of them. > > Nope. Mail servers have no idea what name you used to find them, and it is > very common for inbound and outbound mail servers to be different. My > inbound mail server is mail1.iecc.com, but bounces come from miucha.iecc.com. > For hosted mail, it's common for customers to use MXes in their own domain > that point to the host's mail server. Or see the MX for my client > quarteracre.net. yes, you are right ! >> indeed it reached it... if the message then is forwarded elsewhere and get >> lost... it is the mailbox owner fault... if he did not received it... as >> the message was officially delivered where it was supposed to go. > > This seems contrary to your previous question about whether a non-technical > user could tell if her message was delivered successfully. it was a different consideration indeed :-) I was considering the case where a non technical user send for example a message to me at claudio.allocchio@elettra.eu (which is a valid mailbox I have), and asks for a DSN. The mail server @eletra.eu delivers a positive DSN, but then also forwards the message to me at my real common mailbox @garr.it. The sender knows that the message was delivered to my mailbox @elettra.eu, and this is enough for her because it arrived to the mailbox she intended to reach... if then the forward makes the message disapper in a black hole, it is MY fault... and it is the same situation which happens If I press "delete" on a new message before reading it, if you think to the heuristic... like if I get a snail mail in the mailbox, open the mailbox, and the wind blows away the letter when I'm taking it into the house. :-) (it may indeed happen here in Trieste where 90mph or more gusts are quite common in winter...) best! > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Sun Jan 11 17:12:26 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFAC1A896D; Sun, 11 Jan 2015 17:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ci1abIi6-Y9k; Sun, 11 Jan 2015 17:12:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1651A8866; Sun, 11 Jan 2015 17:12:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> Date: Sun, 11 Jan 2015 17:12:16 -0800 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 01:12:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : The file URI Scheme Author : Matthew Kerwin Filename : draft-ietf-appsawg-file-scheme-00.txt Pages : 16 Date : 2015-01-11 Abstract: This document specifies the "file" Uniform Resource Identifier (URI) scheme, replacing the definition in RFC 1738. It attempts to document current practices, while at the same time defining a common core which is intended to interoperate across the broad spectrum of existing implementations. 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: http://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-00 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 Jan 11 17:25:30 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074061A8955 for ; Sun, 11 Jan 2015 17:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81etzSpBHyri for ; Sun, 11 Jan 2015 17:25:27 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8021A8958 for ; Sun, 11 Jan 2015 17:25:27 -0800 (PST) Received: (qmail 29845 invoked from network); 12 Jan 2015 01:25:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=7494.54b32285.k1501; bh=xcOBCU6CgRPsZIhfvKFm9y24jfKwMzHSHdh73QI8UCg=; b=r/3+OdESi/jFSH9RXELitkjrH4dlmnLGiprB44YC+53xFTAlMvRYsFBn5U8Tg4o67qPrHSTmGvBzx5lFaRxJxYRSB0K24QWGdiFjnhj+ShXUki/JcckxNwVzAHVi4VsEjLww87+cBzfvxSJPOkb1LSvK/Gcvipry9BbyemDG+8Tsdd2YmLqtKbfbMyoMaDtu/Zd/FNHGIJ3xrYJ/fsaSZXxejQrufU5HKmCW/p+voi9DoeSYd4zyNlV+aJPTdsEs DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=7494.54b32285.k1501; bh=xcOBCU6CgRPsZIhfvKFm9y24jfKwMzHSHdh73QI8UCg=; b=Aerj0NtcWgqpsb2b9HEEQ27e09GE8q1tSOZtveKTnMmI6gokK5sbV97vblaKMDKftowPmzgr1Zs9OhTOaluZJfxFC62KBl80yS4q5fICe8hyEQ0skxTltsubHg2N2G/WVw/xUwZUvus84LcgfcrIrmJ5NmHK9PE0PEmK9o8UGWsaxTano+gR0DM0WKT7E4Edgb0Oez46vTsfBQMIrQg1Saw9PB67t+FIrRAg+73YI/ygxDhukFpAUK9pmY1g2w2i Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 12 Jan 2015 01:25:25 -0000 Date: 11 Jan 2015 20:25:24 -0500 Message-ID: From: "John R Levine" To: "Claudio Allocchio" In-Reply-To: References: <20150111215428.13470.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 01:25:29 -0000 >> This seems contrary to your previous question about whether a non-technical >> user could tell if her message was delivered successfully. > > it was a different consideration indeed :-) ... > knows that the message was delivered to my mailbox @elettra.eu, and this is > enough for her because it arrived to the mailbox she intended to reach... if > then the forward makes the message disapper in a black hole, it is MY > fault... I dunno about the people you know, but the ones I know wouldn't find that to be a very interesting distinction. It's not like mail blowing out of your mailbox, because that only affects a few letters, while a screwed up forward will lose all of them. The DSN extensions in RFC 3461 are intended to make this all work. The ORCPT and ENVID parameters let you link the DSN from a forwarded message to the original message. Sendmail and Postfix have some support for the DSN extension, but it's not clear to me how complete it is (notably, whether they pass ENVID and ORCPT on forwarded mail) and how many people actually turn it on. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sun Jan 11 17:26:41 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4421A8958 for ; Sun, 11 Jan 2015 17:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol6XZRBST8BS for ; Sun, 11 Jan 2015 17:26:36 -0800 (PST) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B049C1A1ABF for ; Sun, 11 Jan 2015 17:26:35 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id i8so16171978qcq.11 for ; Sun, 11 Jan 2015 17:26:35 -0800 (PST) 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:content-type; bh=ujbB+a2OkeMVtVwuTORkx4HeqL7sLm58h/Z+K7en4Pc=; b=LWsR+pIaVh5AKd7S2vPkb/77wWkIlHAQPPDAMvFBLxQHgrqiT3BzPuCXzfAusMrxbT TuSbz/r2K8+nr3ZOZSfHUeSS8Qvh21Aw7RM8ZJtZ2a4lRyXFuBfqPRAQuGSEugcyZpqf kJk3/Av/mT5vhzhikUB+iZx4VzHTdmBZPNga4pNsrNf1XvvhrUi0wWMdC3tat5ThBtzK 6BrJaRxrIcFSBSoP6t+erBR90klkcrN3ipjVax6spoVVQV/iusJocMbX8ZmEvVYx5KUy RAeSxhc59TmtcCjN3hbqOvxuLkhC4sd+03RoHJ2XlAAyVZ5fZO8KAO0bUIVRAkOoO83u UZXg== MIME-Version: 1.0 X-Received: by 10.224.120.8 with SMTP id b8mr24651159qar.36.1421025994889; Sun, 11 Jan 2015 17:26:34 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Sun, 11 Jan 2015 17:26:34 -0800 (PST) In-Reply-To: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 11:26:34 +1000 X-Google-Sender-Auth: RAlH4ih6-GvOiQ_3fxm8BgFxafQ Message-ID: From: Matthew Kerwin To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c2f876a4600d050c6a658c Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 01:26:38 -0000 --001a11c2f876a4600d050c6a658c Content-Type: text/plain; charset=UTF-8 Hi all, As you can see below, the file: scheme draft has been adopted by the WG. I'm in the process of writing a mini-charter, part of which is a list of people who will commit to doing timely reviews of the document. Could I please ask for volunteers to provide reviews, whose names I can list in the charter? Cheers, and thanks. On 12 January 2015 at 11:12, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Applications Area Working Group Working > Group of the IETF. > > Title : The file URI Scheme > Author : Matthew Kerwin > Filename : draft-ietf-appsawg-file-scheme-00.txt > Pages : 16 > Date : 2015-01-11 > > Abstract: > This document specifies the "file" Uniform Resource Identifier (URI) > scheme, replacing the definition in RFC 1738. > > It attempts to document current practices, while at the same time > defining a common core which is intended to interoperate across the > broad spectrum of existing implementations. > > 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: > http://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-00 > > > 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/ --001a11c2f876a4600d050c6a658c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

As you can see below, t= he file: scheme draft has been adopted by the WG. I'm in the process of= writing a mini-charter, part of which is a list of people who will commit = to doing timely reviews of the document.

Could I ple= ase ask for volunteers to provide reviews, whose names I can list in the ch= arter?

Cheers, and thanks.


On 12 January 2015 at 1= 1:12, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Applications Area Working Group Work= ing Group 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-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 16
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-01-11

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 attempts to document current practices, while at the same t= ime
=C2=A0 =C2=A0defining a common core which is intended to interoperate acros= s the
=C2=A0 =C2=A0broad spectrum of existing implementations.

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/draft-ietf-appsawg-fil= e-scheme/

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


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.kerwi= n.net.au/
--001a11c2f876a4600d050c6a658c-- From nobody Sun Jan 11 18:24:02 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9258B1A89B0 for ; Sun, 11 Jan 2015 18:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO9n-K2YPcUM for ; Sun, 11 Jan 2015 18:23:58 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.231]) by ietfa.amsl.com (Postfix) with ESMTP id BAF261A1B29 for ; Sun, 11 Jan 2015 18:23:58 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:41036] helo=rubix) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 1C/BF-30379-E3033B45; Mon, 12 Jan 2015 02:23:58 +0000 Received: from [192.168.1.115] (unknown [192.168.1.115]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 431F6140B53; Sun, 11 Jan 2015 21:23:58 -0500 (EST) Message-ID: <54B3303D.2040508@intertwingly.net> Date: Sun, 11 Jan 2015 21:23:57 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sean Leonard References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2F4C3.5020008@seantek.com> <54B2F806.2090509@intertwingly. net> <54B2FCCE.4000304@seantek.com> In-Reply-To: <54B2FCCE.4000304@seantek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: Cc: "pkix@ietf.org" , apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 02:24:00 -0000 On 01/11/2015 05:44 PM, Sean Leonard wrote: > On 1/11/2015 2:24 PM, Sam Ruby wrote: >> >> The next question is: are all possible URIs valid GeneralNames? >> >> Here are two examples: >> >> data:image/gif;base64,R0lGODlhyAAiALM...DfD0QAADs= > > Yes. Use case: Certificate Image. RFC 6170 (previously RFC 3709). > >> https://www.ietf.org/#related > > Yes. Use case: Certification Practice Statement (CPS) Pointer > (Certificate Policies, id-qt-cps). Section 4.2.1.4 of RFC 5280. I have > seen fragments in there in the wild. > > Both examples are valid. > > Note: the examples I provide here are actually examples where the URIs > are encoded directly in IA5Strings; there is no GeneralName CHOICE. But > the premise still stands. Others with PKIX experience can point to > systems/protocols where uniformResourceIdentifier is in use with the > appropriate. > > One offhand example that I was able to find, via a Google search, is the > GS1 Certificate Profile Standard v2.0 > . > That happens to use GeneralName. It's a bit elliptical, and refers to > RFC 4043 (which I rarely see), but...it's there. Thanks! This input is helpful. I don't see where it clearly states that fragments are allowed, but then again, I don't see where it says that they would be disallowed. That coupled with your statement that you have seen them in practice (however rare) is valuable input. > Sean - Sam Ruby From nobody Sun Jan 11 18:29:09 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62531A8855 for ; Sun, 11 Jan 2015 18:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1aRDgn23hTu for ; Sun, 11 Jan 2015 18:29:01 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.228]) by ietfa.amsl.com (Postfix) with ESMTP id 837681A1B35 for ; Sun, 11 Jan 2015 18:29:01 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:41804] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 95/40-08411-C6133B45; Mon, 12 Jan 2015 02:29:00 +0000 Received: from [192.168.1.115] (unknown [192.168.1.115]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 0E2C0140C4E; Sun, 11 Jan 2015 21:29:00 -0500 (EST) Message-ID: <54B3316B.7040909@intertwingly.net> Date: Sun, 11 Jan 2015 21:28:59 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Julian Reschke References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2ABA8.6030205@gmx.de> <54B2C6FA.80802@intertwingly.net> <54B2EE08.9040705@gmx.de> <54B2F527.7040404@intertwingly.net> <54B2FB76.6040208@gmx.de> In-Reply-To: <54B2FB76.6040208@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 02:29:06 -0000 On 01/11/2015 05:38 PM, Julian Reschke wrote: > > a) I still do not see how fragments are special in general. They *are* > special in the context of browsers and HTTP, but that doesn't mean we > can generalize from that. > > b) The *parser* never needs to percent encode anything. A *sender* would > need to percent-encode (*) if fragments stay the way thy are. Q: how is > that a problem in practice? Again, it is my hope/expectation that by year end every single one of the parsers that I have looked out (with the possible/probable exception of Perl) will NOT percent encode fragments. This means that virtually every parser will not be RFC 3986 compliant by your definition (or, to follow your lead, RFC 3986 is irrelevant to them as they are not "*senders*"). Furthermore, absolutely no specification in existence would cover the gap between what parsers do and what RFC 3986 requires. Forgetting me, the WHATWG, the W3C, and everything else; I would think that that would be a problem. Finally, I will openly say that I don't understand your distinction. I know what it means to send a HTTP request (which you concede is special), but I have no idea what it means to *send* a data: URI. RFC 2616 (and its successors) are about *sending* (among other things). RFC 3986 is about syntax and a process for resolving relative references. There are three occurrences of the word "send" in RFC 3986. Two are examples. The final occurrence relates to the necessity for there to be a base URI when sending a relative reference. >> the URL standard which describes the real world use cases that RFC 3986 >> does not address which prevent a proper layering. Additionally, there >> would be a description of what the set of outputs from a URL >> parse/stringification process does produce, i.e., a description of what >> RFC 3986 should have said. > > Which brings us back to the question what exactly is wrong with RFC > 3986. So far I heard "what it says about IDNA". What else? I have published a lot of test values that I am looking for people to work through with me. Cooperation amongst browser vendors in this effort is increasing. I have yet to find anybody on this list willing to look at this data. The fact that you either will not or can not "hear" that parsers are not RFC 3986 compliant, coupled with the fact that you either will not or can not work with the test results I have published is not working for me. - Sam Ruby From nobody Sun Jan 11 21:30:38 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F2B1A8895 for ; Sun, 11 Jan 2015 21:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_OMec0EwWk9 for ; Sun, 11 Jan 2015 21:30:35 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 61B7B1A88A4 for ; Sun, 11 Jan 2015 21:30:35 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id DD25243807C; Sun, 11 Jan 2015 21:30:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=p5ubvFdXkqwlL/ rZC8hA240GFpw=; b=OAUWZv+gDUZw+dhwylyM4pzUmXVbw2pQwCTKhiW3T6Xcvk JcCDPazAFy0xoYFZ4Sf8MU+EV1OsNpt0Il/3aA2nds2NfGKomRzsmCWvY0dWQk2C nY8N3TO7f+sIeCK6YrTASHFKypYJbbM0gcdb6/KQHGam4/580meUvVvxQi6Gg= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPA id 8A9A4438072; Sun, 11 Jan 2015 21:30:34 -0800 (PST) Date: Sun, 11 Jan 2015 23:30:34 -0600 From: Nico Williams To: Julian Reschke Message-ID: <20150112053032.GF16323@localhost> References: <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2ABA8.6030205@gmx.de> <54B2C6FA.80802@intertwingly.net> <54B2EE08.9040705@gmx.de> <54B2F527.7040404@intertwingly.net> <54B2FB76.6040208@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54B2FB76.6040208@gmx.de> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 05:30:36 -0000 On Sun, Jan 11, 2015 at 11:38:46PM +0100, Julian Reschke wrote: > b) The *parser* never needs to percent encode anything. A *sender* > would need to percent-encode (*) if fragments stay the way thy are. > Q: how is that a problem in practice? Exactly. Protocol slots that limit content to US-ASCII must use appropriate encoding, which means that the code putting non-ASCII content into such slots should do the necessary encoding. For IRIs this is described in RFC3987. Whether non-ASCII Unicode forms may appear in slots where they are allowed is a much more interesting question. RFC3987 says "yes". E.g., IRIs in SANs MUST be encoded into URIs per-RFC3987 because RFC5280 defines the uniformResourceIdentifier arm of the GeneralName CHOICE as IA5String. If we were to add an IRI OtherName for PKIX then a non-ASCII then IRIs could appear _there_ in their Unicode, unencoded form. The location bar of the browser *is* a protocol element of sorts: because it's involved in cut-n-paste [local, but still real] protocols, because of JavaScript. The location bar therefore is a Unicode-aware slot[*] and MUST accept IRIs (Unicode), but it also MUST accept ASCII encoded IRIs (because of one might be pasted in). Because it's also a UI element, the location bar MUST display Unicode. [*] Because it's a UI element, and because a string and strings are Unicode strings in JavaScript. I admit this is hand-waving: there is no requirement that a browser support JavaScript, and there can be no requirement that the UI facing part of it use Unicode when the locale doesn't. A browser could accept non-Unicode, non-ASCII in a non-Unicode, non-ASCII locale, but since at some point the rubber has to meet the road and an ASCII URI will be needed, the browser effectively has to do the encodings that RFC3987 says to do, which means the browser must deal in Unicode, which means we might as well speak of the location bar as being Unicode-aware even in cases where the locale uses a Unicode-incompatible codeset. > ((*) Maybe it's time to coin a term for the > utf-8-encode-then-uri-percent-escape thingy) > > >It may come to pass that Roy is the only person who shares the goals > >that he described. In which case, the end result will be an appendix to > > I believe I share these goals. Me too. I don't see why there's any controversy here. What am I missing? > >the URL standard which describes the real world use cases that RFC 3986 > >does not address which prevent a proper layering. Additionally, there > >would be a description of what the set of outputs from a URL > >parse/stringification process does produce, i.e., a description of what > >RFC 3986 should have said. > > Which brings us back to the question what exactly is wrong with RFC > 3986. So far I heard "what it says about IDNA". What else? IMO nothing, not even that. I don't want to see punycoded/pct-encoded strings in my UIs -- no one does[**]. But that doesn't mean that protocol elements shouldn't have to see them either. Yes, sometimes encoded strings will leak where they shouldn't (and then someone has to work to plug the leak). [**] End users anyways. Nico -- From nobody Sun Jan 11 21:46:21 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8BE1A89E9 for ; Sun, 11 Jan 2015 21:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KjqwPZXUIYX for ; Sun, 11 Jan 2015 21:46:17 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2A31A8895 for ; Sun, 11 Jan 2015 21:46:17 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 603F327BC064; Sun, 11 Jan 2015 21:46:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=gFyJmp7lRec/y4 T2o2BqV82AgKI=; b=mzRl8Ddwhr/NVvDImuyfuXqWsEy5xMz2pDJ09E07DwSq8e cPRTcsxMAKiV/i1gNi/OJLsy4I3hiuMnfIDYqymcJXzHMIKt2DwM7B6bFzVvHak5 qamNy2aiUB52nAKE7m6+hfuNq7VYTnrvHJOTeAndSPOuPDiayAG6h4xZGhgLY= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPA id 0C40C27BC05D; Sun, 11 Jan 2015 21:46:16 -0800 (PST) Date: Sun, 11 Jan 2015 23:46:16 -0600 From: Nico Williams To: Matthew Kerwin Message-ID: <20150112054614.GG16323@localhost> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF Apps Discuss , Larry Masinter Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 05:46:19 -0000 On Sun, Jan 04, 2015 at 10:22:59PM +1000, Matthew Kerwin wrote: > To be honest, a big reason for using RFC 3986 as a normative reference > is so I don't have to deal with things like hostnames. If those > definitions are good enough for the shiny new HTTP/1.1 (which actually > uses hostnames) then surely they're also sufficient for file: (which > often doesn't). The file scheme is a bit special though in that a hostname could appear outside the authority part of the URI, right? Hosts appearing there should be dealt with as any other non-authority part of an IRI when the IRI must be fed into a URI slot. OTOH, RFCs 3986 and 3987 apply, so if a hostname is to appear as an authority in a file scheme URI/IRI then you know what to do (because those RFCs tell you what to do). > BTW who on earth writes localhost as "2130706433"? Or more significantly, > who on earth *accepts* that as a valid URL? The browser location bar certainly shouldn't. Nico -- From nobody Sun Jan 11 22:06:48 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C721A89F1 for ; Sun, 11 Jan 2015 22:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LewYgo_DS2h6 for ; Sun, 11 Jan 2015 22:06:43 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5831A8895 for ; Sun, 11 Jan 2015 22:06:43 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 61FCF2005C231; Sun, 11 Jan 2015 22:06:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=8O/9qra/dxgU4B XTf4kkcGyY2GQ=; b=LYflO4I6h66MMyGtY0Q19vXY7emrOcgky/IDb/C5mg5PsR A6wq0ETAPUVaI6qZM3xR8FdSjDcadLODtMtu6ffb/tCjrxPeX5SPJTk5Aei+KdA7 DCxFXODYNxBurHaJAb+02+CHztIETn/G9T127ahMM+pNjcypYe4aY/R3jH9rI= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id 020052008232A; Sun, 11 Jan 2015 22:06:42 -0800 (PST) Date: Mon, 12 Jan 2015 00:06:42 -0600 From: Nico Williams To: Matthew Kerwin Message-ID: <20150112060641.GH16323@localhost> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF Apps Discuss , Larry Masinter Subject: [apps-discuss] Filesystem I18N, again (Re: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 06:06:46 -0000 On Sun, Jan 04, 2015 at 10:22:59PM +1000, Matthew Kerwin wrote: > Importantly, I don't want to include every codepath in every implementation > that exists, but I don't want the definition I write to *not* work in any > implementations. I suspect we'll have to make some choices then. > [1] http://blogs.msdn.com/b/ie/archive/2006/12/06/file-uris-in-windows.aspx Yes, there's an aliasing problem when IRIs are encoded onto URIs where some of the URI consumers simply decode into bytes in non-UTF-8, non-ASCII locales. This is not something that the IETF ignored, it's just something that the IETF couldn't fix. Many filesystems allow just about any byte values other than the traditional path component separator character(s) (ASCII slash and, for Windows, _also_ backslash), and so we have an interop problem. I don't think we should have this discussion every time a filesystem- related protocol comes up! We should have a spec we can reference from specs dealing with filesystems. We've had this discussion in quite a few contexts (e.g., WebDAV, NFSv4, even PKCS#11 URIs just now; and probably many more). The facts are: - filesystems exist with non-Unicode, non-ASCII object names (files, directories, symlinks, ...), and/or which allow new such names to be created at any time; - interpretation of such octet strings is necessarily locale-specific; - non-Unicode, non-ASCII locales exist and will continue to for some time; - often the only entities that know a filesystem object name's codeset are end users; - we have Internet protocols that need to interface to these filesystems; - we also have local interfaces involved that aren't Internet protocols. (It gets worse. We even have a filesystem that uses an inconvenient Unicode normalization. But the above facts will do for now.) The thing to do is to demand [normalized] Unicode on the wire. We can't really achieve that, but we (the IETF) demand it anyways and note the problems that result from not knowing what codeset is used for a given character string because we only know it as an octet string. (Those problems don't arise from demanding UTF-8 on the wire.) We do this because the only alternative that can interop is to tag these strings with codeset metadata, but since a) we lack that metadata (see facts above), and b) it would be *much* more work to start carrying that metadata everywhere than it would be to convert to/from Unicode at the boundaries where we *do* have that metadata... we do the simpler thing of demanding Unicode in the middle. The same applies to the file scheme. Yes, you can get in trouble if you mix non-ASCII names with locales with various different codesets, so what? We should still say that RFCs 3986 and 3987 apply. Longer term, what should really happen is that filesystem _APIs_ that just-use-8 today should start doing conversion to/from Unicode so that "the middle" (e.g., the VFS layer, the wire, ...) can carry Unicode and the "edges" (the filesystem's on-disk format, the APIs) can carry whatever is locally appropriate, and then end users should clean up as necessary (tools for this are common). This is a bit like boiling a Great lake: do we really expect C runtimes for various OSes to do this? I'd like to expect that, yes, though I won't hold my breath. But it's better than the alternative (see above). Nico -- From nobody Sun Jan 11 22:28:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48931A87F1 for ; Sun, 11 Jan 2015 22:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Hgnk-_EPWoH for ; Sun, 11 Jan 2015 22:28:20 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9541A88A7 for ; Sun, 11 Jan 2015 22:28:19 -0800 (PST) Received: by mail-qg0-f42.google.com with SMTP id q108so16413479qgd.1 for ; Sun, 11 Jan 2015 22:28:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=74zw0ao9Qhso2u0BzvfaSfs3EfX3av76ri2Oy+7A51g=; b=okULO1wkl2ZPCBYiCYoPMklTIPD75wGxbzJZxS2GQ4zxExfuayY1loa9LM8UDvW6X0 TRHrKcHok0thmAFtUdy1qjcP426Ow3RpeM0Zpy/Yj05kL0xUiIau8qA3Mow14dMPEeSI PkxbeaEj53swQbPPL02h3/zVUstSlEKRD6TmQ9iTpzmNWjA4RFY7N1DrPN6UPM7BCP8e DVFrNrgzWZxhsL3EVyX1VHL9d2Kj94iVH1W4NkPElbEZKYOpn0XmF5t8/55I4gYVLWWz sJTgWASzmyLg3qIOOACld3XczxMlRHXOYSpvh7OwfDAWGQnaZfszlRtwzHyUeIfWeX9D fZsA== MIME-Version: 1.0 X-Received: by 10.224.128.196 with SMTP id l4mr47134657qas.100.1421044098940; Sun, 11 Jan 2015 22:28:18 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Sun, 11 Jan 2015 22:28:18 -0800 (PST) In-Reply-To: <54B3316B.7040909@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2ABA8.6030205@gmx.de> <54B2C6FA.80802@intertwingly.net> <54B2EE08.9040705@gmx.de> <54B2F527.7040404@intertwingly.net> <54B2FB76.6040208@gmx.de> <54B3316B.7040909@intertwingly.net> Date: Mon, 12 Jan 2015 16:28:18 +1000 X-Google-Sender-Auth: q4Df8BvkQWlBZX2BT12pIAqvlLY Message-ID: From: Matthew Kerwin To: Sam Ruby Content-Type: multipart/alternative; boundary=001a11c2c358ba4443050c6e9ca0 Archived-At: Cc: Julian Reschke , IETF Apps Discuss Subject: Re: [apps-discuss] character repertoire for fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 06:28:23 -0000 --001a11c2c358ba4443050c6e9ca0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12 January 2015 at 12:28, Sam Ruby wrote: > On 01/11/2015 05:38 PM, Julian Reschke wrote: > >> >> b) The *parser* never needs to percent encode anything. A *sender* would >> need to percent-encode (*) if fragments stay the way thy are. Q: how is >> that a problem in practice? >> > > > Finally, I will openly say that I don't understand your distinction. I > know what it means to send a HTTP request (which you concede is special), > but I have no idea what it means to *send* a data: URI. > =E2=80=8B=E2=80=8B > > =E2=80=8B > =E2=80=8B Provide it=E2=80=8B to a parser. E.g. by writing it in a HTML document or C= SS file. As with any URIs, the UA parser interprets the sequence of bytes in the document (or from a UI element, etc.) into a "URI object", and uses that URI object to resolve the resource. Whether that be by sending a HTTP request or constructing a virtual object or whatever is not really relevant at this point. =E2=80=8B > > =E2=80=8B=E2=80=8B > RFC 2616 (and its successors) are about *sending* (among other things). > RFC 3986 is about syntax and a process for resolving relative references. > There are three occurrences of the word "send" in RFC 3986. Two are > examples. The final occurrence relates to the necessity for there to be = a > base URI when sending a relative reference. > =E2=80=8B=E2=80=8B > =E2=80=8B > =E2=80=8B > > =E2=80=8B > Actually 2616 and co. have two sides: defining the 'http' and 'https' URI schemes (inheriting from the generic syntax from 3986), and the actual http protocol. The HTTP RFCs don't ever talking about "sending" URIs, they send requests which are generated from URIs. The overlap is that a HTTP request includes some parts of the URI in its fields. HTML is a URL =E2=80=8B" sender =E2=80=8B" , if you want to define such a thing, as is the location bar, etc. >> The fact that you either will not or can not "hear" that parsers are not > RFC 3986 compliant, coupled with the fact that you either will not or can > not work with the test results I have published is not working for me. > > Parser compliance has two parts: 1) For any given input deemed "valid"=E2=80=8B by the spec, all compliant p= arsers interpret it the same way. For RFC 3986 this is a bit hazy, because it defines a generic syntax but the outputs are defined by scheme-specific specs that inherit (/extend) the generic syntax. The practical outputs of parsing a 'http' URI, for example, are defined by RFC 7230 -- ultimately it results in a valid HTTP request. 2) For any given input deemed "invalid" by the spec with a specific failure mode, all compliant parsers fail in the same way. This is a bit trickier, because it's often not well defined or has to be inferred. As a general rule, we usually say, "anything that doesn't match the spec isn't a URI." This is handy because it makes it easier for something like the awesomebar to determine whether a given input is a http URI (etc.) or not. I'm guessing this is where you come in. It seems that what you want is to identify and standardise common behaviours for a bunch of those "not a URI (but probably should be interpreted as a URL)" inputs. I don't think revving 3986 is the right way to do this. For one: RFC 3986 provides the basis for a lot of URI schemes, so changing it in an incompatible way leaves a lot of those schemes up in the air. For two: as in HTTP, the syntax elements are sometimes used in protocol artefacts. That makes them pretty rigid. A better way would be to define a new "thing", and provide instructions for how to translate to/from RFC 3986-style URIs. That's what RFC 3987 did with IRIs. I'm pretty sure that's pretty close to what you're already doing with the URL spec. Rather than fight RFC 3986, how about treating it as a target= ? --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11c2c358ba4443050c6e9ca0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 12 January 2015 at 12:28, Sam Ruby <rubys@intertwingly.net= > wrote:
On 01/11/2015 05:38 PM, Julian Re= schke wrote:

b) The *parser* never needs to percent encode anything. A *sender* woul= d
need to percent-encode (*) if fragments stay the way thy are. Q: how is
that a problem in practice?


Finally, I will openly say that I don't understand your distinction.=C2= =A0 I know what it means to send a HTTP request (which you concede is speci= al), but I have no idea what it means to *send* a data: URI.
=E2=80=8B=E2=80=8B

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

Provide it=E2=80=8B to = a parser. E.g. by writing it in a HTML document or CSS file.
=
As with any URIs, the UA parser interprets the sequence = of bytes in the document (or from a UI element, etc.) into a "URI obje= ct", and uses that URI object to resolve the resource. Whether that be= by sending a HTTP request or constructing a virtual object or whatever is = not really relevant at this point.


=E2=80=8B

=E2=80=8B=E2=80=8B
RFC 2616 (and its successor= s) are about *sending* (among other things).=C2=A0 RFC 3986 is about syntax= and a process for resolving relative references.=C2=A0 There are three occ= urrences of the word "send" in RFC 3986.=C2=A0 Two are examples.= =C2=A0 The final occurrence relates to the necessity for there to be a base= URI when sending a relative reference.
=E2=80=8B=E2=80=8B
=E2=80=8B
=E2=80=8B
=C2=A0
=E2=80=8B

Actually = 2616 and co. have two sides: defining the 'http' and 'https'= ; URI schemes (inheriting from the generic syntax from 3986), and the actua= l http protocol.

The HTTP RFCs don't ever talking about "= ;sending" URIs, they send requests which are generated from URIs.=C2=A0= The overlap is= that a HTTP request includes some parts of the URI in its fields.=C2=A0HTML is a = URL
=E2=80=8B"
sender
=E2=80=8B"
, if you want to define such a thing, as is the lo= cation bar, etc.

<= div>


 The fact that you either will not or can not "hear" that parsers = are not RFC 3986 compliant, coupled with the fact that you either will not = or can not work with the test results I have published is not working for m= e.


Parser compliance has two parts:

1) For= any given input deemed "valid"=E2=80=8B by the spec, all complia= nt parsers interpret it the same way. For RFC 3986 this is a bit hazy, beca= use it defines a generic syntax but the outputs are defined by scheme-speci= fic specs that inherit (/extend) the generic syntax. The practical outputs = of parsing a 'http' URI, for example, are defined by RFC 7230 -- ul= timately it results in a valid HTTP request.

2) For any given input deemed "invalid" by the spec with a spe= cific failure mode, all compliant parsers fail in the same way. This is a b= it trickier, because it's often not well defined or has to be inferred.= As a general rule, we usually say, "anything that doesn't match t= he spec isn't a URI."

This is han= dy because it makes it easier for something like the awesomebar to determin= e whether a given input is a http URI (etc.) or not.

I'm guessing this is where you come in. It seems that what y= ou want is to identify and standardise common behaviours for a bunch of tho= se "not a URI (but probably should be interpreted as a URL)" inpu= ts. I don't think revving 3986 is the right way to do this.

For one: RFC 3986 provides the basis for a lot of URI= schemes, so changing it in an incompatible way leaves a lot of those schem= es up in the air.

For two: as in HTTP, the= syntax elements are sometimes used in protocol artefacts. That makes them = pretty rigid.

A better way would be to def= ine a new "thing", and provide instructions for how to translate = to/from RFC 3986-style URIs. That's what RFC 3987 did with IRIs. I'= m pretty sure that's pretty close to what you're already doing with= the URL spec. Rather than fight RFC 3986, how about treating it as a targe= t?


--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a11c2c358ba4443050c6e9ca0-- From nobody Sun Jan 11 22:32:32 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A09F1A89F2 for ; Sun, 11 Jan 2015 22:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgq8wpwfhwKg for ; Sun, 11 Jan 2015 22:32:29 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 263311A88A7 for ; Sun, 11 Jan 2015 22:32:29 -0800 (PST) Received: from [192.168.2.175] ([84.187.47.145]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MGWR2-1XxL7g2WBM-00DE6z; Mon, 12 Jan 2015 07:32:24 +0100 Message-ID: <54B36A77.9090908@gmx.de> Date: Mon, 12 Jan 2015 07:32:23 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2ABA8.6030205@gmx.de> <54B2C6FA.80802@intertwingly.net> <54B2EE08.9040705@gmx.de> <54B2F527.7040404@intertwingly.net> <54B2FB76.6040208@gmx.de> <54B3316B.7040909@intertwingly.net> In-Reply-To: <54B3316B.7040909@intertwingly.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:qDjHd85WpQfhJbUj0CdvAjPhyzMz0APGh3ktjSHYuaCLWH8/l7w iInNYLwGgttBy5c2Os5EauXsdMsxCpMfvF68b0pvC7KeEPW/AeRX0YmXiSB9uBNPF3+yawo Zt8Q+NwqXLu9KKwlIXw6JFZ265Efi/6jcZGCHJTodGC6L7AgawNOi6JmO6oYS3R8UGvFtxo W6VROnvl0PImPqLyF/8oQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 06:32:31 -0000 On 2015-01-12 03:28, Sam Ruby wrote: > On 01/11/2015 05:38 PM, Julian Reschke wrote: >> >> a) I still do not see how fragments are special in general. They *are* >> special in the context of browsers and HTTP, but that doesn't mean we >> can generalize from that. >> >> b) The *parser* never needs to percent encode anything. A *sender* would >> need to percent-encode (*) if fragments stay the way thy are. Q: how is >> that a problem in practice? > > Again, it is my hope/expectation that by year end every single one of > the parsers that I have looked out (with the possible/probable exception > of Perl) will NOT percent encode fragments. ...when doing what? A parser parses a URI into components. Are you referring to the act of return the fragment identifier as result of the parsing process? > This means that virtually every parser will not be RFC 3986 compliant by > your definition (or, to follow your lead, RFC 3986 is irrelevant to them > as they are not "*senders*"). Can you give a concrete example where this affects a URI that is currently valid per RFC 3986? > Furthermore, absolutely no specification in existence would cover the > gap between what parsers do and what RFC 3986 requires. > > Forgetting me, the WHATWG, the W3C, and everything else; I would think > that that would be a problem. > > Finally, I will openly say that I don't understand your distinction. I > know what it means to send a HTTP request (which you concede is > special), but I have no idea what it means to *send* a data: URI. I used "sender" as in "software that generates a URI". > ... >>> the URL standard which describes the real world use cases that RFC 3986 >>> does not address which prevent a proper layering. Additionally, there >>> would be a description of what the set of outputs from a URL >>> parse/stringification process does produce, i.e., a description of what >>> RFC 3986 should have said. >> >> Which brings us back to the question what exactly is wrong with RFC >> 3986. So far I heard "what it says about IDNA". What else? > > I have published a lot of test values that I am looking for people to > work through with me. Cooperation amongst browser vendors in this > effort is increasing. I have yet to find anybody on this list willing > to look at this data. Ahem. I think you got concrete feedback from Mark, Björn, and myself (and maybe others). > The fact that you either will not or can not "hear" that parsers are not > RFC 3986 compliant, coupled with the fact that you either will not or > can not work with the test results I have published is not working for me. Sam, could you for once leave the meta-level and provide an example (remember: this thread was about fragment identifiers)? And yes, I'm still talking about URIs that are currently valid per RFC 3986. Best regards, Julian From nobody Sun Jan 11 22:48:33 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022411A8A50 for ; Sun, 11 Jan 2015 22:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvhXNycGu8xA for ; Sun, 11 Jan 2015 22:48:28 -0800 (PST) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2FC1A8A4B for ; Sun, 11 Jan 2015 22:48:28 -0800 (PST) Received: by mail-qc0-f178.google.com with SMTP id p6so16842752qcv.9 for ; Sun, 11 Jan 2015 22:48:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DxhydHTgPNbIeBiIJWtAGNHY/LisNoUher/TjvIm1zI=; b=rLIw5QyeltMYj02vMEDbubaeF5/gr8ner1psxjA8qA0tBdFvH2BFHI3khi0ZLmCpsm nA3+GpC5KV0mZHVqjgePj0XpGeKJ0OaBG6oHWOWq+SnxK+fljstuxMXcfo+c7Vkm7FCa 38kv9AEWksIpK8FUfBi5hkwf5/JMqqmE/SvG5JxpQ1wX8ifaSxHCxtNq7eqi1/gTmPNv dFyZ1xyPpGY9fT6wL/shH8z4Aiki4pEUIbAfrCcZEchcSRER4fFod4iTC81uRaJ85+nb luRMl2x04T0HsVWEEc4p9Q1PKahyv5rklg91hQMOayr3nNMFO37JxvgpXvV0h8paVUzp ei5Q== MIME-Version: 1.0 X-Received: by 10.224.20.133 with SMTP id f5mr36082657qab.17.1421045306957; Sun, 11 Jan 2015 22:48:26 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Sun, 11 Jan 2015 22:48:26 -0800 (PST) In-Reply-To: <20150112054614.GG16323@localhost> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <20150112054614.GG16323@localhost> Date: Mon, 12 Jan 2015 16:48:26 +1000 X-Google-Sender-Auth: 6LQOVLAgVEtub917JtNEjy0Dcng Message-ID: From: Matthew Kerwin To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c2b82ebb24f8050c6ee450 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 06:48:30 -0000 --001a11c2b82ebb24f8050c6ee450 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12 January 2015 at 15:46, Nico Williams wrote: > On Sun, Jan 04, 2015 at 10:22:59PM +1000, Matthew Kerwin wrote: > > To be honest, a big reason for using RFC 3986 as a normative reference > > is so I don't have to deal with things like hostnames. If those > > definitions are good enough for the shiny new HTTP/1.1 (which actually > > uses hostnames) then surely they're also sufficient for file: (which > > often doesn't). > > The file scheme is a bit special though in that a hostname could appear > outside the authority part of the URI, right? Hosts appearing there > should be dealt with as any other non-authority part of an IRI when the > IRI must be fed into a URI slot. > > OTOH, RFCs 3986 and 3987 apply, so if a hostname is to appear as an > authority in a file scheme URI/IRI then you know what to do (because > those RFCs tell you what to do). > > =E2=80=8BHmm, I think there's an issue I should file[1]. So far I've hand-w= aved the authority-in-path issue by deferring to Microsoft's UNC definition, but it seems people would prefer to use the 'host' ABNF construct to detect UNC-in-path URIs, and then have guidance for translating the host to something UNC accepts (or not) before dereferencing. =E2=80=8BIs that right?=E2=80=8B =E2=80=8B[1]: https://github.com/phluid61/internet-drafts/issues/4=E2=80=8B --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11c2b82ebb24f8050c6ee450 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 12 January 2015 at 15:46, Nico Williams <nico@cryptonector.c= om> wrote:
On Sun, Jan 04, 2015 at 10:22:5= 9PM +1000, Matthew Kerwin wrote:
> To be honest, a big reason for using RFC 3986 as a normative reference=
> is so I don't have to deal with things like hostnames. If those > definitions are good enough for the shiny new HTTP/1.1 (which actually=
> uses hostnames) then surely they're also sufficient for file: (whi= ch
> often doesn't).

The file scheme is a bit special though in that a hostname could app= ear
outside the authority part of the URI, right?=C2=A0 Hosts appearing there should be dealt with as any other non-authority part of an IRI when the
IRI must be fed into a URI slot.

OTOH, RFCs 3986 and 3987 apply, so if a hostname is to appear as an
authority in a file scheme URI/IRI then you know what to do (because
those RFCs tell you what to do).

<= br>
=E2=80=8BHmm, I think there's an issue I should file[= 1]. So far I've hand-waved the authority-in-path issue by deferring to = Microsoft's UNC definition, but it seems people would prefer to use the= 'host' ABNF construct to detect UNC-in-path URIs, and then have gu= idance for translating the host to something UNC accepts (or not) before de= referencing.

=E2=80=8BIs that right?=E2= =80=8B



=E2=80=8B= [1]: https= ://github.com/phluid61/internet-drafts/issues/4=E2=80=8B


--
=C2= =A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a11c2b82ebb24f8050c6ee450-- From nobody Sun Jan 11 23:42:29 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7561D1A8A5A for ; Sun, 11 Jan 2015 23:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9SIJba_wuGu for ; Sun, 11 Jan 2015 23:42:27 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 A85461A8A59 for ; Sun, 11 Jan 2015 23:42:26 -0800 (PST) Received: from [192.168.2.175] ([84.187.47.145]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0ML72n-1YAIer3ukL-000PKk; Mon, 12 Jan 2015 08:42:21 +0100 Message-ID: <54B37ADA.3020609@gmx.de> Date: Mon, 12 Jan 2015 08:42:18 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin , IETF Apps Discuss References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Fu6PPFY5YXNcuSTmJJX3tZ9AP+OQ2dOXfPe8NChhhCyXwdx78Ad vighdPCfcja12W+IBi1VF0K47U4qY96bO97OjCQXVHZvRpFk8zxbkwB9UEkBzMBNvqrpH6o K7XviXnCU+AgWq04iKFXQVQOdGZGKkqwdsYr/aiJBOm5h2C0NZaN3aD6SvlcO3NJDIcu0rf P4F2JjwtYLj0i7NLdZIxg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 07:42:28 -0000 On 2015-01-12 02:26, Matthew Kerwin wrote: > Hi all, > > As you can see below, the file: scheme draft has been adopted by the WG. > I'm in the process of writing a mini-charter, part of which is a list of > people who will commit to doing timely reviews of the document. > > Could I please ask for volunteers to provide reviews, whose names I can > list in the charter? > > Cheers, and thanks. I volunteer. Best regards, Julian From nobody Mon Jan 12 00:36:42 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660761A1B2E for ; Mon, 12 Jan 2015 00:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Uy40_cJAS1N for ; Mon, 12 Jan 2015 00:36:38 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895F21A1B3E for ; Mon, 12 Jan 2015 00:36:38 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5E162FA0004; Mon, 12 Jan 2015 08:36:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1421051796; bh=D+I+ETwYL1f5nsBRXkq4/ocICTbIsOQO6Awm8T9ZOZc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=TxsFKCAdPtmPQDQgR3U6DyFbxzy1ESnFzdA6TlvUbcZOYF1U07ZZsZI/RDEjDsbAn o5kwvER8kwBLqnRtZTxPRQ0WdrjYPamLtJL8/arskFYzeBq1bcUK2DJmQLsZd32PnF Pnk/ttW/0KF3F+iUpQL0hTCyxXbxwmI0PonnKW/Q= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1421051795-3758-3757/12/92; Mon, 12 Jan 2015 08:36:35 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Mon, 12 Jan 2015 09:36:33 +0100 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.6; X11; Linux; Ubuntu 14.04.1 LTS Mime-Version: 1.0 Message-Id: <632a2444-bb0f-4ce9-ad40-4f378f856a57@gulbrandsen.priv.no> In-Reply-To: References: <20150111215428.13470.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 08:36:40 -0000 On Sunday, January 11, 2015 11:40:55 PM CEST, Claudio Allocchio wrote: > ... but I just tried to extend the question of "(positive) DSNs > non repudiation" to the open Internet, trying to see if we have, > if any, possible mechanisms to do so, without enforcing > additional rules which you can apply only within a closed > regulated environment. I haven't tested it or even considered this use case when I set up the server, but the Postfix version I use is less than ten years old and I do use DKIM. So I think it's worth trying: Send me mail with an entropy-rich ENVID and NOTIFY=SUCCESS,FAILURE, and see if you get back a DKIM-signed success DSN. Arnt From nobody Mon Jan 12 00:59:51 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645E51A1B42 for ; Mon, 12 Jan 2015 00:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPT-riuXNFcA for ; Mon, 12 Jan 2015 00:59:48 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 337FA1A1B2E for ; Mon, 12 Jan 2015 00:59:48 -0800 (PST) Received: internal info suppressed Date: Mon, 12 Jan 2015 09:59:44 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@synx02.dir.garr.it To: Arnt Gulbrandsen In-Reply-To: <632a2444-bb0f-4ce9-ad40-4f378f856a57@gulbrandsen.priv.no> Message-ID: References: <20150111215428.13470.qmail@ary.lan> <632a2444-bb0f-4ce9-ad40-4f378f856a57@gulbrandsen.priv.no> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1421053185; bh=UX7OKVzJVQZFmSaJt4icMj0SGSq8Bz/yr2fNNCeuZ6U=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=u4Krahi5Q0zJ5t8vMgbM6QmtFwn+lqfB/5W9TdU5WG2qQwbwrJUljgMAYnQw2BTx0 XWE+hKWi3CP3UkcFHORZxn7f8nh9N/Qp/zmXNIGuNBWI9VT9ufBWQ0Y3DQW0lD6FNN qKB53EMhffmlD46GuidEhwRIYmDPaCoVjDGAwSoc= Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 08:59:50 -0000 On Mon, 12 Jan 2015, Arnt Gulbrandsen wrote: > On Sunday, January 11, 2015 11:40:55 PM CEST, Claudio Allocchio wrote: >> ... but I just tried to extend the question of "(positive) DSNs non >> repudiation" to the open Internet, trying to see if we have, if any, >> possible mechanisms to do so, without enforcing additional rules which you >> can apply only within a closed regulated environment. > > I haven't tested it or even considered this use case when I set up the > server, but the Postfix version I use is less than ten years old and I do use > DKIM. So I think it's worth trying: Send me mail with an entropy-rich ENVID > and NOTIFY=SUCCESS,FAILURE, and see if you get back a DKIM-signed success > DSN. OK, I need to check also my Postfix setup for the ENVID, and then I'll make the test! back later... > > Arnt > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Mon Jan 12 01:12:38 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204BD1A8A65 for ; Mon, 12 Jan 2015 01:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ff314bm2_yq0 for ; Mon, 12 Jan 2015 01:12:27 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 215171A1B2E for ; Mon, 12 Jan 2015 01:12:26 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id BAE1732E577; Mon, 12 Jan 2015 18:11:41 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 7f59_2b24_b34dbfb3_87fc_4135_ae18_dc94c4c89fc2; Mon, 12 Jan 2015 18:11:41 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id ED034BF521; Mon, 12 Jan 2015 18:11:40 +0900 (JST) Message-ID: <54B38FCC.9030305@it.aoyama.ac.jp> Date: Mon, 12 Jan 2015 18:11:40 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , Julian Reschke , Sean Leonard , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$40 01a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <54B29C84.8010709@gmx.de> <54B2A28D.40003@intertwingly.net> In-Reply-To: <54B2A28D.40003@intertwingly.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 09:12:33 -0000 On 2015/01/12 01:19, Sam Ruby wrote: > On 01/11/2015 10:53 AM, Julian Reschke wrote: > To you, RFC 3986 (including potential errata and/or bis work) implies > ASCII. Sam - As far as I have looked at your spec, the main difference between fragments and the rest of an URL is that fragments don't get %-encoded but stay as Unicode when parsing. > I point out that that restriction does not seem to make sense for > fragments. From an user point, the restriction doesn't make sense for any part of an UR?. From a protocol point, there are protocols/formats where slots are defined (and implemented) to only accept ASCII. These protocols/formats cannot be upgraded just by changing the definition. Therefore, it seems that even an RFC 3986 bis, however that will look, will have to have a definition/production/name for the form that is ASCII only. Regards, Martin. From nobody Mon Jan 12 01:20:37 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833E51A8A83 for ; Mon, 12 Jan 2015 01:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoWMbKa37ntv for ; Mon, 12 Jan 2015 01:20:34 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 0E6611A8A84 for ; Mon, 12 Jan 2015 01:20:34 -0800 (PST) Received: from [192.168.2.175] ([84.187.47.145]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lu8Ri-1Xkinm1VEE-011Pfe; Mon, 12 Jan 2015 10:20:24 +0100 Message-ID: <54B391D5.10803@gmx.de> Date: Mon, 12 Jan 2015 10:20:21 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Sam Ruby , Sean Leonard , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$40 01a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <54B29C84.8010709@gmx.de> <54B2A28D.40003@intertwingly.net> <54B38FCC.9030305@it.aoyama.ac.jp> In-Reply-To: <54B38FCC.9030305@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:hjQBR9Ip2PIeB1fy9XWGtMpoCqqrYzNITlvEtE4D0pTkVy/exS/ yiInbCdqWoY71c17Vv3m16pW1nfAMUbRhXYja1xqFhuo+aEgOVZjPCH7nJGseCozE4GEhka MFBwCIjlwBC2ntCSFXImWUS821uQlrJMK8z9TU7TAWUGrzp/oMugms22r3WAPNHx5qG9uYj z/bD1XJasGowC5os/Z5RQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 09:20:35 -0000 On 2015-01-12 10:11, "Martin J. Dürst" wrote: > On 2015/01/12 01:19, Sam Ruby wrote: >> On 01/11/2015 10:53 AM, Julian Reschke wrote: > >> To you, RFC 3986 (including potential errata and/or bis work) implies >> ASCII. > > Sam - As far as I have looked at your spec, the main difference between > fragments and the rest of an URL is that fragments don't get %-encoded > but stay as Unicode when parsing. > > >> I point out that that restriction does not seem to make sense for >> fragments. > > From an user point, the restriction doesn't make sense for any part of > an UR?. From a protocol point, there are protocols/formats where slots Exactly. Another thing to consider is what we gain by allowing non-ASCII in a single place in the identifier as opposed to the confusion caused of having different rules for the different parts. > ... Best regards, Julian From nobody Mon Jan 12 01:30:36 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F330E1A8A83; Mon, 12 Jan 2015 01:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPdj-mZmmykQ; Mon, 12 Jan 2015 01:30:32 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED8F1A8A65; Mon, 12 Jan 2015 01:30:32 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id DF15432E577; Mon, 12 Jan 2015 18:29:47 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 7f59_2c34_a9afb93b_81b0_4108_81fc_202249b90379; Mon, 12 Jan 2015 18:29:47 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 14027BF521; Mon, 12 Jan 2015 18:29:47 +0900 (JST) Message-ID: <54B3940A.6020308@it.aoyama.ac.jp> Date: Mon, 12 Jan 2015 18:29:46 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sean Leonard , Sam Ruby , Julian Reschke , Mark Nottingham References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2F4C3.5020008@seantek.com> In-Reply-To: <54B2F4C3.5020008@seantek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "pkix@ietf.org" , apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 09:30:35 -0000 On 2015/01/12 07:10, Sean Leonard wrote: > The security angle brings up another problem: the interoperable > transcription of URIs across systems. The ASCII range is a limited > repertoire, so it is easy to write it out unambiguously on paper, > display it on a TV screen, say it over the radio or a public service > announcement, or memorize it on your smartphone, in order to type it > into your web browser, the command-line, or any other system of choice. Many other writing systems are equally limited, and are easier to use=20 for those using them natively. Some writing systems in East Asia aren't=20 that limited, but have other mechanisms to just about allow the same=20 things to happen. > If you allow the enormous (and ever-expanding) range of Unicode > characters in "URIs", all of those use cases become fundamentally > ambiguous, inviting homograph attacks. Which smiley face out of nearly = a > hundred smiley emoji do you mean when you say "http://foo.com/=F0=9F=98= =8B" ?? Homograph attacks can happen, but only at points where different actors=20 can add to the same namespace. There are exceptions, but usually, the=20 path part isn't such an exception. Also, people using smileys in their IRIs and hoping that these get=20 easily copied are just shooting themselves in the foot. Just because it=20 turns out that using some Unicode characters in IRIs isn't necessarily a=20 good idea doesn't mean that we should exclude them all. > How > about an URI containing "=E1=BF=97" (U+1FD7 GREEK SMALL LETTER IOTA WIT= H > DIALYTIKA AND PERISPOMENI)--what composition or decomposition mode? Wha= t > if the combining accent mark code points are in a different order? > > *** > I have empathy for what Sam/the W3C wants, since the HTML protocol slot= s > basically beg to be filled with Unicode strings like href=3D"http://zh.wikipedia.org/wiki/=E5=B7=B4=E6=B3=B0=E5=8B=92=E7=B1=B3= =C2=B7=E6=B3=A2=E5=B2=A1=E9=81=94"> (instead of href=3D"http://zh.wikipedia.org/wiki/%E5%B7%B4%E6%B3%B0%E5%8B%92%E7%B1%= B3%C2%B7%E6%B3%A2%E5%B2%A1%E9%81%94">). Very very much so. The former is readable (although there are better=20 examples than foreign names such as Barth=C3=A9lemy Boganda) to a signifi= cant=20 part of the world's population; the later is gibberish for everybody. > But maybe the more interoperable approach is to define a format and > mechanism (e.g., IRIs, or something like IRIs v2) to map /from ///the > Unicode-capable protocol slots, /to/ the well-standardized RFC 3986 URI > format. With IRIs, that's essentially what we have. (of course I don't want to=20 imply that the IRI spec cannot be improved upon) Regards, Martin. From nobody Mon Jan 12 03:49:33 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046C11A8AFA for ; Mon, 12 Jan 2015 03:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4Trlf5Mwl1E for ; Mon, 12 Jan 2015 03:49:27 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0745.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::745]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4F501A8BB5 for ; Mon, 12 Jan 2015 03:47:50 -0800 (PST) Received: from pc6 (81.151.167.59) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.53.17; Mon, 12 Jan 2015 11:34:57 +0000 Message-ID: <017601d02e5b$a8616080$4001a8c0@gateway.2wire.net> From: t.petch To: "Murray S. Kucherawy" , Matthew Kerwin References: Date: Mon, 12 Jan 2015 11:24:53 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB4PR05CA0021.eurprd05.prod.outlook.com (25.160.40.31) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DB3PR07MB060; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DB3PR07MB060; X-Forefront-PRVS: 0454444834 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(51704005)(24454002)(189002)(13464003)(116806002)(230783001)(50226001)(62236002)(42186005)(44716002)(92566002)(87976001)(77156002)(122386002)(19580405001)(46102003)(14496001)(19580395003)(44736004)(33646002)(101416001)(93886004)(61296003)(106356001)(62966003)(105586002)(40100003)(81816999)(77096005)(15975445007)(81686999)(50986999)(76176999)(23676002)(68736005)(50466002)(86362001)(66066001)(97736003)(47776003)(64706001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2015 11:34:57.0808 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-kerwin-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 11:49:31 -0000 Meanwhile, back at the ranch, I remain an enthusiastic supporter of the adoption of this I-D by APPSAWG. Any URI scheme requires skills in the general issues of URIs (characters used, percent encoding, etc) and in the issues of resolution for the specific scheme and while there are other places where URIs surface in the IETF, I think that this is the only place where both skills are present. I see the objective, were it to be codified as such, as updating the file: scheme from the level of RFC1738 to the level of RFC3986 and not attempting to go beyond that. Tom Petch ----- Original Message ----- From: "Murray S. Kucherawy" To: "Matthew Kerwin" Cc: "IETF Apps Discuss" ; "Larry Masinter" Sent: Thursday, January 01, 2015 6:37 AM Subject: Re: [apps-discuss] Call for Adoption: draft-kerwin-file-scheme > On Wed, Dec 31, 2014 at 8:51 PM, Matthew Kerwin > wrote: > > > On 21 December 2014 at 05:55, Larry Masinter wrote: > > > >> > This opens a call for adoption for draft-kerwin-file-scheme, to be > >> processed by APPSAWG. > >> > >> I don't think apps area should take up kerwin-file-scheme as an > >> independent work item, not because the work isn't important but because > >> apps-discuss is too congested to manage the discussion (no responses to my > >> Dec 9 comments > >> https://www.ietf.org/mail-archive/web/apps-discuss/current/msg13462.html > >> ). In general, APPSAWG shouldn't take up URL-scheme permanent > >> registrations? Or should it? This should be addressed in the scheme > >> registration BCP. > >> > >> > > Sorry for not responding sooner, I've been a bit overwhelmed with real > > life, and there's quite a back-log of comments and messages to aggregate > > and process. > > > > Regarding adoption of URL schemes by this WG, what alternatives would you > > propose? I could instead try to make it an individual submission, but this > > particular scheme has a lot of political and emotional history, and there > > seems to be more and more work involved with developing the spec, so I'd > > rather have much more buy-in through the whole process (such as you get > > from a working group). I don't think it's big enough to warrant spinning up > > its own WG, and I'm not aware of any others that would be more appropriate > > than here. > > > > The BCP for registering schemes appears not to require an RFC, only Expert > Review. > > The guideline I've had in mind both for schemes and media types is this: If > there's a lot of development work to be done on the format of what's to be > registered, or if Standards Track status seems to be worthwhile or even > necessary, then a working group (this one or a new one) makes sense. On > the other hand, if it's mostly just documenting and then registering > something already quite well understood, I think the independent stream is > worth considering. Even better: If the required documentation could simply > be included in the registration template, then just do that, and then > there's no need to produce an RFC through any stream. > > An individual submission requires AD sponsorship, and I don't think this > has been shopped to any ADs yet (has it?). > > All that said, one of the earlier threads about this work certainly made me > think there's a non-trivial number of issues that need attention before > this one could be done right, so working group attention (this or a new > one) is warranted. If we want to spin off a WG for it, that's for Barry to > consider (anyone feel like writing a charter?). > > All THAT said, Larry's earlier message (URI cited above) does still need a > reply, I believe. If this draft does get adopted, that will be necessary > before we can progress the document. > > -MSK > ------------------------------------------------------------------------ -------- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Mon Jan 12 08:19:13 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830CE1AC3BF for ; Mon, 12 Jan 2015 08:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 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_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fa4nXclsljEb for ; Mon, 12 Jan 2015 08:19:11 -0800 (PST) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B1E1AC3BA for ; Mon, 12 Jan 2015 08:19:10 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id x12so11101949qac.11 for ; Mon, 12 Jan 2015 08:19:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:from:to:subject:importance:date:in-reply-to :references:content-type; bh=u1/qNhl5eEg/JyP8wuYR/qWD4yUmDZNYQbSgGZUPGQM=; b=n1wFKOYkbVZhJwQrpbMK+jSNMSfT77yC0MUlm5p0kWUvGq9tirp2AcvbwQXZzRqwzc VMa1wcPx2kXT+ZonqA0pHFccYXRzMPWMmVMO5J/VmrnSEnDB/fKF7kQKyHb493fv2ZzT 6QjWuh03OwwsUAovCoUVJPN0UM/V4LGH+ViIPPJvfY94hKLisASYWffTzpSIt1L43BnH HwW7+dUhvbW03SZxkj2JdwotOhHPeDLW3vl6wwUWdGNNCQdNbEyQe840CU/wCub3Q4TU FcjH2CvtU3D/BzxW2f+/2lBKLNnb2kGJNKrkS8d0/O60GsCLtoLw7IwcR9Q6F1PfIiNz bilA== X-Received: by 10.224.161.81 with SMTP id q17mr44179786qax.34.1421079550091; Mon, 12 Jan 2015 08:19:10 -0800 (PST) Received: from Pecan (MTRLPQ5031W-LP130-05-1096744000.dsl.bell.ca. [65.94.252.64]) by mx.google.com with ESMTPSA id g60sm15092752qgg.39.2015.01.12.08.19.09 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Jan 2015 08:19:09 -0800 (PST) Message-ID: <54b3f3fd.42208c0a.893a.1fcb@mx.google.com> MIME-Version: 1.0 From: To: =?utf-8?Q?IETF_Apps_Discuss?= Importance: Normal Date: Mon, 12 Jan 2015 16:03:38 +0000 In-Reply-To: <54B3316B.7040909@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2ABA8.6030205@gmx.de> <54B2C6FA.80802@intertwingly.net> <54B2EE08.9040705@gmx.de> <54B2F527.7040404@intertwingly.net> <54B2FB76.6040208@gmx.de>,<54B3316B.7040909@intertwingly.net> Content-Type: multipart/alternative; boundary="_CEB0D8F3-BA03-404F-898A-13D691D8A873_" Archived-At: Subject: Re: [apps-discuss] =?utf-8?q?character_repertoire_for_fragment_identi?= =?utf-8?q?fiers?= X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 16:19:12 -0000 --_CEB0D8F3-BA03-404F-898A-13D691D8A873_ Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" PiBGcm9tOiBTYW0gUnVieQ0KPiANCj4gQWdhaW4sIGl0IGlzIG15IGhvcGUvZXhwZWN0YXRpb24g dGhhdCBieSB5ZWFyIGVuZCBldmVyeSBzaW5nbGUgb25lIG9mIA0KPiB0aGUgcGFyc2VycyB0aGF0 IEkgaGF2ZSBsb29rZWQgb3V0ICh3aXRoIHRoZSBwb3NzaWJsZS9wcm9iYWJsZSBleGNlcHRpb24g DQo+IG9mIFBlcmwpIHdpbGwgTk9UIHBlcmNlbnQgZW5jb2RlIGZyYWdtZW50cy4NCj4g4oCmIA0K DQo+IA0KPiBJIGhhdmUgcHVibGlzaGVkIGEgbG90IG9mIHRlc3QgdmFsdWVzIHRoYXQgSSBhbSBs b29raW5nIGZvciBwZW9wbGUgdG8gDQo+IHdvcmsgdGhyb3VnaCB3aXRoIG1lLiAgQ29vcGVyYXRp b24gYW1vbmdzdCBicm93c2VyIHZlbmRvcnMgaW4gdGhpcyANCj4gZWZmb3J0IGlzIGluY3JlYXNp bmcuICBJIGhhdmUgeWV0IHRvIGZpbmQgYW55Ym9keSBvbiB0aGlzIGxpc3Qgd2lsbGluZyANCj4g dG8gbG9vayBhdCB0aGlzIGRhdGEuDQoNCg0KDQpJIGhhdmUgbG9va2VkIGF0IHRoZSB0ZXN0IGRh dGEuICBTcGVjaWZpY2FsbHkgSSBoYXZlIGxvb2tlZCBhdCB0aGUgY29tcGFyaXNvbnMgYmV0d2Vl biB0aGUgLk5FVCBmcmFtZXdvcmsgKGNzaGFycCkgVVJJIHBhcnNlciBhbmQgdGhlIHJlZmVyZW5j ZSBpbXBsZW1lbnRhdGlvbi4NCg0KDQpJ4oCZbSBub3Qgc3VyZSBob3cgeW91IGV2ZXIgZXhwZWN0 IHRvIG9idGFpbiBhIGNvbnNpc3RlbnQgcmVzdWx0IGJldHdlZW4gYSBsaWJyYXJ5IHRoYXQgcmV0 dXJucyBlcnJvcnMgYWxvbmcgd2l0aCBhIHBhcnNlZCByZXN1bHQgYW5kIG9uZSB0aGF0IHRocm93 cyBhbiBleGNlcHRpb24gYW5kIGFib3J0cyBwYXJzaW5nIHVwb24gZW5jb3VudGVyaW5nIGFuIGVy cm9yLiAgSXMgaXQgeW91ciBleHBlY3RhdGlvbiB0aGF0IHRoZSAuTmV0IGZyYW1ld29yayBzdG9w cyB0aHJvd2luZyBleGNlcHRpb25zIHdoZW4gVVJJIHBhcnNpbmc/DQoNCg0KQWxzbywgcmVnYXJk aW5nIGVzY2FwaW5nIG9mIGZyYWdtZW50IGlkZW50aWZpZXJzLCBpbiB5b3VyIGNzaGFycCB0ZXN0 IHByb2dyYW0geW91IHVzZSBVcmkuRnJhZ21lbnQsIHdoaWNoIGlzIGV4cGxpY2l0bHkgZG9jdW1l bnRlZCB0byByZXR1cm4gYW4gZXNjYXBlZCBmcmFnbWVudC4gIElmIHRoZSBkZXZlbG9wZXIgZG9l cyBub3Qgd2lzaCB0aGUgZnJhZ21lbnQgdG8gYmUgZXNjYXBlZCB0aGVuIHRoZXkgYXJlIGZyZWUg dG8gdXNlLA0KDQoNCg0KVXJpLkdldENvbXBvbmVudHMoVXJpQ29tcG9uZW50cy5GcmFnbWVudCwg VXJpRm9ybWF0LlVuZXNjYXBlZCkNCg0KDQpEaWZmZXJlbnQgbGFuZ3VhZ2VzIGRvIHRoaW5ncyBp biBkaWZmZXJlbnQgd2F5cy4gIFRyeWluZyBnZXQgZXZlcnkgVVJMIHBhcnNpbmcgbGlicmFyeSB0 byBiZWhhdmUgaWRlbnRpY2FsbHkganVzdCBmZWVscyBsaWtlIGFuIG9jZWFuIGJvaWxpbmcgZXhl cmNpc2UuIA0KDQoNCkRhcnJlbA== --_CEB0D8F3-BA03-404F-898A-13D691D8A873_ Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" CjxodG1sPgo8aGVhZD4KPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJXaW5kb3dzIE1h aWwgMTcuNS45NjAwLjIwNjg5Ij4KPHN0eWxlPjwhLS0KaHRtbCB7CmZvbnQtZmFtaWx5OiJDb2xv ciBFbW9qaSIsICJDYWxpYnJpIiwgIlNlZ29lIFVJIiwgIk1laXJ5byIsICJNaWNyb3NvZnQgWWFI ZWkgVUkiLCAiTWljcm9zb2Z0IEpoZW5nSGVpIFVJIiwgIk1hbGd1biBHb3RoaWMiLCAic2Fucy1z ZXJpZiI7Cn0KLS0+PC9zdHlsZT48c3R5bGUgZGF0YS1leHRlcm5hbHN0eWxlPSJ0cnVlIj48IS0t CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGggewptYXJnaW4tdG9wOjBpbjsKbWFyZ2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTow aW47Cm1hcmdpbi1sZWZ0Oi41aW47Cm1hcmdpbi1ib3R0b206LjAwMDFwdDsKfQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsIHsKbWFyZ2luOjBpbjsKbWFyZ2luLWJvdHRv bTouMDAwMXB0Owp9CnAuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgbGkuTXNvTGlzdFBhcmFn cmFwaEN4U3BGaXJzdCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIApwLk1zb0xpc3RQ YXJhZ3JhcGhDeFNwTWlkZGxlLCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCAKcC5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QsIGxp Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCB7 Cm1hcmdpbi10b3A6MGluOwptYXJnaW4tcmlnaHQ6MGluOwptYXJnaW4tYm90dG9tOjBpbjsKbWFy Z2luLWxlZnQ6LjVpbjsKbWFyZ2luLWJvdHRvbTouMDAwMXB0OwpsaW5lLWhlaWdodDoxMTUlOwp9 Ci0tPjwvc3R5bGU+PC9oZWFkPgo8Ym9keSBkaXI9Imx0ciI+CjxkaXYgZGF0YS1leHRlcm5hbHN0 eWxlPSJmYWxzZSIgZGlyPSJsdHIiIHN0eWxlPSJmb250LWZhbWlseTogJ0NhbGlicmknLCAnU2Vn b2UgVUknLCAnTWVpcnlvJywgJ01pY3Jvc29mdCBZYUhlaSBVSScsICdNaWNyb3NvZnQgSmhlbmdI ZWkgVUknLCAnTWFsZ3VuIEdvdGhpYycsICdzYW5zLXNlcmlmJztmb250LXNpemU6MTJwdDsiPgo8 ZGl2Pjxmb250IGZhY2U9IiAnQ2FsaWJyaScsICdTZWdvZSBVSScsICdNZWlyeW8nLCAnTWljcm9z b2Z0IFlhSGVpIFVJJywgJ01pY3Jvc29mdCBKaGVuZ0hlaSBVSScsICdNYWxndW4gR290aGljJywg J3NhbnMtc2VyaWYnIiBzdHlsZT0nbGluZS1oZWlnaHQ6IDE1cHQ7IGxldHRlci1zcGFjaW5nOiAw LjAyZW07IGZvbnQtZmFtaWx5OiAiQ2FsaWJyaSIsICJTZWdvZSBVSSIsICJNZWlyeW8iLCAiTWlj cm9zb2Z0IFlhSGVpIFVJIiwgIk1pY3Jvc29mdCBKaGVuZ0hlaSBVSSIsICJNYWxndW4gR290aGlj IiwgInNhbnMtc2VyaWYiOyBmb250LXNpemU6IDEycHQ7Jz48Yj4mZ3Q7IEZyb206PC9iPiZuYnNw OzxhIGhyZWY9Im1haWx0bzpydWJ5c0BpbnRlcnR3aW5nbHkubmV0IiB0YXJnZXQ9Il9wYXJlbnQi PlNhbSBSdWJ5PC9hPjxicj48L2ZvbnQ+PHN0cm9uZz48Zm9udCBmYWNlPSJDYWxpYnJpIEJvbGQi PiZndDsgPC9mb250Pjwvc3Ryb25nPjxicj48c3Ryb25nPjxmb250IGZhY2U9IkNhbGlicmkgQm9s ZCI+Jmd0OyA8L2ZvbnQ+PC9zdHJvbmc+QWdhaW4sIGl0IGlzIG15IGhvcGUvZXhwZWN0YXRpb24g dGhhdCBieSB5ZWFyIGVuZCBldmVyeSBzaW5nbGUgb25lIG9mIDxicj48c3Ryb25nPjxmb250IGZh Y2U9IkNhbGlicmkgQm9sZCI+Jmd0OyA8L2ZvbnQ+PC9zdHJvbmc+dGhlIHBhcnNlcnMgdGhhdCBJ IGhhdmUgbG9va2VkIG91dCAod2l0aCB0aGUgcG9zc2libGUvcHJvYmFibGUgZXhjZXB0aW9uIDxi cj48c3Ryb25nPjxmb250IGZhY2U9IkNhbGlicmkgQm9sZCI+Jmd0OyA8L2ZvbnQ+PC9zdHJvbmc+ b2YgUGVybCkgd2lsbCBOT1QgcGVyY2VudCBlbmNvZGUgZnJhZ21lbnRzLjxicj48c3Ryb25nPjxm b250IGZhY2U9IkNhbGlicmkgQm9sZCI+Jmd0OyA8L2ZvbnQ+PC9zdHJvbmc+4oCmIDwvZGl2Pjxk aXYgZGF0YS1zaWduYXR1cmVibG9jaz0idHJ1ZSI+PHN0cm9uZz48Zm9udCBmYWNlPSJDYWxpYnJp IEJvbGQiPiZndDsgPC9mb250Pjwvc3Ryb25nPjxicj48c3Ryb25nPjxmb250IGZhY2U9IkNhbGli cmkgQm9sZCI+Jmd0OyA8L2ZvbnQ+PC9zdHJvbmc+SSBoYXZlIHB1Ymxpc2hlZCBhIGxvdCBvZiB0 ZXN0IHZhbHVlcyB0aGF0IEkgYW0gbG9va2luZyBmb3IgcGVvcGxlIHRvIDxicj48c3Ryb25nPjxm b250IGZhY2U9IkNhbGlicmkgQm9sZCI+Jmd0OyA8L2ZvbnQ+PC9zdHJvbmc+d29yayB0aHJvdWdo IHdpdGggbWUuJm5ic3A7IENvb3BlcmF0aW9uIGFtb25nc3QgYnJvd3NlciB2ZW5kb3JzIGluIHRo aXMgPGJyPjxzdHJvbmc+PGZvbnQgZmFjZT0iQ2FsaWJyaSBCb2xkIj4mZ3Q7IDwvZm9udD48L3N0 cm9uZz5lZmZvcnQgaXMgaW5jcmVhc2luZy4mbmJzcDsgSSBoYXZlIHlldCB0byBmaW5kIGFueWJv ZHkgb24gdGhpcyBsaXN0IHdpbGxpbmcgPGJyPjxzdHJvbmc+PGZvbnQgZmFjZT0iQ2FsaWJyaSBC b2xkIj4mZ3Q7IDwvZm9udD48L3N0cm9uZz50byBsb29rIGF0IHRoaXMgZGF0YS48YnI+PC9kaXY+ PGRpdiBkYXRhLXNpZ25hdHVyZWJsb2NrPSJ0cnVlIj48YnI+PC9kaXY+PGRpdiBkYXRhLXNpZ25h dHVyZWJsb2NrPSJ0cnVlIj5JIGhhdmUgbG9va2VkIGF0IHRoZSB0ZXN0IGRhdGEuJm5ic3A7IFNw ZWNpZmljYWxseSBJIGhhdmUgbG9va2VkIGF0IHRoZSBjb21wYXJpc29ucyBiZXR3ZWVuIHRoZSAu TkVUIGZyYW1ld29yayAoY3NoYXJwKSBVUkkgcGFyc2VyIGFuZCB0aGUgcmVmZXJlbmNlIGltcGxl bWVudGF0aW9uLjwvZGl2PjxkaXYgZGF0YS1zaWduYXR1cmVibG9jaz0idHJ1ZSI+PGJyPjwvZGl2 PjxkaXYgZGF0YS1zaWduYXR1cmVibG9jaz0idHJ1ZSI+SeKAmW0gbm90IHN1cmUgaG93IHlvdSBl dmVyIGV4cGVjdCB0byBvYnRhaW4gYSBjb25zaXN0ZW50IHJlc3VsdCBiZXR3ZWVuIGEgbGlicmFy eSB0aGF0IHJldHVybnMgZXJyb3JzIGFsb25nIHdpdGggYSBwYXJzZWQgcmVzdWx0IGFuZCBvbmUg dGhhdCB0aHJvd3MgYW4gZXhjZXB0aW9uIGFuZCBhYm9ydHMgcGFyc2luZyB1cG9uIGVuY291bnRl cmluZyBhbiBlcnJvci4mbmJzcDsgSXMgaXQgeW91ciBleHBlY3RhdGlvbiB0aGF0IHRoZSAuTmV0 IGZyYW1ld29yayBzdG9wcyB0aHJvd2luZyBleGNlcHRpb25zIHdoZW4gVVJJIHBhcnNpbmc/PC9k aXY+PGRpdiBkYXRhLXNpZ25hdHVyZWJsb2NrPSJ0cnVlIj48YnI+PC9kaXY+PGRpdiBkYXRhLXNp Z25hdHVyZWJsb2NrPSJ0cnVlIj5BbHNvLCByZWdhcmRpbmcgZXNjYXBpbmcgb2YgZnJhZ21lbnQg aWRlbnRpZmllcnMsIGluIHlvdXIgY3NoYXJwIHRlc3QgcHJvZ3JhbSB5b3UgdXNlIFVyaS5GcmFn bWVudCwgd2hpY2ggaXMgZXhwbGljaXRseSBkb2N1bWVudGVkIHRvIHJldHVybiBhbiBlc2NhcGVk IGZyYWdtZW50LiZuYnNwOyBJZiB0aGUgZGV2ZWxvcGVyIGRvZXMgbm90IHdpc2ggdGhlIGZyYWdt ZW50IHRvIGJlIGVzY2FwZWQgdGhlbiB0aGV5IGFyZSBmcmVlIHRvIHVzZSw8L2Rpdj48ZGl2IGRh dGEtc2lnbmF0dXJlYmxvY2s9InRydWUiPjxmb250IGZhY2U9IkNvbnNvbGFzIiBzaXplPSI0Ij48 Zm9udCBmYWNlPSJDb25zb2xhcyIgc2l6ZT0iNCI+PC9mb250PjwvZm9udD48YnI+PC9kaXY+PGRp diBkYXRhLXNpZ25hdHVyZWJsb2NrPSJ0cnVlIj48Zm9udCBmYWNlPSJDb25zb2xhcyIgc2l6ZT0i NCI+PGZvbnQgZmFjZT0iQ29uc29sYXMiIHNpemU9IjQiPlVyaS5HZXRDb21wb25lbnRzKDwvZm9u dD48L2ZvbnQ+PGZvbnQgY29sb3I9IiMyYjkxYWYiIGZhY2U9IkNvbnNvbGFzIiBzaXplPSI0Ij48 Zm9udCBjb2xvcj0iIzJiOTFhZiIgZmFjZT0iQ29uc29sYXMiIHNpemU9IjQiPjxmb250IGNvbG9y PSIjMmI5MWFmIiBmYWNlPSJDb25zb2xhcyIgc2l6ZT0iNCI+VXJpQ29tcG9uZW50czwvZm9udD48 L2ZvbnQ+PC9mb250Pjxmb250IGZhY2U9IkNvbnNvbGFzIiBzaXplPSI0Ij48Zm9udCBmYWNlPSJD b25zb2xhcyIgc2l6ZT0iNCI+LkZyYWdtZW50LCA8L2ZvbnQ+PC9mb250Pjxmb250IGNvbG9yPSIj MmI5MWFmIiBmYWNlPSJDb25zb2xhcyIgc2l6ZT0iNCI+PGZvbnQgY29sb3I9IiMyYjkxYWYiIGZh Y2U9IkNvbnNvbGFzIiBzaXplPSI0Ij48Zm9udCBjb2xvcj0iIzJiOTFhZiIgZmFjZT0iQ29uc29s YXMiIHNpemU9IjQiPlVyaUZvcm1hdDwvZm9udD48L2ZvbnQ+PC9mb250Pjxmb250IGZhY2U9IkNv bnNvbGFzIiBzaXplPSI0Ij48Zm9udCBmYWNlPSJDb25zb2xhcyIgc2l6ZT0iNCI+LlVuZXNjYXBl ZCk8L2ZvbnQ+PC9mb250PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+RGlmZmVyZW50IGxhbmd1 YWdlcyBkbyB0aGluZ3MgaW4gZGlmZmVyZW50IHdheXMuJm5ic3A7IFRyeWluZyZuYnNwO2dldCBl dmVyeSBVUkwgcGFyc2luZyBsaWJyYXJ5IHRvIGJlaGF2ZSBpZGVudGljYWxseSBqdXN0IGZlZWxz IGxpa2UgYW4gb2NlYW4gYm9pbGluZyBleGVyY2lzZS4mbmJzcDs8L2Rpdj48ZGl2IGRhdGEtc2ln bmF0dXJlYmxvY2s9InRydWUiPjxicj48L2Rpdj48ZGl2IGRhdGEtc2lnbmF0dXJlYmxvY2s9InRy dWUiPkRhcnJlbDwvZGl2PjxkaXYgZGF0YS1zaWduYXR1cmVibG9jaz0idHJ1ZSI+PGJyPjwvZGl2 PgoKCjwvZGl2Pgo8L2JvZHk+CjwvaHRtbD4K --_CEB0D8F3-BA03-404F-898A-13D691D8A873_-- From nobody Mon Jan 12 09:01:54 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354B81AC3E0 for ; Mon, 12 Jan 2015 09:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5nATNLMqMNO for ; Mon, 12 Jan 2015 09:01:49 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FFF1AC3CF for ; Mon, 12 Jan 2015 09:01:48 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id x13so20464394wgg.12 for ; Mon, 12 Jan 2015 09:01:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MKidRaMwGrch9Fzt/XgU/2l1ZA6g7cTlHfyI8YTSFnA=; b=T6VMLpc/3c/gUcB+f9Lb9MEGymx5d2IAt0uPP4FJzsajneBdVzn59TLmYOI6WiNv3T 8gb8EmOg0vRB6QpnauIr4QJ+QMWWeVNLcErZ+PeVpCCbXvD4WsXZe2V+21WDb+fEdB1C ikJUoSdS6YZBrgZpdCm8JIHrCsVL8DeCVRp+GQo93VQp5sJTzAqQeB32OuHPh7xSeKER WkBGVzS9OUk+vbKGWOjfs/xKfK1Swx1o7RuqjAOva71YcE67ceACDd0cysZ1Via1/YhD hsFZqqHqp7GLCixjtKVwFDcArkn9WBl5FEiWDoAw4VSVT5yqL4m7mjnnsLiER9zVWNFB w94A== MIME-Version: 1.0 X-Received: by 10.180.91.36 with SMTP id cb4mr31560462wib.30.1421082107325; Mon, 12 Jan 2015 09:01:47 -0800 (PST) Received: by 10.27.204.198 with HTTP; Mon, 12 Jan 2015 09:01:47 -0800 (PST) In-Reply-To: References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 09:01:47 -0800 Message-ID: From: "Murray S. Kucherawy" To: Matthew Kerwin Content-Type: multipart/alternative; boundary=f46d043d67113434eb050c777602 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 17:01:51 -0000 --f46d043d67113434eb050c777602 Content-Type: text/plain; charset=UTF-8 On Sun, Jan 11, 2015 at 5:26 PM, Matthew Kerwin wrote: > As you can see below, the file: scheme draft has been adopted by the WG. > I'm in the process of writing a mini-charter, part of which is a list of > people who will commit to doing timely reviews of the document. > > Could I please ask for volunteers to provide reviews, whose names I can > list in the charter? > APPSAWG also regularly invites people other than the co-chairs to act as document shepherd for the documents we develop. If anyone would be interested in filling this role for this document, please email appsawg-chairs@tools.ietf.org. -MSK --f46d043d67113434eb050c777602 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jan 11, 2015 at 5:26 PM, Matthew Kerwin <mat= thew@kerwin.net.au> wrote:
As y= ou can see below, the file: scheme draft has been adopted by the WG. I'= m in the process of writing a mini-charter, part of which is a list of peop= le who will commit to doing timely reviews of the document.

Could I please ask for volunteers to provide r= eviews, whose names I can list in the charter?

APPSAWG also regularly invites people other than the co-cha= irs to act as document shepherd for the documents we develop.=C2=A0 If anyo= ne would be interested in filling this role for this document, please email= appsawg-chairs@tools.ietf= .org.

-MSK
--f46d043d67113434eb050c777602-- From nobody Mon Jan 12 09:11:50 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27D71ACCF6 for ; Mon, 12 Jan 2015 09:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ7XtR1JPDWq for ; Mon, 12 Jan 2015 09:11:47 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D731AC3B0 for ; Mon, 12 Jan 2015 09:11:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1421082706; x=2284996306; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=KUuxPjkL1I8gZTAP2akDMh6tFX59ApSXi+Wh/NfrxK8=; b=4ZkPgLbOQMbR7CfV4aSuzQLHGplSJZ86yqZJZFvJ+1am/9NfVxtW3L0K7L7bx8Kp dYnii3kkCswxVG8MaOYSBIuvgC6IPFScCern70tbGnPcWCVG7YlBR5tg6jt8sArk cdvtSM+saDQeLi7o133BVfBODCh6nO/YZiGUkHF4yxcwK74pliQw2tM5B71SBExE GY/QBhTGISyPYyWzcV5td0njbnvt6B8Y6Tb8XlsCv6zxikHdF3TXoJUm/De3Xorb uZX/S9Y0LkGDvdJQqNdneP/+8IOZR5Kh5SfobrDG9GfGFrRSJ84D7lS5n7uztH9U KRatECYB7xr0Lx2exaSjwQ==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 59.59.10337.25004B45; Mon, 12 Jan 2015 09:11:46 -0800 (PST) X-AuditID: 11973e13-f79c66d000002861-cc-54b40052d266 Received: from cilantro.apple.com (cilantro.apple.com [17.128.115.18]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 7D.6E.17961.95004B45; Mon, 12 Jan 2015 09:11:53 -0800 (PST) Received: from [17.153.46.254] (unknown [17.153.46.254]) by cilantro.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NI200ANOQFLCY50@cilantro.apple.com> for apps-discuss@ietf.org; Mon, 12 Jan 2015 09:11:46 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> Date: Mon, 12 Jan 2015 09:11:45 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUi2FAYrBvEsCXE4GuLpMXqlyvYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsej7R7aCd8IVe99OYmxg3CDQxcjBISFgInF7b2EXIyeQKSZx 4d56ti5GLg4hgb2MEo8mT2CCqbnb5AdSIyQwkUni21ENiJqZTBJtH6+ygNQwC6hLTJmSC1LD K6An0fTkMRNIjbDAdEaJz0e7GEESbAKqEg/mHAOzOQVsJCbsOsMEYrMAxedu3QMWZxbIlti4 /w07hK0t8eTdBVaQ+bxA9bdulELsfc8msfPyHxaQGhEBZYnv85ewQDwgK/Hv4hl2kCIJgY+s EhtebGWZwCg8C+G+WUjum4VkxQJG5lWMQrmJmTm6mXmmeokFBTmpesn5uZsYQSE83U54B+Pp VVaHGAU4GJV4eC2kNocIsSaWFVfmHmKU5mBREuddfmlDiJBAemJJanZqakFqUXxRaU5q8SFG Jg5OqQbGdKUF3stPqE/U+qOZpr9m4SaBkA9OCxml/C9xJP1+VhveGxx885qhIfNdLZX7X45W H5dzLm7dx/Z26kKhyBd76yK3nv6SuO/vDKd7IhG8J70VJz6f1THV42gpe5kii+p8/7fSmcdn sM07N9FBedIc70/crV/a/y3i0c/yvpMnJs8W/6Th1fI/SizFGYmGWsxFxYkAHZHb0UICAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FAspBvJsCXEYMZOIYvVL1ewOTB6LFny kymAMYrLJiU1J7MstUjfLoErY9H3j2wF74Qr9r6dxNjAuEGgi5GDQ0LAROJuk18XIyeQKSZx 4d56NhBbSGAik8S3oxpdjFxA9kwmibaPV1lA6pkF1CWmTMkFqeEV0JNoevKYCaRGWGA6o8Tn o12MIAk2AVWJB3OOgdmcAjYSE3adYQKxWYDic7fuAYszC2RLbNz/hh3C1pZ48u4CK8h8XqD6 WzdKIfa+Z5PYefkPC0iNiICyxPf5S1ggDpWV+HfxDPsERoFZCCfNQnLSLCRTFzAyr2IUKErN Saw01kssKMhJ1UvOz93ECA66wuAdjH+WWR1iFOBgVOLhtZDaHCLEmlhWXJl7iFGCg1lJhPfD Z6AQb0piZVVqUX58UWlOavEhRmkOFiVxXq/dM0OEBNITS1KzU1MLUotgskwcnFINjJbqGh73 0nYr1L6c8ilzVuTZ+8sX/86P3LD7mGWe3bZvDys0vMqOBXgIdJWyW/2TZvu0rfGiz4RnmhMd q/gdik84r3+vKa2d9Hn+52MrMhp683Ke8C6S8vvLfEvr+y4R5hurMmoOlC/Nlq66+n9mWu0q 04LZavcyrUUWOb9hVnwQLrtqvud+HSWW4oxEQy3mouJEAD3FZXg2AgAA Archived-At: Cc: "Julian F. Reschke" , apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 17:11:49 -0000 > On Jan 11, 2015, at 8:04 , Mark Nottingham wrote: >=20 > One more point of data -=20 > https://indiewebcamp.com/fragmention >=20 > Note that they=E2=80=99re using a second #, which isn=E2=80=99t = conformant to the URI ABNF. Interesting. When I wanted a URL scheme that had nested fragments, I = had to use =E2=80=9C*=E2=80=9D for the second, with the rule that when = de-nesting, the first * after the # that was being interpreted has to be = replaced by #. The use-case was =E2=80=98package formats=E2=80=99. Given a packaging = system that can pack anything, one can use the fragment syntax to = indicate some component of the package. But what do you do if that = component has a fragment syntax already and you want to use it? e.g. http://www.example.com/package.pkg#whatsit.htm*anchor >=20 > Cheers, >=20 >=20 >> On 11 Jan 2015, at 10:14 am, Sam Ruby wrote: >>=20 >> On 1/11/15 9:51 AM, Julian Reschke wrote: >>> On 2015-01-11 00:32, Sam Ruby wrote: >>>> ... >>>> As a concrete example, I believe that the repertoire of characters >>>> available for fragment identifiers should be expanded. >>>> ... >>>=20 >>> Could you provide a bit more information? Example for a character >>> missing? And the reason to add it? >>=20 >> More details available here: >>=20 >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D27252 >>=20 >> As luck would have it, I had a chance to discuss this with Tim = Berners-Lee in person on Wednesday. A typical URI parsing library will = treat everything after the hash mark as a fragment. >>=20 >> The current proposal can be found here: >>=20 >> https://specs.webplatform.org/url/webspecs/develop/#fragment >>=20 >> Here are the proposed set of conforming characters: >>=20 >> https://specs.webplatform.org/url/webspecs/develop/#url-code-points >>=20 >> Additionally, the presence of a percent sign not immediately followed = by two ASCII hex digits would also be a conformance error. >>=20 >>> Best regards, Julian >>=20 >> - Sam Ruby >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss David Singer Manager, Software Standards, Apple Inc. From nobody Mon Jan 12 09:19:52 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753F21ACD15 for ; Mon, 12 Jan 2015 09:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q573qUwWZWgk for ; Mon, 12 Jan 2015 09:19:45 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 495491ACCDE for ; Mon, 12 Jan 2015 09:19:45 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 032751DE060; Mon, 12 Jan 2015 09:19:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=v/T1//VZVM7qnk xS9iVkYZYxnmQ=; b=iooPTxDgFQcqw3U42gn6r+PqzPrtkZdyQ9KLfYhO9Xs08V RYtin34yVE01/1jhIN6X11FPyjaMyR4Z+Ck/+A3Ib9d9mu5kTJQP/M4N3yCOh3yB pmXJJ0Dx8C/7/s8g8pupncGWfTgsuWt/8qgDTnmd4o0ONjlOx/VQwtiUCooyg= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPA id 9D02E1DE059; Mon, 12 Jan 2015 09:19:44 -0800 (PST) Date: Mon, 12 Jan 2015 11:19:43 -0600 From: Nico Williams To: Matthew Kerwin Message-ID: <20150112171941.GJ16323@localhost> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <20150112054614.GG16323@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 17:19:49 -0000 On Mon, Jan 12, 2015 at 04:48:26PM +1000, Matthew Kerwin wrote: > On 12 January 2015 at 15:46, Nico Williams wrote: > > On Sun, Jan 04, 2015 at 10:22:59PM +1000, Matthew Kerwin wrote: > > > To be honest, a big reason for using RFC 3986 as a normative reference > > > is so I don't have to deal with things like hostnames. If those > > > definitions are good enough for the shiny new HTTP/1.1 (which actually > > > uses hostnames) then surely they're also sufficient for file: (which > > > often doesn't). > > > > The file scheme is a bit special though in that a hostname could appear > > outside the authority part of the URI, right? Hosts appearing there > > should be dealt with as any other non-authority part of an IRI when the > > IRI must be fed into a URI slot. > > > > OTOH, RFCs 3986 and 3987 apply, so if a hostname is to appear as an > > authority in a file scheme URI/IRI then you know what to do (because > > those RFCs tell you what to do). > > Hmm, I think there's an issue I should file[1]. So far I've hand-waved > the authority-in-path issue by deferring to Microsoft's UNC > definition, but it seems people would prefer to use the 'host' ABNF > construct to detect UNC-in-path URIs, and then have guidance for > translating the host to something UNC accepts (or not) before > dereferencing. I have no specific preference here. But you *must* pick one since otherwise we'd have two different ways of encoding IDNs in file URIs. If I had to pick... I think I'd want the hostname in the UNC to be treated as a URI authority (which means that IDNs would have to be ToASCII()'ed). But I could also go the other way. Would either alternative lead to ambiguities? Nico -- From nobody Mon Jan 12 09:43:04 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED7B1ACD07 for ; Mon, 12 Jan 2015 09:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBVcuH1qhrJZ for ; Mon, 12 Jan 2015 09:43:02 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 27C491ACCDE for ; Mon, 12 Jan 2015 09:43:02 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 044C7678063; Mon, 12 Jan 2015 09:43:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=UuqrSkUyEK1d/j l459dlCSykArM=; b=B9cxPC5ryIwfOral4KjddBBp4Co04KDy8mbqATviZTnfF+ NTUTpc5t8QGbuGvIrB39c5t2LWjdlaBW+A9O3eL75hYdrrrokyAtLKU0ttgDE5wk JR9b2orYkQlbLOt5gTYfVoY1GW5e+Gsb2SrAin+Jr+7TuTwlllVxZImuHy0Gk= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPA id 6C475678058; Mon, 12 Jan 2015 09:43:01 -0800 (PST) Date: Mon, 12 Jan 2015 11:43:00 -0600 From: Nico Williams To: Sam Ruby Message-ID: <20150112174259.GK16323@localhost> References: <54A5730C.8040501@ninebynine.org> <54A583DD.9010602@intertwingly.net> <54A59651.4060306@ninebynine.org> <54A59B26.5000408@intertwingly.net> <54A6AABF.4060406@ninebynine.org> <54A6B6DF.1010206@intertwingly.net> <54A7DC46.2020708@ninebynine.org> <54A7E9F4.80406@intertwingly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54A7E9F4.80406@intertwingly.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Graham Klyne , apps-discuss@ietf.org Subject: Re: [apps-discuss] presumption that RFC3986 is correct (was: New Version Notification for draft-kerwin-file-scheme-13.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 17:43:03 -0000 On Sat, Jan 03, 2015 at 08:09:08AM -0500, Sam Ruby wrote: > On 01/03/2015 07:10 AM, Graham Klyne wrote: > > > >3. Where there is divergence between implementations and RFC3986, these > >indeed should be considered on a case-by-case basis, but with (IMO) the > >presumption that RFC3986 is correct. I.e. it is for those who think > >there is a problem with RFC3986 to make the case. > > You ask me to presume that RFC 3986 is correct. That's a big ask. I think you may be missing some important things. URIs are restricted to US-ASCII because there are protocol slots where that's all that's allowed. IRIs are not restricted to US-ASCII, of course, and there is a mapping from IRIs to URIs for the purpose of being able to pass IRIs where only URIs are permitted. There are "URI slots" and "IRI slots", and mostly an implementor need only keep track of which is which, and what locale is used for user input and display, and convert accordingly. (Yes, there are ambiguities that result as described below; please read on.) This is critical. We (the IETF) cannot say that "hey, well, so sorry, but any protocol slots that only permitted US-ASCII will now have to magically permit UTF-8". Full stop. Full stop because: to go make such a decision we'd have to boil the oceans (fix all existing URI slots to be IRI slots -- fix as-deployed) or simply choose to ignore them. The latter is politically difficult: lots of implementors would be upset, and anyways, flag days are the sort of "nuclear option" we try to avoid at the IETF. But I think mostly you're failing to understand that all an implementor has to do is keep track of what kind of a slot anything is. Your mistake is VERY understandable: we're discussing filesystem issues, and filesystems are the premier example of an application where existing software historically lost, *regularly still* loses track of character strings' charset and encoding metadata. If so many apps just-use-whatever, why-can't-URIs-too-damn-it is a fair reaction. But it is not, IMO, a good reaction. Accepting just-use-whatever will lead to the situation getting worse. Use-and-expect-Unicode will tend to make the situation better, even though non-Unicode-and-non-ASCII will tend to leak from time to time, leading to aliasing issues. (This approach will tend to put pressure to perform codeset and encoding conversions at the edges where the required metadata is available. E.g., system call stubs, and so on.) Given this, if you accept that use-and-expect-Unicode is the better approach to dealing with filesystem object naming, then you can probably accept the need to keep track of what is a URI slot and what is an IRI slot, and convert as necessary. This is basically what RFCs 3986 and 3987 already require, and it's what others are telling you. There is a lot of context here. NFSv4 is a good place to start, because there the issues are very stark, but RFC3530 just papered over them, and we're periodically had to re-address them. See also: https://www.ietf.org/mail-archive/web/apps-discuss/current/msg13710.html Nico -- From nobody Mon Jan 12 09:56:02 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E571ACD1C for ; Mon, 12 Jan 2015 09:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpI-FDvNTKru for ; Mon, 12 Jan 2015 09:55:58 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2311ACD1B for ; Mon, 12 Jan 2015 09:55:58 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:6379] helo=rubix) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id BD/B8-23646-DAA04B45; Mon, 12 Jan 2015 17:55:57 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 2BF7C140B59 for ; Mon, 12 Jan 2015 12:55:58 -0500 (EST) Message-ID: <54B40AAD.9040400@intertwingly.net> Date: Mon, 12 Jan 2015 12:55:57 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2ABA8.6030205@gmx.de> <54B2C6FA.80802@intertwingly.net> <54B2EE08.9040705@gmx.de> <54B2F527.7040404@intertwingly.net> <54B2FB76.6040208@gmx.de>, <54B3316B.7040909@intertwingly.net> <54b3f3fd.42208c0a.893a.1fcb@mx.google.com> In-Reply-To: <54b3f3fd.42208c0a.893a.1fcb@mx.google.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: Subject: Re: [apps-discuss] character repertoire for fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 17:56:01 -0000 On 01/12/2015 11:03 AM, darrel.miller@gmail.com wrote: > *> From:* Sam Ruby > *> * > *> *Again, it is my hope/expectation that by year end every single one of > *> *the parsers that I have looked out (with the possible/probable > exception > *> *of Perl) will NOT percent encode fragments. > *> * > *> * > *> *I have published a lot of test values that I am looking for people to > *> *work through with me. Cooperation amongst browser vendors in this > *> *effort is increasing. I have yet to find anybody on this list willing > *> *to look at this data. > > I have looked at the test data. Specifically I have looked at the > comparisons between the .NET framework (csharp) URI parser and the > reference implementation. Thanks for doing this! > Im not sure how you ever expect to obtain a consistent result between a > library that returns errors along with a parsed result and one that > throws an exception and aborts parsing upon encountering an error. Is > it your expectation that the .Net framework stops throwing exceptions > when URI parsing? At the moment, I'm gathering data and sharing results. > Also, regarding escaping of fragment identifiers, in your csharp test > program you use Uri.Fragment, which is explicitly documented to return > an escaped fragment. If the developer does not wish the fragment to be > escaped then they are free to use, > > Uri.GetComponents(UriComponents.Fragment, UriFormat.Unescaped) Fixed. Thanks! https://github.com/webspecs/url/commit/1ac9fb4279f90f6c349ee8954159ea48e99cbdef https://url.spec.whatwg.org/interop/test-results/730127041a > Different languages do things in different ways. Trying get every URL > parsing library to behave identically just feels like an ocean boiling > exercise. In the case of browsers and HTML, different browsers doing different things was a major pain point, and large strides have been made over the past several years on addressing this. I hope to make things better (more compatible, more interoperable) for developers. If the best I can do is document what options need to be used to get compatible results, then that's what I will do. > Darrel - Sam Ruby From nobody Mon Jan 12 10:15:49 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD611ACD29; Mon, 12 Jan 2015 10:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbRdffL_6Kaa; Mon, 12 Jan 2015 10:15:41 -0800 (PST) Received: from homiemail-a110.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 039B01ACD2D; Mon, 12 Jan 2015 10:15:39 -0800 (PST) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id D6F642004EE91; Mon, 12 Jan 2015 10:15:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=kmyaTxkVkxj6EueriUSKhK8xRok=; b=yeVauIbmOW+ TdksHvl38RR7ovFTII/03N+Odr9flSCSfqmIeSZsRe1rI4mF0MLMC768XKtCysHP lD71ngcsTdx5et4iOzQNGRg6vctaPGwB41GmDjZpIfkqZyAh6awtE8ETB3PcEY0A WLwQqFH9R9aHik9vk/P/d7Y6vccp451o= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPA id 338972004EE90; Mon, 12 Jan 2015 10:15:38 -0800 (PST) Date: Mon, 12 Jan 2015 12:15:37 -0600 From: Nico Williams To: =?iso-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= Message-ID: <20150112181536.GN16323@localhost> References: <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2F4C3.5020008@seantek.com> <54B3940A.6020308@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <54B3940A.6020308@it.aoyama.ac.jp> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: Cc: apps-discuss@ietf.org, Julian Reschke , Mark Nottingham , "pkix@ietf.org" Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 18:15:43 -0000 On Mon, Jan 12, 2015 at 06:29:46PM +0900, "Martin J. D=C3=BCrst" wrote: > On 2015/01/12 07:10, Sean Leonard wrote: > >*** > >I have empathy for what Sam/the W3C wants, since the HTML protocol slo= ts > >basically beg to be filled with Unicode strings like >href=3D"http://zh.wikipedia.org/wiki/=E5=B7=B4=E6=B3=B0=E5=8B=92=E7=B1= =B3=C2=B7=E6=B3=A2=E5=B2=A1=E9=81=94"> (instead of >href=3D"http://zh.wikipedia.org/wiki/%E5%B7%B4%E6%B3%B0%E5%8B%92%E7%B1= %B3%C2%B7%E6%B3%A2%E5%B2%A1%E9%81%94">). >=20 > Very very much so. The former is readable (although there are better > examples than foreign names such as Barth=C3=A9lemy Boganda) to a > significant part of the world's population; the later is gibberish > for everybody. The href attribute in HTML is one thing. "_All_ URI/IRI slots" is another. I don't object to versioning protocols and data formats to change specific URI slots into IRI slots. Thus I have no objection to -say- the href attribute in HTML being made into an IRI slot (with or without versioning of HTML -- that being an issue for W3C, though if it were the IETF we'd want to do something better than a flag day). I object to any proposal that implies that all existing URI slots must now [magically] be able to carry Unicode non-ASCII character data. > >But maybe the more interoperable approach is to define a format and > >mechanism (e.g., IRIs, or something like IRIs v2) to map /from ///the > >Unicode-capable protocol slots, /to/ the well-standardized RFC 3986 UR= I > >format. We already have this: RFC 3987. > With IRIs, that's essentially what we have. (of course I don't want > to imply that the IRI spec cannot be improved upon) Exactly. Terminology is a problem here. In conversation and these e-mail threads, I really want to refer to IRIs as "URIs". But in the context of RFCs 3986 and 3987 it is critical to be careful to say "URI" in reference to "slots" accepting US-ASCII only, and "IRI" in reference to slots that notionally[*] accept Unicode. It would be very convenient if we only needed to be so careful when pairing "URI" and "IRI" with the word "slot". [*] I say notionally because related UI elements generally can only handle an equivalent subset when used in non-Unicode locales. Nico --=20 From nobody Mon Jan 12 10:19:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E0E1ACD18 for ; Mon, 12 Jan 2015 10:19:21 -0800 (PST) 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, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6yKa7QpDgx4 for ; Mon, 12 Jan 2015 10:19:16 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0786.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::786]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B04361ACD1F for ; Mon, 12 Jan 2015 10:19:15 -0800 (PST) Received: from pc6 (81.151.167.59) by DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) with Microsoft SMTP Server (TLS) id 15.1.53.17; Mon, 12 Jan 2015 18:18:52 +0000 Message-ID: <036301d02e94$15a95200$4001a8c0@gateway.2wire.net> From: t.petch To: "Murray S. Kucherawy" , Matthew Kerwin References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 18:17:30 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB4PR05CA0017.eurprd05.prod.outlook.com (25.160.40.27) To DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DBXPR07MB062; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DBXPR07MB062; X-Forefront-PRVS: 0454444834 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(51704005)(377454003)(13464003)(199003)(101416001)(44716002)(66066001)(64706001)(86362001)(77156002)(230783001)(62966003)(68736005)(77096005)(15975445007)(87976001)(1456003)(62236002)(105586002)(42186005)(47776003)(116806002)(19580405001)(19580395003)(61296003)(97736003)(50986999)(33646002)(44736004)(50226001)(40100003)(122386002)(50466002)(81816999)(23676002)(81686999)(76176999)(46102003)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB062; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB062; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2015 18:18:52.4253 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB062 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 18:19:21 -0000 Matthew Fascinating. My post earlier today was intended to prod whoever would declare consensus on adopting your I-D into declaring consensus. I am not sure what has happened, I see no statement of adoption in my Inbox or in the IETF archives but no matter, as long as the powers that be agree on adoption, that is fine. My earlier note also speculated on the powers that be wanting a charter change, in which case I proposed 'I see the objective, were it to be codified as such, as updating the file: scheme from the level of RFC1738 to the level of RFC3986 and not attempting to go beyond that. ' which remains what I will work toward. Changes to RFC3986/RFC3987 I regard as out of scope, bordering on a DoS attack. Tom Petch ----- Original Message ----- From: "Murray S. Kucherawy" To: "Matthew Kerwin" Cc: "IETF Apps Discuss" Sent: Monday, January 12, 2015 5:01 PM > On Sun, Jan 11, 2015 at 5:26 PM, Matthew Kerwin > wrote: > > > As you can see below, the file: scheme draft has been adopted by the WG. > > I'm in the process of writing a mini-charter, part of which is a list of > > people who will commit to doing timely reviews of the document. > > > > Could I please ask for volunteers to provide reviews, whose names I can > > list in the charter? > > > > APPSAWG also regularly invites people other than the co-chairs to act as > document shepherd for the documents we develop. If anyone would be > interested in filling this role for this document, please email > appsawg-chairs@tools.ietf.org. > > -MSK > ------------------------------------------------------------------------ -------- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Mon Jan 12 10:24:11 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372C01ACD34 for ; Mon, 12 Jan 2015 10:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApNzfgxtEjyo for ; Mon, 12 Jan 2015 10:24:05 -0800 (PST) Received: from homiemail-a112.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD721ACD2F for ; Mon, 12 Jan 2015 10:24:05 -0800 (PST) Received: from homiemail-a112.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTP id 233E7200EDEAE; Mon, 12 Jan 2015 10:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=j7Ct8ZeJdjKIHP jw9oG7WP+9VZE=; b=DLt6DVCfJF3SspQYtdTwvRZkDvn+XYHVf6+HjN9YFfMF7O NOmgnevW0tbbdmAh9OXkVdd2/XNKqcIVpnvluk7BuknPD/QCfzW+VRlzmfhWUJdt k4sIj2GVsi2skCIOw80t5jylS1xlmoiR6Rml4lFYDysjnzhxbBV7iqXDs5uD0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTPA id CEAC8200EDEAD; Mon, 12 Jan 2015 10:24:04 -0800 (PST) Date: Mon, 12 Jan 2015 12:24:04 -0600 From: Nico Williams To: Matthew Kerwin Message-ID: <20150112182402.GO16323@localhost> References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 18:24:07 -0000 On Mon, Jan 12, 2015 at 11:26:34AM +1000, Matthew Kerwin wrote: > Could I please ask for volunteers to provide reviews, whose names I can > list in the charter? I'll review. From nobody Mon Jan 12 10:33:42 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634F41ACD2D for ; Mon, 12 Jan 2015 10:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVtu1tPxPpsa for ; Mon, 12 Jan 2015 10:33:37 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF7E1A802F for ; Mon, 12 Jan 2015 10:33:36 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w61so20623056wes.1 for ; Mon, 12 Jan 2015 10:33:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AxEgB0PrDE4h3v+UGD9ET6AVA/jfLViNHeh0LuTKv7k=; b=q8vMMGvHM1DfLQ5WpGn24OcDmgoKfFfaxfNh4izf8/6hwv0gqpo4rvRaRi8AAKdQjF on9KP5zjSZiD5+cgUq2TBfDilNvTtGe9ReodDJmYmtA5lIt3FpBBoJZ252TSRaYpnnB2 OvBhFMuWfTNGN9iaK95Gp/jzPaFZkeG+5q+wXbNLBGJQ1IHR+fOyuTbCtMcPKFUXxiPJ 0jiemK/AI4t542Uv95eP2YQpVKBlVKeLc8qF2djXXLkeXFvLQk8nsyhifgg1AKqijN9i kDp6noeJuTiLijNjlL6sxa0yLTwGS2WNMiGIT6yWUsOkUQ/oruLsoagD9LZaJkX1Uhtx 4BsQ== MIME-Version: 1.0 X-Received: by 10.194.86.135 with SMTP id p7mr9439690wjz.89.1421087615375; Mon, 12 Jan 2015 10:33:35 -0800 (PST) Received: by 10.27.204.198 with HTTP; Mon, 12 Jan 2015 10:33:35 -0800 (PST) In-Reply-To: <036301d02e94$15a95200$4001a8c0@gateway.2wire.net> References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> <036301d02e94$15a95200$4001a8c0@gateway.2wire.net> Date: Mon, 12 Jan 2015 10:33:35 -0800 Message-ID: From: "Murray S. Kucherawy" To: "t.petch" Content-Type: multipart/alternative; boundary=089e0102e498826b86050c78be10 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 18:33:38 -0000 --089e0102e498826b86050c78be10 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 12, 2015 at 10:17 AM, t.petch wrote: > Matthew > > Fascinating. > > My post earlier today was intended to prod whoever would declare > consensus on adopting your I-D into declaring consensus. I am not sure > what has happened, I see no statement of adoption in my Inbox or in the > IETF archives but no matter, as long as the powers that be agree on > adoption, that is fine. > > My earlier note also speculated on the powers that be wanting a charter > change, in which case I proposed > > 'I see the objective, were it to be codified as such, as updating the > file: scheme from the level of RFC1738 to the level of RFC3986 and not > attempting to go beyond that. ' > > which remains what I will work toward. Changes to RFC3986/RFC3987 I > regard as out of scope, bordering on a DoS attack. > Apologies for the confusion, if any, which was likely my fault. I should have had the mini-charter drafted and sent out as part of the Call For Adoption rather than doing it after the fact. In the pre-holiday rush I got the order of operations backwards. We do still need to square that away before we can do any real work on the content. -MSK, slightly sheepish APPSAWG co-chair --089e0102e498826b86050c78be10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 12, 2015 at 10:17 AM, t.petch <ietfc@btconn= ect.com> wrote:
Matthew

Fascinating.

My post earlier today was intended to prod whoever would declare
consensus on adopting your I-D into declaring consensus.=C2=A0 I am not sur= e
what has happened, I see no statement of adoption in my Inbox or in the
IETF archives but no matter, as long as the powers that be agree on
adoption, that is fine.

My earlier note also speculated on the powers that be wanting a charter
change, in which case I proposed

'I see the objective, were it to be codified as such, as updating the file: scheme from the level of RFC1738 to the level of RFC3986 and not
attempting to go beyond that. '

which remains what I will work toward.=C2=A0 Changes to RFC3986/RFC3987 I regard as out of scope, bordering on a DoS attack.
Apologies for the confusion, if any, which was likely my fault.= =C2=A0 I should have had the mini-charter drafted and sent out as part of t= he Call For Adoption rather than doing it after the fact.=C2=A0 In the pre-= holiday rush I got the order of operations backwards.

We = do still need to square that away before we can do any real work on the con= tent.

-MSK, slightly sheepish APPSAWG co-chair
=
--089e0102e498826b86050c78be10-- From nobody Mon Jan 12 10:39:42 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C723F1ACD29 for ; Mon, 12 Jan 2015 10:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrbwNUspnOBT for ; Mon, 12 Jan 2015 10:39:39 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B8D921ACD18 for ; Mon, 12 Jan 2015 10:39:39 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 87F541005D; Mon, 12 Jan 2015 10:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=LBe6NxTJ6ezYAi mrVesNkptFGlc=; b=kvEGmUW0RmlNlf0y0zgn5JcjPCwZ7+1gMCiZ9yRV/BuCvu AF3y+usPFmJFMuNUbL+A4F0DzGiW5dNF9tKjLTzkTCKpgCaar6FzxDNFmpiZBBBO yinBJsUSYgPayvAzOQXSsY5aCGwETR2+e1lyR+NGC8iOmU9+iJvPBVWHPGaEY= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPA id 07EC71006E; Mon, 12 Jan 2015 10:39:38 -0800 (PST) Date: Mon, 12 Jan 2015 12:39:38 -0600 From: Nico Williams To: "t.petch" Message-ID: <20150112183935.GP16323@localhost> References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> <036301d02e94$15a95200$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <036301d02e94$15a95200$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 18:39:41 -0000 On Mon, Jan 12, 2015 at 06:17:30PM +0000, t.petch wrote: > My post earlier today was intended to prod whoever would declare > consensus on adopting your I-D into declaring consensus. I am not sure > what has happened, I see no statement of adoption in my Inbox or in the > IETF archives but no matter, as long as the powers that be agree on > adoption, that is fine. The fact that draft-ietf-appsawg-file-scheme-00 got submitted with a handle that starts with draft-ietf-appsawg- very strongly implies that the APPS chairs thought there was consensus to adopt (since the author could not have caused such an I-D to be accepted otherwise). > My earlier note also speculated on the powers that be wanting a charter > change, in which case I proposed > > 'I see the objective, were it to be codified as such, as updating the > file: scheme from the level of RFC1738 to the level of RFC3986 and not > attempting to go beyond that. ' I don't mind all sorts of informative language, but yes, as to RFCs 3986 and 3987: > which remains what I will work toward. Changes to RFC3986/RFC3987 I > regard as out of scope, bordering on a DoS attack. I agree most emphatically, at least if the proposed changes to those RFCs were to be backwards-incompatible ones. I doubt we'd reach consensus on backwards-incompatible changes to those two RFCs, but if we were to try, we should do that via an explicitly separate process (separate from the file URI I-D). Nico -- From nobody Mon Jan 12 11:15:44 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA571ACD3B for ; Mon, 12 Jan 2015 11:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTa4GDupTsyt for ; Mon, 12 Jan 2015 11:15:41 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E3C1ACD37 for ; Mon, 12 Jan 2015 11:15:41 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q59so20881298wes.10 for ; Mon, 12 Jan 2015 11:15:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c3YT2NWYS+G3qzNRezjq+CwVSapGKiUdTSe5x3FVi34=; b=CKQPdtYM1NXxKchDrt6KlBCSkj50FS1pW5Wze2TA4YoDMBqhNn8NJiUpY+b/wsEhuv vXgTKLmhp2m6Ba6lZFePiDfbrITWPPC704rb/0jiN3x8rRqK0lT2pT1un0DpHQyqwK3Q pBlF0WBce5ORkMD3DD9pdJulANkAHss4piQi7FNDBciXvx1H4QcT/tQEHlZCWzl2HsYV G1kjGwCl/SWXJ6JXWW2U851e6ZmaFBb4e5ysWiaI3PrOYvCD6h95K6wuz3i13pHu13IO bgAsD+LP7Y+gMRY5p8bm30NYwQC5NCzFIvbCzsuvn1ngDP9s2mxjcYjcPBenLJazoUdX Egsw== MIME-Version: 1.0 X-Received: by 10.194.86.135 with SMTP id p7mr9785712wjz.89.1421090136128; Mon, 12 Jan 2015 11:15:36 -0800 (PST) Received: by 10.27.204.198 with HTTP; Mon, 12 Jan 2015 11:15:36 -0800 (PST) In-Reply-To: <20150112183935.GP16323@localhost> References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> <036301d02e94$15a95200$4001a8c0@gateway.2wire.net> <20150112183935.GP16323@localhost> Date: Mon, 12 Jan 2015 11:15:36 -0800 Message-ID: From: "Murray S. Kucherawy" To: Nico Williams Content-Type: multipart/alternative; boundary=089e0102e498c204c5050c7954c0 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 19:15:43 -0000 --089e0102e498c204c5050c7954c0 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 12, 2015 at 10:39 AM, Nico Williams wrote: > On Mon, Jan 12, 2015 at 06:17:30PM +0000, t.petch wrote: > > My post earlier today was intended to prod whoever would declare > > consensus on adopting your I-D into declaring consensus. I am not sure > > what has happened, I see no statement of adoption in my Inbox or in the > > IETF archives but no matter, as long as the powers that be agree on > > adoption, that is fine. > > The fact that draft-ietf-appsawg-file-scheme-00 got submitted with a > handle that starts with draft-ietf-appsawg- very strongly implies that > the APPS chairs thought there was consensus to adopt (since the author > could not have caused such an I-D to be accepted otherwise). > Also correct. An email I sent to the author saying as much and inviting him to submit a WG-named version should have been sent to the list. -MSK, slightly more sheepish APPSAWG co-chair --089e0102e498c204c5050c7954c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 12, 2015 at 10:39 AM, Nico Williams <nic= o@cryptonector.com> wrote:
On M= on, Jan 12, 2015 at 06:17:30PM +0000, t.petch wrote:
> My post earlier today was intended to prod whoever would declare
> consensus on adopting your I-D into declaring consensus.=C2=A0 I am no= t sure
> what has happened, I see no statement of adoption in my Inbox or in th= e
> IETF archives but no matter, as long as the powers that be agree on > adoption, that is fine.

The fact that draft-ietf-appsawg-file-scheme-00 got submitted with a=
handle that starts with draft-ietf-appsawg- very strongly implies that
the APPS chairs thought there was consensus to adopt (since the author
could not have caused such an I-D to be accepted otherwise).

Also correct.=C2=A0 An email I sent to the author say= ing as much and inviting him to submit a WG-named version should have been = sent to the list.

-MSK, slightly more sheepish APPSAWG co= -chair
--089e0102e498c204c5050c7954c0-- From nobody Mon Jan 12 12:12:09 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15781ACDD2 for ; Mon, 12 Jan 2015 12:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZTe9UWNnOe2 for ; Mon, 12 Jan 2015 12:11:55 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC4641ACDDC for ; Mon, 12 Jan 2015 12:11:54 -0800 (PST) Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 8B765C404BB; Mon, 12 Jan 2015 14:12:49 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421093569; bh=Vr8QIcN1epfhVnEsXuBYbXW7eJdTpOh7yVxP88Uk2nc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=eDEbJARJ4g19+EbVXT8jzHkfeU3+XhODrFhLcU/Z1fdcE4VuY9PwOc2JmDAqiilAr Ypa+qQGYbdpzL1Sd5o6gmCQk3wZhvnCaAobrL4OFsN/9Uk32BaFDIjtn7xMzLHuyAM wFtb4UGvlcu2jZca6eFinjbNe4jo2M/BwGUIAvJQ= From: Scott Kitterman To: apps-discuss@ietf.org Date: Mon, 12 Jan 2015 15:11:52 -0500 Message-ID: <3168431.DdMjSJ6525@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-43-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> <20150112183935.GP16323@localhost> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 20:11:57 -0000 On Monday, January 12, 2015 11:15:36 Murray S. Kucherawy wrote: > On Mon, Jan 12, 2015 at 10:39 AM, Nico Williams > > wrote: > > On Mon, Jan 12, 2015 at 06:17:30PM +0000, t.petch wrote: > > > My post earlier today was intended to prod whoever would declare > > > consensus on adopting your I-D into declaring consensus. I am not sure > > > what has happened, I see no statement of adoption in my Inbox or in the > > > IETF archives but no matter, as long as the powers that be agree on > > > adoption, that is fine. > > > > The fact that draft-ietf-appsawg-file-scheme-00 got submitted with a > > handle that starts with draft-ietf-appsawg- very strongly implies that > > the APPS chairs thought there was consensus to adopt (since the author > > could not have caused such an I-D to be accepted otherwise). > > Also correct. An email I sent to the author saying as much and inviting > him to submit a WG-named version should have been sent to the list. This issue I've previously mentioned about IPR encumbered normative references is still present in the update. We really, really ought to have something as file: standardized in an unemcumbered manner. Scott K From nobody Mon Jan 12 14:24:57 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84681ACDB7 for ; Mon, 12 Jan 2015 14:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h37RB8olsetu for ; Mon, 12 Jan 2015 14:24:52 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA3F1ACD43 for ; Mon, 12 Jan 2015 14:24:52 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id nt9so950598obb.10 for ; Mon, 12 Jan 2015 14:24:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5vaQdJLL2uogbVTFrV78sZq7bYT26MZhBJvg5uuOfnA=; b=aLOlgFtAcp7nu3xPaWbmPmtE6vkshmqKRcxhdNfJp3NYutqfE/EFt11XyTQJhLa/vV E9ct4dZ7ivY4vR24S0FUMzZfum+uGNAloCo1/pdHodlUylvdfxktV9q1a+czQ8+VM4LK Gbmpazvz7l02aJx4L8pBb9PIqmMiBWXxLydNY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5vaQdJLL2uogbVTFrV78sZq7bYT26MZhBJvg5uuOfnA=; b=h3vNy4PnT9jHXO9eGYGzM8LJ3H2F60zWS5azOuFR4gBfhs3WhFFDGf8mHGqpaMjNSq Gae2X7GDeLeKFKfPEKT2xh32JPUsPs2awlkzKobDAp8XSNAwvXy9n6zK7uJpyv0u211h tC0uEaulg1lPZNoq22gbuMR8bsKn9nYP5EzKiobj08KjWOIb/xpM2SyHV1gEbitmKf0X Zvi7jIf3uB05IfJbQAvHyQd6pbk+FOI74ckDlnM95jL2qpwzA06nh6q+dDXM1gtV9kpB 1L1TtLtq9L5Qqlvg7W4Mk1p8qz8ktYDB1koYdfqfVwe8nLeL4upqxKmy0i2N1sqx2Wz+ Z/EQ== X-Gm-Message-State: ALoCoQnHw85TWWM55yhJnwLtSh0NGKyXxCcCB8RlyqfQoQlJ+e1veAf1OX8je+chXulYJ0O1zf/7 MIME-Version: 1.0 X-Received: by 10.202.212.210 with SMTP id l201mr17525287oig.117.1421101491714; Mon, 12 Jan 2015 14:24:51 -0800 (PST) Received: by 10.60.84.171 with HTTP; Mon, 12 Jan 2015 14:24:51 -0800 (PST) In-Reply-To: <54B2F527.7040404@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2ABA8.6030205@gmx.de> <54B2C6FA.80802@intertwingly.net> <54B2EE08.9040705@gmx.de> <54B2F527.7040404@intertwingly.net> Date: Mon, 12 Jan 2015 22:24:51 +0000 Message-ID: From: Dave Cridland To: Sam Ruby Content-Type: multipart/alternative; boundary=001a113d2da09a99f1050c7bf91b Archived-At: Cc: Julian Reschke , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] character repertoire for fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 22:24:55 -0000 --001a113d2da09a99f1050c7bf91b Content-Type: text/plain; charset=UTF-8 Sam, I'm getting really confused by what I suspect are differences in terminology. On 11 January 2015 at 22:11, Sam Ruby wrote: > On 01/11/2015 04:41 PM, Julian Reschke wrote: > >> I keep returning to URIs as things consisting of ASCII code points. >> > > Indeed you do. :-( > > I think that is their current definition, and I think that - outside of HTML at least - changing that definition would be hugely problematic. X.509 is one case where the existing syntactic definitions simply force ASCII. Also, I think this doesn't matter, of which more later... Now onto your use of terminology. From your quotation of Roy Fielding: > > This does not mean there isn't value in coming up with a consistent > > reference parsing model for HTML that reflects the browser > > Note that he makes the distinction between a "reference" and a URI. > I'd like to explore what Roy is suggesting: layering URLs on URIs, without > going through a URL layered on IRI layered on URI approach. Doing so may > require changes to both the definition of URLs and URIs. > > No, Roy is talking about References. References, of which the most popular form discussed is a Relative Reference (commonly - but incorrectly - called a relative URL), I understand to be "Things which can be put into an HREF attribute", loosely. Probably also a good model for interpreting random crap a user stuff into the address bar, too. One could reasonably argue that URIs are a proper subset of References. Let's assume that, if you don't object. In particular, I'd like to see how close we can come to a goal where the > output of URL parsing followed by URL stringification is always a valid URI. > > URLs I understand to be a proper subset of URIs; it's simply a URI which has protocol information for resolving the resource. The distinction is messy, but the subsetness isn't. IRIs are not a subset of URIs; instead they're a subset of References (assuming you're happy with URIs being such a subset). I think they have an intersection with URIs (ie, some URIs, at least, are also IRIs). > There is no question that a change to the "ASCII-ness" of schemes is > clearly a non-starter. But I would hope that we could discuss whether a > change to the "ASCII-ness" of fragments is a possibility. In particular, I > don't believe that there is any reason why a URL parser (in a browser or > elsewhere) needs to percent encode fragments. > > Well, you're clearly wrong, as has been discussed. However, I don't see any reason why we cannot have arbitrary unicode codepoints in a Reference whether or not it includes a fragment. We need it in domain names, paths, XMPP addresses, and plenty of other things, as well as fragments in HTTP References. Moreover, I think, judging from things you've said, that you also actually want Refernces to be uplifted to Unicode - not actual URIs. The current specification for doing so is the IRI spec, as Julian has pointed out a few times. If you think this specification is wrong (or could be done better, or even *is* practically done better by existing URL parsers) then I'm all ears. So just to summarize - if your goal is to have unicode in the (fairly obvious) places in a Reference in HTML, the browser address bar, and similar places that usually have a Reference rather than a URI, then I'm entirely behind you. If your goal is to have consistent parsing, I'm also 100% with you. If your goal is genuinely to redefine URI syntax and break every application aside from the web, I'm utterly opposed. Dave. --001a113d2da09a99f1050c7bf91b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sam,

I'm getting really confused by= what I suspect are differences in terminology.

On 11 January 2015 at 22:11, Sam Ruby <rubys@intertwingly.net> wrote:
On 01/11/2015 04:41 PM, Julian Reschke wrote:
I keep returning to URIs as things consistin= g of ASCII code points.

Indeed you do.=C2=A0 :-(


I think that is their current definiti= on, and I think that - outside of HTML at least - changing that definition = would be hugely problematic. X.509 is one case where the existing syntactic= definitions simply force ASCII. Also, I think this doesn't matter, of = which more later...

Now onto your use of terminolo= gy. From your quotation of Roy Fielding:
=C2=A0
> This does not mean there isn't value in coming up with a consisten= t
> reference parsing model for HTML that reflects the browser


Note that he makes the distinction between a &= quot;reference" and a URI.
=C2=A0
I'd like to explore what Roy is suggesting: layering URLs on URIs, with= out going through a URL layered on IRI layered on URI approach. Doing so ma= y require changes to both the definition of URLs and URIs.


No, Roy is talking about References. R= eferences, of which the most popular form discussed is a Relative Reference= (commonly - but incorrectly - called a relative URL), I understand to be &= quot;Things which can be put into an HREF attribute", loosely. Probabl= y also a good model for interpreting random crap a user stuff into the addr= ess bar, too.

One could reasonably argue that URIs= are a proper subset of References. Let's assume that, if you don't= object.

In particular, I'd like to see how close we can come to a goal where th= e output of URL parsing followed by URL stringification is always a valid U= RI.


URLs I understand to be a proper subse= t of URIs; it's simply a URI which has protocol information for resolvi= ng the resource. The distinction is messy, but the subsetness isn't.

IRIs are not a subset of URIs; instead they're a= subset of References (assuming you're happy with URIs being such a sub= set). I think they have an intersection with URIs (ie, some URIs, at least,= are also IRIs).
=C2=A0
There is no question that a change to the "ASCII-ness" of schemes= is clearly a non-starter.=C2=A0 But I would hope that we could discuss whe= ther a change to the "ASCII-ness" of fragments is a possibility.= =C2=A0 In particular, I don't believe that there is any reason why a UR= L parser (in a browser or elsewhere) needs to percent encode fragments.


Well, you're clearly wrong, as has= been discussed. However, I don't see any reason why we cannot have arb= itrary unicode codepoints in a Reference whether or not it includes a fragm= ent. We need it in domain names, paths, XMPP addresses, and plenty of other= things, as well as fragments in HTTP References. Moreover, I think, judgin= g from things you've said, that you also actually want Refernces to be = uplifted to Unicode - not actual URIs.

The current= specification for doing so is the IRI spec, as Julian has pointed out a fe= w times. If you think this specification is wrong (or could be done better,= or even *is* practically done better by existing URL parsers) then I'm= all ears.

So just to summarize - if your goal is = to have unicode in the (fairly obvious) places in a Reference in HTML, the = browser address bar, and similar places that usually have a Reference rathe= r than a URI, then I'm entirely behind you. If your goal is to have con= sistent parsing, I'm also 100% with you.

If yo= ur goal is genuinely to redefine URI syntax and break every application asi= de from the web, I'm utterly opposed.

Dave.
--001a113d2da09a99f1050c7bf91b-- From nobody Mon Jan 12 15:49:22 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BE41ACE13 for ; Mon, 12 Jan 2015 15:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSmmaQrvy5_6 for ; Mon, 12 Jan 2015 15:49:18 -0800 (PST) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 480071ACE0D for ; Mon, 12 Jan 2015 15:49:18 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id v8so7651017qal.7 for ; Mon, 12 Jan 2015 15:49:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=BepF+IHzfG1hAyyJEuGewPJnx6/vNVUEVHAP58xjjic=; b=EsqoEe8ZLOIfdzBSDzoDAyLEMCtz6LevlC02mpT8mcR4bLzkpIbYHrGs/FV+9c4Frf F153KBPgx3aZhWZ5G/MdQVmptBQ4xFGIj58V/8dNx75sVHEDuX4YQXFSUffIyJWMWCPr xguOesPURC1WTtCxH0ecuEB2gY18k39IheC1EiFUlpCbIBDXCEkgp9W89Nmx/UkDRkv8 /R+OlJpyJdLmEu/Pji5sdzpU3Yq0WYYh4mo0ceK/XJauDS0a1FqXzYl3fpfBvOMr+OMc qEG+fcHhuXsR+5Zn9SS+FU1zDPUgyRyi9G/myNNGlA+BPP2D7jbObwUvTZaTenax2pe5 Wdcw== MIME-Version: 1.0 X-Received: by 10.224.20.133 with SMTP id f5mr43709792qab.17.1421106557423; Mon, 12 Jan 2015 15:49:17 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Mon, 12 Jan 2015 15:49:17 -0800 (PST) In-Reply-To: <20150112182402.GO16323@localhost> References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> <20150112182402.GO16323@localhost> Date: Tue, 13 Jan 2015 09:49:17 +1000 X-Google-Sender-Auth: baViKoLBaGNdG7QgrmVKe7jN9wA Message-ID: From: Matthew Kerwin To: Nico Williams , Julian Reschke Content-Type: multipart/alternative; boundary=001a11c2b82e8b19d7050c7d275b Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jan 2015 23:49:20 -0000 --001a11c2b82e8b19d7050c7d275b Content-Type: text/plain; charset=UTF-8 On 13 January 2015 at 04:24, Nico Williams wrote: > On Mon, Jan 12, 2015 at 11:26:34AM +1000, Matthew Kerwin wrote: > > Could I please ask for volunteers to provide reviews, whose names I can > > list in the charter? > > I'll review. > Thanks Nico and Julian. -- Matthew Kerwin http://matthew.kerwin.net.au/ --001a11c2b82e8b19d7050c7d275b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 13 January 2015 at 04:24, Nico Williams <= nico@cryptonecto= r.com> wrote:
On Mon, Jan 12, 2015 at 11:26:34AM +1000, Matthew Kerwin wrote:
> Could I please ask for volunteers to provide reviews, whose names I ca= n
> list in the charter?

I'll review.

Thanks Nic= o and Julian.

--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a11c2b82e8b19d7050c7d275b-- From nobody Mon Jan 12 16:01:36 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0BE1ACE1C for ; Mon, 12 Jan 2015 16:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.427 X-Spam-Level: X-Spam-Status: No, score=-0.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydnAw9NLPVzt for ; Mon, 12 Jan 2015 16:01:28 -0800 (PST) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED651ACE26 for ; Mon, 12 Jan 2015 16:01:25 -0800 (PST) Received: by mail-qg0-f43.google.com with SMTP id z107so20263648qgd.2 for ; Mon, 12 Jan 2015 16:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=sUh9jJWe/Ce+zrbCLgeC6bXAPEmOgjJucKSw0SwjSj4=; b=c+tkLs9GX/KcP9MhVky7RoE68aNiVCVKOIIylcmQ2MAKebwohniQkpLgIx3TAWQBfj y8RGNwACilouanm1QxBMWoc2hGLO/CfehpTv94CHnrwIqBmXhXjVFTCw6S3ZL1tf8YOD +TWCF3ZSr/YEBbRI961HXAn8liLpWXJlPAfaAup+1vTxOdXo0IWimX7mt+hd8jFiz1r8 O18r8ySltMiZRMMHGK5GLXfn12BhIUSdgEw4LQTJX+BMxD2j8l1gVgh0bz2Cn9MZT9d9 Ckp+FI3ki2Rr2zlU+1RcN6RWumTP2JQKaxpHK8lo10gL1wJGK6OQpa0tuKI/i7HuqaVn fFOw== MIME-Version: 1.0 X-Received: by 10.140.97.102 with SMTP id l93mr50824660qge.48.1421107285134; Mon, 12 Jan 2015 16:01:25 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Mon, 12 Jan 2015 16:01:25 -0800 (PST) In-Reply-To: <036301d02e94$15a95200$4001a8c0@gateway.2wire.net> References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> <036301d02e94$15a95200$4001a8c0@gateway.2wire.net> Date: Tue, 13 Jan 2015 10:01:25 +1000 X-Google-Sender-Auth: a-lV3sc0nS1_MMl8WKmTppAhd4o Message-ID: From: Matthew Kerwin To: "t.petch" Content-Type: multipart/alternative; boundary=001a113a9e72eb17bf050c7d527b Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 00:01:31 -0000 --001a113a9e72eb17bf050c7d527b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 13 January 2015 at 04:17, t.petch wrote: > > My earlier note also speculated on the powers that be wanting a charter > change, in which case I proposed > > 'I see the objective, were it to be codified as such, as updating the > file: scheme from the level of RFC1738 to the level of RFC3986 and not > attempting to go beyond that. ' > > which remains what I will work toward. Changes to RFC3986/RFC3987 I > regard as out of scope, bordering on a DoS attack. > > =E2=80=8BYes, that's essentially my goal. I've written this: | The "file" URI scheme is woefully out of date. The document that defines | it, RFC 1738, has been superseded by the generic URI syntax of RFC 3986, | and its status is listed as "Obsolete". As such, the "file" URI scheme | is viewed by many in the internet community as being without a current | defining standard, and in need of updating to match current standards | and implementations. | | This document defines an updated "file" URI scheme, promoting | interoperability by being compatible with the generic syntax of | RFC 3986, while enumerating commonly-encountered variations that have | arisen during the scheme's long history of vague standardisation. | | Reviewers: | | * Julian Reschke | * Nico Williams | * Sean Leonard Does that suit?=E2=80=8B If so I'll give it to Murray to put in the wiki. --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a113a9e72eb17bf050c7d527b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 13 January 2015 at 04:17, t.petch <ietfc@btconnect.com&g= t; = wrote:

My earlier note also speculated on the powers that be wanting a charter
change, in which case I proposed

'I see the objective, were it to be codified as such, as updating the file: scheme from the level of RFC1738 to the level of RFC3986 and not
attempting to go beyond that. '

which remains what I will work toward.=C2=A0 Changes to RFC3986/RFC3987 I regard as out of scope, bordering on a DoS attack.


=E2=80= =8BYes, that's essentially my goal. I've written this:

| The "file&quo= t; URI scheme is woefully out of date. The document that defines
|=C2=A0it, RFC 1738, has been superseded by the generic URI syntax of RFC 3986,=
|=C2=A0and its status is listed as "Obsolete". As such, th= e "file" URI scheme
|=C2=A0is viewed by many in the interne= t community as being without a current
|=C2=A0defining standard, and = in need of updating to match current standards
|= =C2=A0and implementa= tions.
|
|=C2=A0This document defines an updated &qu= ot;file" URI scheme, promoting
|=C2=A0interoperability by being = compatible with the generic syntax of
|=C2=A0RFC 3986, while enumerat= ing commonly-encountered variations that have
|= =C2=A0arisen during = the scheme's long history of vague standardisation.
|
<= /font>
|=C2=A0Reviewers:
|
|=C2= =A0* Julian Reschke = <julian.reschke@gmx.de><= /font>
|=C2=A0* Nico Williams <n= ico@cryptonector.com>
|=C2=A0* Sean Leonard <dev+ietf@seantek.com>


Does that suit?=E2=80=8B If so I'll give it to M= urray to put in the wiki.


--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.ke= rwin.net.au/
--001a113a9e72eb17bf050c7d527b-- From nobody Mon Jan 12 16:18:51 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1EF1ACE4F for ; Mon, 12 Jan 2015 16:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYCecVk7miE0 for ; Mon, 12 Jan 2015 16:18:47 -0800 (PST) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32B11ACE42 for ; Mon, 12 Jan 2015 16:18:47 -0800 (PST) Received: by mail-qg0-f54.google.com with SMTP id l89so20282179qgf.13 for ; Mon, 12 Jan 2015 16:18:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vfr/kQiYYsfLTRhEZx1guksrY0jHc5SD/Hu6K/Gz4Is=; b=K+hYvcHEVtzr0oSo/tSnFB0Tyeu70KRs9oUTvnTVTzubscx+YKXBNMZzBauNeIp5M5 Jl0U7xTB/1OS+6msAPlj+CGuqzsh7j5XAZQx7VyJOvxZXIPBD69k/ZKqBsHprishx6XT myySXc/KdAwSeRRwLr7KdcLld3Uws6FUfQXTbllef5WrX659qnCf4oqvSLYgAIsovsfV 5RpoHct8SmOfJw3HLg/lW40NX0PJ+SsetFBvReENqRGM/sgtEhRe+QWOfQXFJ9PuEuUk YbaXRn6ANOgRkIvFt9r5fH1UoQMFYs+QfTndu5Nf2QGZmo8ZuTRxfu/Wx5NhDg6lHBrA n9xw== MIME-Version: 1.0 X-Received: by 10.224.29.209 with SMTP id r17mr40339178qac.67.1421108326718; Mon, 12 Jan 2015 16:18:46 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Mon, 12 Jan 2015 16:18:46 -0800 (PST) In-Reply-To: <3168431.DdMjSJ6525@scott-latitude-e6320> References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> <20150112183935.GP16323@localhost> <3168431.DdMjSJ6525@scott-latitude-e6320> Date: Tue, 13 Jan 2015 10:18:46 +1000 X-Google-Sender-Auth: 6sp2tEBph5W99hS9ktnBhNPclLo Message-ID: From: Matthew Kerwin To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7bdc17920064fb050c7d91a9 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 00:18:49 -0000 --047d7bdc17920064fb050c7d91a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 13 January 2015 at 06:11, Scott Kitterman wrote: > > This issue I've previously mentioned about IPR encumbered normative > references > is still present in the update. We really, really ought to have somethin= g > as > file: standardized in an unemcumbered manner. > > Scott K > > The update I submitted only changed metadata (name, date, working group), so all the open issues remain. =E2=80=8BThat said, I heartily agree. I'm trying to look up the conversatio= n where somebody originally suggested I use MS-DTYP as the normative reference, instead of trying to redefine it myself, as that might provide some guidance. In the meantime I've created an open issue, because it's something that definitely needs to be resolved. Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --047d7bdc17920064fb050c7d91a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 13 January 2015 at 06:11, Scott Kitterman <scott@kitterman.com&= gt;= wrote:
<= br>
This issue I've previously mentioned about IPR encumbered n= ormative references
is still present in the update.=C2=A0 We really, really ought to have somet= hing as
file: standardized in an unemcumbered manner.

Scott K

=

The update I submitted only c= hanged metadata (name, date, working group), so all the open issues remain.=

=E2=80=8BThat said, I h= eartily agree. I'm trying to look up the conversation where somebody or= iginally suggested I use MS-DTYP as the normative reference, instead of try= ing to redefine it myself, as that might provide some guidance.

In the meantime I've created an open issue, becau= se it's something that definitely needs to be resolved.

Cheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--047d7bdc17920064fb050c7d91a9-- From nobody Mon Jan 12 16:24:59 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0C21ACE30 for ; Mon, 12 Jan 2015 16:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64ac_tJ1ZpbI for ; Mon, 12 Jan 2015 16:24:55 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7A61ACE29 for ; Mon, 12 Jan 2015 16:24:54 -0800 (PST) Received: by mail-qg0-f42.google.com with SMTP id q108so62589qgd.1 for ; Mon, 12 Jan 2015 16:24:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=bS/n4/QTC9hg9SmGyBo/Bv5YsmhjuAkPG8sCYIPTnbo=; b=yagrQ07JgRZvF1XhQblc6BLHj+IA2EohDqF+apyP3uIv1ztTNiZScmpJ8fdFQp4wHL eOaNF5wDONcnfOdjor5OhMu23G5mTm8dRN/76JU1AQaFEEaNP9jLeIqk+qyzqEzpNCo7 MP2Obq6sJybNesvzXr0GRhG34jBbwKXcqZoFa8kVW7o3lCVFX6Ug10eCcRaBXXBiIe76 UlLV3UzsudZZrK3oYwx8rUG7ax2S2EHFiLga3NK6mJUUgCfhHj16aUqYaNiu13rYWbER KGSUeFVqM+mRWjNSVUvOmivOOtNYyOt3B2Ky7Um3Ul8aE2445gxQh0qAx+Pjjplsg8hY iUbQ== MIME-Version: 1.0 X-Received: by 10.140.107.73 with SMTP id g67mr51175161qgf.103.1421108694162; Mon, 12 Jan 2015 16:24:54 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Mon, 12 Jan 2015 16:24:54 -0800 (PST) In-Reply-To: References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> <20150112183935.GP16323@localhost> <3168431.DdMjSJ6525@scott-latitude-e6320> Date: Tue, 13 Jan 2015 10:24:54 +1000 X-Google-Sender-Auth: q0rI7W1fQ4klEfJtiCEaY7UVF64 Message-ID: From: Matthew Kerwin To: Scott Kitterman , Dave Thaler Content-Type: multipart/alternative; boundary=001a113a7c02e7226a050c7da6fc Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 00:24:56 -0000 --001a113a7c02e7226a050c7da6fc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 13 January 2015 at 10:18, Matthew Kerwin wrote: > On 13 January 2015 at 06:11, Scott Kitterman wrote: > >> >> This issue I've previously mentioned about IPR encumbered normative >> references >> is still present in the update. We really, really ought to have >> something as >> file: standardized in an unemcumbered manner. >> >> Scott K >> >> > =E2=80=8BThat said, I heartily agree. I'm trying to look up the conversat= ion where > somebody originally suggested I use MS-DTYP as the normative reference, > instead of trying to redefine it myself, as that might provide some > guidance. > > Ah, it was an early review from Dave Thaler. Dave, do you have any advice here? Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a113a7c02e7226a050c7da6fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 13 January 2015 at 10:18, Matthew Kerwin <matthew@ker= win.net.au> wrote:
On 1= 3 January 2015 at 06:11, Scott Kitterman <scott@kitterman.com> wrote:<= br>

This issue I've previously mentioned about IPR encumbered n= ormative references
is still present in the update.=C2=A0 We really, really ought to have somet= hing as
file: standardized in an unemcumbered manner.

Scott K

= =E2=80=8BThat said, I heartily agree. I'm trying to look up the convers= ation where somebody originally suggested I use MS-DTYP as the normative re= ference, instead of trying to redefine it myself, as that might provide som= e guidance.


<= /div>
Ah, it was an early review from Dave Thaler.
<= br>
Dave, do you have any advice here?

Cheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a113a7c02e7226a050c7da6fc-- From nobody Mon Jan 12 18:10:43 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3F21A1AB2 for ; Mon, 12 Jan 2015 18:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4EinfJddkj8 for ; Mon, 12 Jan 2015 18:10:37 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F301A899C for ; Mon, 12 Jan 2015 18:10:35 -0800 (PST) Received: (qmail 8729 invoked from network); 13 Jan 2015 02:10:33 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 13 Jan 2015 02:10:33 -0000 Date: 13 Jan 2015 02:10:11 -0000 Message-ID: <20150113021011.18290.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 02:10:41 -0000 >> I haven't tested it or even considered this use case when I set up the >> server, but the Postfix version I use is less than ten years old and I do use >> DKIM. So I think it's worth trying: Send me mail with an entropy-rich ENVID >> and NOTIFY=SUCCESS,FAILURE, and see if you get back a DKIM-signed success >> DSN. > >OK, I need to check also my Postfix setup for the ENVID, and then I'll >make the test! back later... Don't forget to check whether the d= domain in the DKIM signature has any perceptible relationship to the recipient address. R's, John From nobody Mon Jan 12 18:45:47 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E15E1A89AE for ; Mon, 12 Jan 2015 18:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImpeCmagf33p for ; Mon, 12 Jan 2015 18:45:42 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 084E51A89AC for ; Mon, 12 Jan 2015 18:45:42 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id E17B832E0BC; Tue, 13 Jan 2015 11:44:56 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 399f_4b4c_e9b3f070_5014_4b55_9f92_5448613ba97c; Tue, 13 Jan 2015 11:44:56 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 68721BF4DE; Tue, 13 Jan 2015 11:44:56 +0900 (JST) Message-ID: <54B486A7.1090306@it.aoyama.ac.jp> Date: Tue, 13 Jan 2015 11:44:55 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: David Singer , Mark Nottingham References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4 c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Julian F. Reschke" , apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 02:45:44 -0000 On 2015/01/13 02:11, David Singer wrote: > Interesting. When I wanted a URL scheme that had nested fragments, I h= ad to use =E2=80=9C*=E2=80=9D for the second, with the rule that when de-= nesting, the first * after the # that was being interpreted has to be rep= laced by #. > e.g. http://www.example.com/package.pkg#whatsit.htm*anchor Did you ever think about/check out http://www.example.com/package.pkg#whatsit.htm%23anchor ? (# being ASCII 0x23) Regards, Martin. From nobody Mon Jan 12 19:12:15 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF151A1B29 for ; Mon, 12 Jan 2015 19:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHZRzABd8uPl for ; Mon, 12 Jan 2015 19:12:11 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 74B7B1A89FB for ; Mon, 12 Jan 2015 19:11:58 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 87FB832E52E; Tue, 13 Jan 2015 12:11:13 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 399f_517e_efefb83f_c9a2_4985_a95a_6c09ff633504; Tue, 13 Jan 2015 12:11:13 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 06B2EBF4E3; Tue, 13 Jan 2015 12:11:13 +0900 (JST) Message-ID: <54B48CCF.2010001@it.aoyama.ac.jp> Date: Tue, 13 Jan 2015 12:11:11 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Dave Cridland , Sam Ruby References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@in tertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2ABA8.6030205@gmx.de> <54B2C6FA.80802@intertwingly.net> <54B2EE08.9040705@gmx.de> <54B2F527.7040404@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Julian Reschke , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] character repertoire for fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 03:12:13 -0000 On 2015/01/13 07:24, Dave Cridland wrote: > IRIs are not a subset of URIs; instead they're a subset of References > (assuming you're happy with URIs being such a subset). I think they have an > intersection with URIs (ie, some URIs, at least, are also IRIs). IRIs are a superset of URIs, by definition. So all URIs are IRIs. Regards, Martin. From nobody Mon Jan 12 21:35:02 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCA61A89B4 for ; Mon, 12 Jan 2015 21:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9kd9PBC9TKj for ; Mon, 12 Jan 2015 21:34:56 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0625.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::625]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D52171A89B0 for ; Mon, 12 Jan 2015 21:34:55 -0800 (PST) Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) with Microsoft SMTP Server (TLS) id 15.1.53.17; Tue, 13 Jan 2015 05:34:32 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) by DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) with mapi id 15.01.0053.000; Tue, 13 Jan 2015 05:34:32 +0000 From: Larry Masinter To: Scott Kitterman , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt Thread-Index: AQHQLgTmnMWajSyXJEmPfvlJmBL/1Jy7sZAAgAEFTICAABXY7IAABX8AgAAKDACAAA+5AIAAmyCA Date: Tue, 13 Jan 2015 05:34:32 +0000 Message-ID: References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> <20150112183935.GP16323@localhost> <3168431.DdMjSJ6525@scott-latitude-e6320> In-Reply-To: <3168431.DdMjSJ6525@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:9:8380:992:c406:2de7:93b9:2f7b] authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DM2PR0201MB0960; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB0960; x-forefront-prvs: 045584D28C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(13464003)(24454002)(189002)(51704005)(377454003)(97736003)(54206007)(77156002)(62966003)(2656002)(87936001)(76576001)(99286002)(40100003)(107886001)(105586002)(122556002)(106116001)(74316001)(101416001)(106356001)(102836002)(54606007)(15975445007)(46102003)(19580395003)(33656002)(16601075003)(64706001)(76176999)(50986999)(54356999)(86362001)(19580405001)(2900100001)(92566002)(93886004)(230783001)(2950100001)(587094005)(68736005)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0960; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2015 05:34:32.0843 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB0960 Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 05:34:58 -0000 SSdtIHN0aWxsIG5vdCBzdXJlICB3aGF0IHRoZSBwcm9ibGVtIGlzIHdpdGggSVBSLWVuY3VtYmVy ZWQgbm9ybWF0aXZlIHJlZmVyZW5jZXMuIFRoYXQgc2FpZCwgSSdkIHByZWZlciBhIGxpc3QgKElB TkEgcmVnaXN0cnk/KSBvZiBPUytmaWxlc3lzdGVtcyBhbmQgT1MrZmlsZXN5c3RlbS1zcGVjaWZp YyAiZmlsZToiIG1hcHBpbmdzLCB3aGljaCBjb3VsZCBiZSB2ZW5kb3Itc3VwcGxpZWQgb3IgSW5m b3JtYXRpb25hbCwgcmF0aGVyIHRoYW4gc3RhbmRhcmRzIHRyYWNrLiANCg0KRXZlbiB0aGluZ3Mg bGlrZSBjYXNlLXNlbnNpdGl2aXR5IGluIGZpbGUgc3lzdGVtcyBpcyBsaWtlbHkgdG8gY2hhbmdl IHRoZSBtYXBwaW5nLg0KDQpMYXJyeQ0KLS0NCmh0dHA6Ly9sYXJyeS5tYXNpbnRlci5uZXQNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBhcHBzLWRpc2N1c3MgW21haWx0 bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIFNjb3R0IEtp dHRlcm1hbg0KPiBTZW50OiBNb25kYXksIEphbnVhcnkgMTIsIDIwMTUgMTI6MTIgUE0NCj4gVG86 IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi1hcHBzYXdnLWZpbGUtc2NoZW1lLQ0KPiAwMC50eHQNCj4gDQo+ IE9uIE1vbmRheSwgSmFudWFyeSAxMiwgMjAxNSAxMToxNTozNiBNdXJyYXkgUy4gS3VjaGVyYXd5 IHdyb3RlOg0KPiA+IE9uIE1vbiwgSmFuIDEyLCAyMDE1IGF0IDEwOjM5IEFNLCBOaWNvIFdpbGxp YW1zDQo+IDxuaWNvQGNyeXB0b25lY3Rvci5jb20+DQo+ID4NCj4gPiB3cm90ZToNCj4gPiA+IE9u IE1vbiwgSmFuIDEyLCAyMDE1IGF0IDA2OjE3OjMwUE0gKzAwMDAsIHQucGV0Y2ggd3JvdGU6DQo+ ID4gPiA+IE15IHBvc3QgZWFybGllciB0b2RheSB3YXMgaW50ZW5kZWQgdG8gcHJvZCB3aG9ldmVy IHdvdWxkDQo+IGRlY2xhcmUNCj4gPiA+ID4gY29uc2Vuc3VzIG9uIGFkb3B0aW5nIHlvdXIgSS1E IGludG8gZGVjbGFyaW5nIGNvbnNlbnN1cy4gIEkgYW0gbm90DQo+IHN1cmUNCj4gPiA+ID4gd2hh dCBoYXMgaGFwcGVuZWQsIEkgc2VlIG5vIHN0YXRlbWVudCBvZiBhZG9wdGlvbiBpbiBteSBJbmJv eCBvcg0KPiBpbiB0aGUNCj4gPiA+ID4gSUVURiBhcmNoaXZlcyBidXQgbm8gbWF0dGVyLCBhcyBs b25nIGFzIHRoZSBwb3dlcnMgdGhhdCBiZSBhZ3JlZQ0KPiBvbg0KPiA+ID4gPiBhZG9wdGlvbiwg dGhhdCBpcyBmaW5lLg0KPiA+ID4NCj4gPiA+IFRoZSBmYWN0IHRoYXQgZHJhZnQtaWV0Zi1hcHBz YXdnLWZpbGUtc2NoZW1lLTAwIGdvdCBzdWJtaXR0ZWQgd2l0aA0KPiBhDQo+ID4gPiBoYW5kbGUg dGhhdCBzdGFydHMgd2l0aCBkcmFmdC1pZXRmLWFwcHNhd2ctIHZlcnkgc3Ryb25nbHkgaW1wbGll cyB0aGF0DQo+ID4gPiB0aGUgQVBQUyBjaGFpcnMgdGhvdWdodCB0aGVyZSB3YXMgY29uc2Vuc3Vz IHRvIGFkb3B0IChzaW5jZSB0aGUNCj4gYXV0aG9yDQo+ID4gPiBjb3VsZCBub3QgaGF2ZSBjYXVz ZWQgc3VjaCBhbiBJLUQgdG8gYmUgYWNjZXB0ZWQgb3RoZXJ3aXNlKS4NCj4gPg0KPiA+IEFsc28g Y29ycmVjdC4gIEFuIGVtYWlsIEkgc2VudCB0byB0aGUgYXV0aG9yIHNheWluZyBhcyBtdWNoIGFu ZCBpbnZpdGluZw0KPiA+IGhpbSB0byBzdWJtaXQgYSBXRy1uYW1lZCB2ZXJzaW9uIHNob3VsZCBo YXZlIGJlZW4gc2VudCB0byB0aGUgbGlzdC4NCj4gDQo+IFRoaXMgaXNzdWUgSSd2ZSBwcmV2aW91 c2x5IG1lbnRpb25lZCBhYm91dCBJUFIgZW5jdW1iZXJlZCBub3JtYXRpdmUNCj4gcmVmZXJlbmNl cw0KPiBpcyBzdGlsbCBwcmVzZW50IGluIHRoZSB1cGRhdGUuICBXZSByZWFsbHksIHJlYWxseSBv dWdodCB0byBoYXZlIHNvbWV0aGluZw0KPiBhcw0KPiBmaWxlOiBzdGFuZGFyZGl6ZWQgaW4gYW4g dW5lbWN1bWJlcmVkIG1hbm5lci4NCj4gDQo+IFNjb3R0IEsNCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGFwcHMtZGlzY3VzcyBtYWlsaW5n IGxpc3QNCj4gYXBwcy1kaXNjdXNzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzDQo= From nobody Mon Jan 12 22:54:28 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441171A8A1D for ; Mon, 12 Jan 2015 22:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXwzcFzqE3i7 for ; Mon, 12 Jan 2015 22:54:24 -0800 (PST) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7778C1A8A16 for ; Mon, 12 Jan 2015 22:54:24 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id C4F05FA0068; Tue, 13 Jan 2015 06:54:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1421132060; bh=gerzff0SxUtz4zBOED6Jb+LAAmgh4S/AhtnBObZO130=; h=From:To:Subject:References:Date:From; b=bQvCk1oXHJoIsKZXRurbHaaX3+nmR8is6sbo5MZHMZnA7YDQe3BwXfmVlU9CKf7lS MDYaNP0R/vXXotQ2g6ldJfy63WWFR7dxGcrwT4j4t6kLpd7hrMeP7ceJbI1F3s1OUL g5LeWXVyIKux13yxzpcIGI8kl+39wEL22y2qtY0E= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1421132059-3758-3757/12/99; Tue, 13 Jan 2015 06:54:19 +0000 From: Arnt Gulbrandsen To: IETF Apps Discuss , John Levine Message-Id: <46d08f77a738c09bc65d3ba47d4eabecdad3bee307f423e09990ed368d6efaad.sha-256@android.antelope.email> References: <20150111215428.13470.qmail@ary.lan> <632a2444-bb0f-4ce9-ad40-4f378f856a57@gulbrandsen.priv.no> <20150113021011.18290.qmail@ary.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Date: Tue, 13 Jan 2015 06:54:19 +0000 Archived-At: Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 06:54:26 -0000 The ENVID is only known by servers connected to either the sender or the recipients. Of course a server for one recipient could lie convincingly about another recipient. Arnt From nobody Mon Jan 12 23:02:08 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B2F1A8A1D for ; Mon, 12 Jan 2015 23:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1zX9D5YKsNZ for ; Mon, 12 Jan 2015 23:02:05 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18E11A8A17 for ; Mon, 12 Jan 2015 23:02:04 -0800 (PST) Received: internal info suppressed Date: Tue, 13 Jan 2015 08:01:59 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio5.garrtest.units.it To: John Levine In-Reply-To: <20150113021011.18290.qmail@ary.lan> Message-ID: References: <20150113021011.18290.qmail@ary.lan> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1421132520; bh=72nuwbJ4aW+RMPByDcG2nXAn+9hNfKjU6cCkHurxOiE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=PaJU5xJCfdCG/3I356VakQQR66utWBmGv9k8Qj4nbNEjBuyzrKfKI0GRrc47QzgIL AeQMtKuWNUN41jdmyZ2p4ZVG8+LdODOm/V9a6uDIjzlJK1zTNc5Uj61JckgIzTHwBB PvMzVdN+4IzFHWoEFMdDv4lAsvqeEGLNqLVAkmT0= Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 07:02:07 -0000 On Tue, 13 Jan 2015, John Levine wrote: >>> I haven't tested it or even considered this use case when I set up the >>> server, but the Postfix version I use is less than ten years old and I do use >>> DKIM. So I think it's worth trying: Send me mail with an entropy-rich ENVID >>> and NOTIFY=SUCCESS,FAILURE, and see if you get back a DKIM-signed success >>> DSN. >> >> OK, I need to check also my Postfix setup for the ENVID, and then I'll >> make the test! back later... > > Don't forget to check whether the d= domain in the DKIM signature has > any perceptible relationship to the recipient address. ok, it seems my MTAs lx1.dir.garr.it and lx5.dir.garr.it are correctly supporting ENVID, so I can go on with tests... ;-) > > R's, > John > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Mon Jan 12 23:34:36 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A1A1A8955 for ; Mon, 12 Jan 2015 23:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOv-jH0CHtvZ for ; Mon, 12 Jan 2015 23:34:32 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id E9FC71A8A40 for ; Mon, 12 Jan 2015 23:34:30 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 895F132E581; Tue, 13 Jan 2015 16:33:45 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 399c_3a0c_1d03a68b_f07f_4dad_901f_5c3812a8ce25; Tue, 13 Jan 2015 16:33:44 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id D0D89BF4E3; Tue, 13 Jan 2015 16:33:44 +0900 (JST) Message-ID: <54B4CA57.5070900@it.aoyama.ac.jp> Date: Tue, 13 Jan 2015 16:33:43 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Nico Williams References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> <036301d02e94$15a95200$4001a8c0@gateway.2wire.net> <20150112183935.GP16323@localhost> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 07:34:34 -0000 On 2015/01/13 04:15, Murray S. Kucherawy wrote: > Also correct. An email I sent to the author saying as much and inviting > him to submit a WG-named version should have been sent to the list. > > -MSK, slightly more sheepish APPSAWG co-chair In the East Asian zodiac, this year is the year of the sheep, so you are in good and timely company :-). Regards, Martin. From nobody Tue Jan 13 01:00:40 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004FC1A8A6A; Tue, 13 Jan 2015 01:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mzgd-l_faKFc; Tue, 13 Jan 2015 01:00:37 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0434E1ACD55; Tue, 13 Jan 2015 01:00:37 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id B1F9832E0BC; Tue, 13 Jan 2015 17:59:49 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 399c_44ab_770ab094_6516_4d3f_8131_3823dd7fe476; Tue, 13 Jan 2015 17:59:49 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id EA07FBF4DE; Tue, 13 Jan 2015 17:59:48 +0900 (JST) Message-ID: <54B4DE84.4000102@it.aoyama.ac.jp> Date: Tue, 13 Jan 2015 17:59:48 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Nico Williams References: <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2F4C3.5020008@seantek.com> <54B3940A.6020308@it.aoyama.ac.jp> <20150112181536.GN16323@localhost> In-Reply-To: <20150112181536.GN16323@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: apps-discuss@ietf.org, Julian Reschke , Mark Nottingham , "pkix@ietf.org" Subject: Re: [apps-discuss] character repertoire for fragment identifiers, was: Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 09:00:39 -0000 On 2015/01/13 03:15, Nico Williams wrote: > The href attribute in HTML is one thing. "_All_ URI/IRI slots" is > another. > > I don't object to versioning protocols and data formats to change > specific URI slots into IRI slots. > > Thus I have no objection to -say- the href attribute in HTML being made > into an IRI slot (with or without versioning of HTML -- that being an > issue for W3C, though if it were the IETF we'd want to do something > better than a flag day). There was no flag day for HTML. IRIs didn't exist (neither the spec nor the name) when HTML 4.0 became a Recommendation in 1997 (http://www.w3.org/TR/REC-html40-971218/). But there's implementation advice in that spec at http://www.w3.org/TR/REC-html40-971218/appendix/notes.html#h-B.2.1 that amounts to essentially the same conversion as the one from IRIs to URIs defined later in RFC 3987. Browsers took up that hint sooner or later. Regards, Martin. From nobody Tue Jan 13 02:06:44 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39B61ACE61 for ; Tue, 13 Jan 2015 02:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bAA3_diuTTj for ; Tue, 13 Jan 2015 02:06:40 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 467511ACE60 for ; Tue, 13 Jan 2015 02:06:39 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id CC6F032E585; Tue, 13 Jan 2015 19:05:53 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 399c_4b70_1db3aa7d_d05b_45e6_ad72_c0062a3702de; Tue, 13 Jan 2015 19:05:52 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 002A4BF4E3; Tue, 13 Jan 2015 19:05:52 +0900 (JST) Message-ID: <54B4EE00.7020702@it.aoyama.ac.jp> Date: Tue, 13 Jan 2015 19:05:52 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "t.petch" , Larry Masinter , Matthew Kerwin References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$40 01a8c0@gateway.2wire.net> <023b01d02d02$d73e1920$4001a8c0@gateway.2wire.net> In-Reply-To: <023b01d02d02$d73e1920$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 10:06:42 -0000 On 2015/01/11 03:24, t.petch wrote: > Thinking laterally, I see that > http://tools.ietf.org/html/draft-ietf-nfsv4-rfc3530bis-35#section-12 > is in the RFC Editor's Queue and so has IETF consensus. And by our IPR > rules we can lift any text we like from it, and it seems a very good > summary of the situation, perhaps a bit long for our purposes but the > basis of a way forward. (not just for file:// but for any other scheme > or indeed for other IETF work). Probably for 'file:', because both 'file:' and nfs deal with file systems. But hopefully NOT for other IETF work, in particular not for work newly started. There are much better ways to do internationalization than the mess we have to deal with (for legacy reasons) with file systems. Regards, Martin. From nobody Tue Jan 13 03:50:33 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679C71A8A9C for ; Tue, 13 Jan 2015 03:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WJJSEMvBHZx for ; Tue, 13 Jan 2015 03:50:31 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEEDA1A8A94 for ; Tue, 13 Jan 2015 03:50:30 -0800 (PST) Received: by mail-oi0-f54.google.com with SMTP id u20so1881597oif.13 for ; Tue, 13 Jan 2015 03:50:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JNI2pL6wlj33Fr8XvkBOgUzJmmXLn+R3blbfWedPkm8=; b=Hq2tcSeazJgr/Fa8BwOLRoDAh31zQTDcHeZ2yYXYTI7vyHNv5sT3ohDHonj7xzn8Pl U53t/C9tP90pQpB3FVqH+g6yFarNux7iel4nAN+JpOGvFX5dSS/A1Tdcib2H7mBtgZmi RokSXGP2Ssq5omgo0/z0LpPEHSKsObv8u5kQM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JNI2pL6wlj33Fr8XvkBOgUzJmmXLn+R3blbfWedPkm8=; b=dyBQeJsAxpp1SwbRqwZ3Ww0h+QYYIWfZoMgoZa4etzGdK81EVhSrAzb7dOqDd4Tz0V kwEW8mZ9NK/nfG3TFq341qb5Q1/5uDF1++EdR9BmG7L2R7ZAc8V6Ja4ybIjcIs9c7XW8 ugAQDOp0ncoS5osJJEX1K1agC4SdHxYuOpmCvYZI3RKSoSbAQp8pgBziUsoOL44jKijb FYojh0lRJ5pMuSLWdhLbLMFiYmP1P6OkN4fQu4h+UPEWQ3ydwubRjPI7NylydHxVnKED GbWstKcWTAybYkPSkgQq7QFBzIG9GOATnkJKI5uTYvuSQh9uNz9KOLHHkAy3PU8hK49x YdRw== X-Gm-Message-State: ALoCoQlqlOBgYirGlM/v6Lj0AnoDGsjYg6NyuEzSBSXDCFIsTM1YTQPDidnHbntU1deZJjQIgHkm MIME-Version: 1.0 X-Received: by 10.182.153.39 with SMTP id vd7mr20768402obb.78.1421149828413; Tue, 13 Jan 2015 03:50:28 -0800 (PST) Received: by 10.60.84.171 with HTTP; Tue, 13 Jan 2015 03:50:28 -0800 (PST) In-Reply-To: <54B48CCF.2010001@it.aoyama.ac.jp> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2ABA8.6030205@gmx.de> <54B2C6FA.80802@intertwingly.net> <54B2EE08.9040705@gmx.de> <54B2F527.7040404@intertwingly.net> <54B48CCF.2010001@it.aoyama.ac.jp> Date: Tue, 13 Jan 2015 11:50:28 +0000 Message-ID: From: Dave Cridland To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=089e013a01e6b217a4050c873a91 Archived-At: Cc: Julian Reschke , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] character repertoire for fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 11:50:32 -0000 --089e013a01e6b217a4050c873a91 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 13 January 2015 at 03:11, "Martin J. D=C3=BCrst" wrote: > On 2015/01/13 07:24, Dave Cridland wrote: > > IRIs are not a subset of URIs; instead they're a subset of References >> (assuming you're happy with URIs being such a subset). I think they have >> an >> intersection with URIs (ie, some URIs, at least, are also IRIs). >> > > IRIs are a superset of URIs, by definition. So all URIs are IRIs. > Thanks; I've never been entirely clear on IRIs and confess to not having read the spec as far as I can recall. Please do correct anything else I've got wrong; I doubt that's the only thing. --089e013a01e6b217a4050c873a91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 3 January 2015 at 03:11, "Martin J. D=C3=BCrst" <duerst@it.= aoyama.ac.jp> wrote:
On 2015/01/13 07:24, Dave Cridland wrote:

IRIs are not a subset of URIs; instead they're a subset of References (assuming you're happy with URIs being such a subset). I think they hav= e an
intersection with URIs (ie, some URIs, at least, are also IRIs).

 IRIs are a superset of URIs, by definition. So all URIs are IRIs.

Thanks; I've never been entirely clear on IR= Is and confess to not having read the spec as far as I can recall.

Please do correct anything else I've got wrong; I doub= t that's the only thing.
--089e013a01e6b217a4050c873a91-- From nobody Tue Jan 13 05:41:18 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208DA1A8AD8 for ; Tue, 13 Jan 2015 05:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhGyyRHICQ4K for ; Tue, 13 Jan 2015 05:41:14 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::749]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B01681A8AEA for ; Tue, 13 Jan 2015 05:41:13 -0800 (PST) Received: from pc6 (81.151.167.59) by AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) with Microsoft SMTP Server (TLS) id 15.1.53.17; Tue, 13 Jan 2015 13:40:14 +0000 Message-ID: <01d401d02f36$527ce280$4001a8c0@gateway.2wire.net> From: t.petch To: Scott Kitterman , References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> <20150112183935.GP16323@localhost> <3168431.DdMjSJ6525@scott-latitude-e6320> Date: Tue, 13 Jan 2015 13:35:27 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB4PR02CA0034.eurprd02.prod.outlook.com (10.242.174.162) To AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:AMSPR07MB049; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:AMSPR07MB049; X-Forefront-PRVS: 045584D28C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(377454003)(189002)(51704005)(199003)(50466002)(122386002)(23756003)(61296003)(19580405001)(68736005)(77096005)(87976001)(101416001)(33646002)(42186005)(19580395003)(40100003)(107886001)(97736003)(84392001)(93886004)(50226001)(86362001)(77156002)(62966003)(76176999)(81816999)(50986999)(46102003)(230783001)(92566002)(1456003)(44716002)(62236002)(47776003)(64706001)(106356001)(81686999)(105586002)(66066001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB049; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB049; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2015 13:40:14.1466 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB049 Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 13:41:16 -0000 Scott Some WG, prior to adopting an I-D and prior to Last Calling an I-D, do an explicit IPR call to the authors requiring them to disclose any IPR that they are aware of, and inviting others to do the same. I think it a good idea, but realise it is more admin for the powers that be. But then it can prevent the IPR emerging after an IETF Last Call which is even more work for the powers that be. I have on occasions raised a third party IPR disclosure at such a time leading to a 'Whoops, sorry we missed that' from a well-regarded vendor. I am also a fan of removing from an IETF Standard techniques that are IPR encumbered unless we have RAND terms and the techniques are essential. Tom Petch ----- Original Message ----- From: "Scott Kitterman" To: Sent: Monday, January 12, 2015 8:11 PM > On Monday, January 12, 2015 11:15:36 Murray S. Kucherawy wrote: > > On Mon, Jan 12, 2015 at 10:39 AM, Nico Williams > > > > wrote: > > > On Mon, Jan 12, 2015 at 06:17:30PM +0000, t.petch wrote: > > > > My post earlier today was intended to prod whoever would declare > > > > consensus on adopting your I-D into declaring consensus. I am not sure > > > > what has happened, I see no statement of adoption in my Inbox or in the > > > > IETF archives but no matter, as long as the powers that be agree on > > > > adoption, that is fine. > > > > > > The fact that draft-ietf-appsawg-file-scheme-00 got submitted with a > > > handle that starts with draft-ietf-appsawg- very strongly implies that > > > the APPS chairs thought there was consensus to adopt (since the author > > > could not have caused such an I-D to be accepted otherwise). > > > > Also correct. An email I sent to the author saying as much and inviting > > him to submit a WG-named version should have been sent to the list. > > This issue I've previously mentioned about IPR encumbered normative references > is still present in the update. We really, really ought to have something as > file: standardized in an unemcumbered manner. > > Scott K From nobody Tue Jan 13 05:41:19 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D661A8AE6 for ; Tue, 13 Jan 2015 05:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pq0oeZeK1c4i for ; Tue, 13 Jan 2015 05:41:13 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::749]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F1B1A8AE2 for ; Tue, 13 Jan 2015 05:41:12 -0800 (PST) Received: from pc6 (81.151.167.59) by AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) with Microsoft SMTP Server (TLS) id 15.1.53.17; Tue, 13 Jan 2015 13:40:15 +0000 Message-ID: <01d501d02f36$530acaa0$4001a8c0@gateway.2wire.net> From: t.petch To: Matthew Kerwin References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com><036301d02e94$15a95200$4001a8c0@gateway.2wire.net> Date: Tue, 13 Jan 2015 13:37:36 +0000 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: [81.151.167.59] X-ClientProxiedBy: DB4PR02CA0034.eurprd02.prod.outlook.com (10.242.174.162) To AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:AMSPR07MB049; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:AMSPR07MB049; X-Forefront-PRVS: 045584D28C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(377454003)(189002)(51704005)(199003)(50466002)(122386002)(61296003)(19580405001)(68736005)(77096005)(87976001)(101416001)(33646002)(42186005)(23676002)(19580395003)(40100003)(97736003)(84392001)(93886004)(50226001)(86362001)(77156002)(62966003)(76176999)(110136001)(81816999)(50986999)(46102003)(230783001)(92566002)(15975445007)(1456003)(44716002)(62236002)(47776003)(64706001)(106356001)(81686999)(105586002)(66066001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB049; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB049; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jan 2015 13:40:15.0358 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB049 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 13:41:16 -0000 Minor tweak 'its status' is mildly ambiguous suggest 'the status of RFC 1738' Tom Petch ----- Original Message ----- From: "Matthew Kerwin" To: "t.petch" Cc: "Murray S. Kucherawy" ; "IETF Apps Discuss" Sent: Tuesday, January 13, 2015 12:01 AM On 13 January 2015 at 04:17, t.petch wrote: > My earlier note also speculated on the powers that be wanting a charter > change, in which case I proposed > > 'I see the objective, were it to be codified as such, as updating the > file: scheme from the level of RFC1738 to the level of RFC3986 and not > attempting to go beyond that. ' > > which remains what I will work toward. Changes to RFC3986/RFC3987 I > regard as out of scope, bordering on a DoS attack. > > ​Yes, that's essentially my goal. I've written this: | The "file" URI scheme is woefully out of date. The document that defines | it, RFC 1738, has been superseded by the generic URI syntax of RFC 3986, | and its status is listed as "Obsolete". As such, the "file" URI scheme | is viewed by many in the internet community as being without a current | defining standard, and in need of updating to match current standards | and implementations. | | This document defines an updated "file" URI scheme, promoting | interoperability by being compatible with the generic syntax of | RFC 3986, while enumerating commonly-encountered variations that have | arisen during the scheme's long history of vague standardisation. | | Reviewers: | | * Julian Reschke | * Nico Williams | * Sean Leonard Does that suit?​ If so I'll give it to Murray to put in the wiki. -- Matthew Kerwin http://matthew.kerwin.net.au/ From nobody Tue Jan 13 06:36:52 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28F11A8AAA for ; Tue, 13 Jan 2015 06:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGQsu_etv55D for ; Tue, 13 Jan 2015 06:36:49 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CBB21A6F03 for ; Tue, 13 Jan 2015 06:36:49 -0800 (PST) Received: (qmail 96275 invoked from network); 13 Jan 2015 14:36:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=17812.54b52d80.k1501; bh=3gjjLsO9oU9Jp+WbdL3div72IV3hsgB8fTq9kwFMRJ8=; b=rWZEvYSoVcyRHyYBL4aRolzWdb44BqtQf4kUFwxa38d7f7hZGmtFMbf67u9gdu/koAKIoKZNCGteV03cLWG8MzQnhlO2VWjsyV9WT5MBxbsV1l8G1StiWNMemQYq9DchYahbgfFOpwyOaT15ykB9fiMRy6g6VNCzEER2YJBvGYVeh2OZGbQBdzwEyGF7csvZAnZ4jyv+R792TngeIrwGOxS2mNuJZm3Lngo8CX03BS3qKJ3z5phLI+mdARsc8yQc DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=17812.54b52d80.k1501; bh=3gjjLsO9oU9Jp+WbdL3div72IV3hsgB8fTq9kwFMRJ8=; b=OM9D6aXbVxclWsURumr3L4wKDYgIwJ9xM3tjq2GvfR7pEGjH23dn/RS2eGrQ9oY6v9ecQROrBPIeuPLCxAOeynYrGItbTp5YV373/g2HEyPVnvmK7SNNPe1h/p0pLLQl2RBh/syVmHN7onVQekh4MRbt4cXhk/taHNrtErqv8A7BtHsMOrssYpMrW4Y9WCv2QE0SApNU8RxzyjUEtAKBEPVbw7RUgqh+bHWXgMh4UxhEwOOLMqZP6uWjRWSIflYN Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 13 Jan 2015 14:36:48 -0000 Date: 13 Jan 2015 09:36:47 -0500 Message-ID: From: "John R Levine" To: "Arnt Gulbrandsen" In-Reply-To: <46d08f77a738c09bc65d3ba47d4eabecdad3bee307f423e09990ed368d6efaad.sha-256@android.antelope.email> References: <20150111215428.13470.qmail@ary.lan> <632a2444-bb0f-4ce9-ad40-4f378f856a57@gulbrandsen.priv.no> <20150113021011.18290.qmail@ary.lan> <46d08f77a738c09bc65d3ba47d4eabecdad3bee307f423e09990ed368d6efaad.sha-256@android.antelope.email> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 14:36:51 -0000 > The ENVID is only known by servers connected to either the sender or the > recipients. Of course a server for one recipient could lie convincingly about > another recipient. Good points. What value does a DKIM signature provide on a bounce that has the right ENVID? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue Jan 13 06:45:30 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064BA1A8AF5 for ; Tue, 13 Jan 2015 06:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEnbMCCTA_2x for ; Tue, 13 Jan 2015 06:45:27 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 401A61A8AE6 for ; Tue, 13 Jan 2015 06:45:27 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 3A00CFA0068; Tue, 13 Jan 2015 14:45:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1421160325; bh=Qcb+gIxJdm1Rji8B0ySQvhdYAA6UFkMrpR+/Y8g66AI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=mipng95x7uMZm8KumW5ZZJO2mF82SaObVGTSFy/YTJr5mVw1CUubDy1+Z/TyhXtbC j5R29WgtuWjMnO5vToTE3VKrkiCzMTxPWpKhLL4x9yC4hDrl/6tFi6n5sozaDSXE8n 9qJfGYQ7OhTncgsPu2/9m09DdnnJ2Gf4PKWNSpY8= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1421160324-3758-3757/12/101; Tue, 13 Jan 2015 14:45:24 +0000 From: Arnt Gulbrandsen To: IETF Apps Discuss Date: Tue, 13 Jan 2015 15:45:23 +0100 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.6; X11; Linux; Ubuntu 14.04.1 LTS Mime-Version: 1.0 Message-Id: <6724dce8-a087-400a-b6e1-c8cf24e3d55c@gulbrandsen.priv.no> In-Reply-To: References: <20150111215428.13470.qmail@ary.lan> <632a2444-bb0f-4ce9-ad40-4f378f856a57@gulbrandsen.priv.no> <20150113021011.18290.qmail@ary.lan> <46d08f77a738c09bc65d3ba47d4eabecdad3bee307f423e09990ed368d6efaad.sha-256@android.antelope.email> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 14:45:29 -0000 John Levine answers me: >> The ENVID is only known by servers connected to either the >> sender or the recipients. Of course a server for one recipient >> could lie convincingly about another recipient. > > Good points. What value does a DKIM signature provide on a > bounce that has the right ENVID? If I send mail to three people ten servers might learn the ENVID. A strong ENVID offers good assurange that the DSN comes either from one of the ten involved servers or from my keybard. The DKIM signature narrows the source down to one server (or at least to one organization). Arnt From nobody Tue Jan 13 06:48:33 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133F31A8A90 for ; Tue, 13 Jan 2015 06:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hw7J2g1utld8 for ; Tue, 13 Jan 2015 06:48:29 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857881A8BB2 for ; Tue, 13 Jan 2015 06:48:26 -0800 (PST) Received: internal info suppressed Date: Tue, 13 Jan 2015 15:48:22 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@synx02.dir.garr.it To: John R Levine In-Reply-To: Message-ID: References: <20150111215428.13470.qmail@ary.lan> <632a2444-bb0f-4ce9-ad40-4f378f856a57@gulbrandsen.priv.no> <20150113021011.18290.qmail@ary.lan> <46d08f77a738c09bc65d3ba47d4eabecdad3bee307f423e09990ed368d6efaad.sha-256@android.antelope.email> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1421160503; bh=wISZAo6TcqkO0xt7iM28F5ck1oJLRJBJz+JcmTpWg/4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=koL7RKjEhgqfXs4C3rF6EGs16bZGJrQOfkjTNpTxMT4ja1BJXy/6bys5BBhgVOMY1 wixE1F2r9cN2YW4OjPVxpSeij7suSbx/MoNqNTe0fj/E5yHYiocdTVt8Eme5zOBjji qbD+G+Q2PNoPDomngDpB1/X5z6HsIj79f4AbBMA0= Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 14:48:32 -0000 On Tue, 13 Jan 2015, John R Levine wrote: >> The ENVID is only known by servers connected to either the sender or the >> recipients. Of course a server for one recipient could lie convincingly >> about another recipient. Just made the test asked by Arnt. Here is the DSN with full headers: ----------------------------------------------------------------------------- >From MAILER-DAEMON@aox.org Tue Jan 13 15:28:03 2015 Return-Path: <> Received: from cyrus-c1v2.dir.garr.it ([unix socket]) by cyrus-c1v2 (Cyrus v2.4.17) with LMTPA; Tue, 13 Jan 2015 15:28:02 +0100 X-Sieve: CMU Sieve 2.4 Received: internal info suppressed Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by lx1.dir.garr.it (8.14.4/8.14.4/Debian-4) with ESMTP id t0DERpFD007844 for ; Tue, 13 Jan 2015 15:27:57 +0100 Received: by strange.aox.org (Postfix) id EC5C0FA0075; Tue, 13 Jan 2015 14:24:47 +0000 (UTC) Date: Tue, 13 Jan 2015 14:24:47 +0000 (UTC) From: MAILER-DAEMON@aox.org (Mail Delivery System) Subject: Successful Mail Delivery Report To: claudio.allocchio@garr.it Auto-Submitted: auto-replied MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="1DD91FA0068.1421159087/strange.aox.org" Message-Id: <20150113142447.EC5C0FA0075@strange.aox.org> X-SPF-Scan-By: smf-spf v2.0.2 - http://smfs.sf.net/ Received-SPF: None (lx1.dir.garr.it: domain of postmaster@strange.aox.org does not designate permitted sender hosts) receiver=lx1.dir.garr.it; client-ip=2001:4d88:100c::1; envelope-from=<>; helo=strange.aox.org; X-Greylist: Delayed for 00:03:03 by milter-greylist-4.3.9 (lx1.dir.garr.it [IPv6:2001:760:0:158::2]); Tue, 13 Jan 2015 15:27:57 +0100 (CET) X-Virus-Scanned: clamav-milter 0.98.1 at lx1.dir.garr.it X-Virus-Status: Clean This is the mail system at host strange.aox.org. Your message was successfully delivered to the destination(s) listed below. If the message was delivered to mailbox you will receive no further notifications. Otherwise you may still receive notifications of mail delivery errors from other systems. The mail system : delivery via local: alias expanded [ Part 2: "Delivery report" ] Reporting-MTA: dns; strange.aox.org Original-Envelope-Id: 13JAN2015152214010512 X-Postfix-Queue-ID: 1DD91FA0068 X-Postfix-Sender: rfc822; claudio.allocchio@garr.it Arrival-Date: Tue, 13 Jan 2015 14:22:29 +0000 (UTC) Final-Recipient: rfc822; arnt@gulbrandsen.priv.no Original-Recipient: rfc822;arnt@gulbrandsen.priv.no Action: expanded Status: 2.0.0 Diagnostic-Code: X-Postfix; delivery via local: alias expanded Return-Path: Received: from 140.105.1.2 (unknown [140.105.1.2]) by strange.aox.org (Postfix) with ESMTP id 1DD91FA0068 for ; Tue, 13 Jan 2015 14:22:29 +0000 (UTC) From: claudio.allocchio@garr.it To: Arnt Gulbrandsen Date: 13-Jan-2015 15:23 CET Subject: ENVID + NOTIFY test ----------------------------------------------------------------------------- The Delivery Report part contains the correct ENVID used to send (and the DSN was also sent back with IPv6, but this does not matter). But I do not see a DKIM signature in the DSN... > > Good points. What value does a DKIM signature provide on a bounce that has > the right ENVID? > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Tue Jan 13 06:55:46 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078A41A8BBD for ; Tue, 13 Jan 2015 06:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqilMIKY6WEO for ; Tue, 13 Jan 2015 06:55:40 -0800 (PST) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3851A8F3A for ; Tue, 13 Jan 2015 06:55:39 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 35E57FA0068; Tue, 13 Jan 2015 14:55:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1421160938; bh=QF0K1b110dvzm7OqcpvPk7JF6rI+UWYpCPn2zIW1f58=; h=From:To:Subject:Date:In-Reply-To:References:From; b=lP4KZDG8gM14iM3eX3UiLEBFyxPJPBVYW08Mqz1VkeQRJ2g01nWKSUfFdg9y5WNcC 9pzcJ7oF6yUhpRvPHr87tAVAGWSF+t24h7XFvhOLIyVz42ly6MHiITVAijbjY9LqhZ BdYzcmbhDQHISodytGEEaewBjXaM5e8YVIomezh4= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1421160937-3758-3757/11/26; Tue, 13 Jan 2015 14:55:37 +0000 From: Arnt Gulbrandsen To: IETF Apps Discuss Date: Tue, 13 Jan 2015 15:55:37 +0100 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.6; X11; Linux; Ubuntu 14.04.1 LTS Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20150111215428.13470.qmail@ary.lan> <632a2444-bb0f-4ce9-ad40-4f378f856a57@gulbrandsen.priv.no> <20150113021011.18290.qmail@ary.lan> <46d08f77a738c09bc65d3ba47d4eabecdad3bee307f423e09990ed368d6efaad.sha-256@android.antelope.email> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 14:55:45 -0000 On Tuesday, January 13, 2015 3:48:22 PM CEST, Claudio Allocchio wrote: > Just made the test asked by Arnt. Here is the DSN with full headers: Thank you. > But I do not see a DKIM signature in the DSN... I'm afraid this means that if you're moderately competent and set up DKIM in the way the top five google results suggest, the server will not sign DSNs. If a sender chooses an unguessable ENVID and uses NOTIFY=SUCCESS, then this means that the sender will get a more or less unforgable delivery ack from software that's currently fairly widely deployed (with no standards work needed). But without a DKIM signatura, third parties need not believe that. The sender might know that there was only one recipient, so only servers on the path to the recipient could've acked. But the sender won't be sure which one, and third parties need not trust this at all. Arnt From nobody Tue Jan 13 07:52:07 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACC01A8AEA for ; Tue, 13 Jan 2015 07:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_UY2d2pGTWj for ; Tue, 13 Jan 2015 07:52:02 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 131B11A8AE6 for ; Tue, 13 Jan 2015 07:51:46 -0800 (PST) Received: (qmail 10887 invoked from network); 13 Jan 2015 15:51:45 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 13 Jan 2015 15:51:45 -0000 Date: 13 Jan 2015 15:51:23 -0000 Message-ID: <20150113155123.21938.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 15:52:04 -0000 >If a sender chooses an unguessable ENVID and uses NOTIFY=SUCCESS, then this >means that the sender will get a more or less unforgable delivery ack from >software that's currently fairly widely deployed (with no standards work >needed). > >But without a DKIM signatura, third parties need not believe that. Unless you have some way to know what servers handle what mail, which you don't, a DKIM signature provides no benefit. You send mail to bogus@gurus.org, my server responds with a DSN signed by miucha.iecc.com. Now what? Also keep in mind that anyone with access to the message can produce a 100% authentic DSN, either by forwarding it to a bad address, or just by faking one up and mailing it out, quite likely getting it signed on the way. All a DSN really tells you is that someone saw the message, and it's entirely up to you whether you believe what the DSN says about it. R's, John From nobody Tue Jan 13 09:14:31 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97651A901C for ; Tue, 13 Jan 2015 09:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBBrnsQRsEY0 for ; Tue, 13 Jan 2015 09:14:24 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDDEE1A8FD7 for ; Tue, 13 Jan 2015 09:14:18 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4CE0AFA0068; Tue, 13 Jan 2015 17:14:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1421169256; bh=a8JObQP7h5ZZOKMXZaassChfpUhpJACoDWh/KgSpFv4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=eO7OQD93n7aDjpRvh97N+ui+4B4QzzKwFBcPdTOfXoely9eJf9oP4wh0TUT2Bro3T YL5hxIlKSrNKHDDxBCpkZ3H76e8dg/3uctzrG8/rP0czbpPIIPmwofQBR6wgUt5xfc 979pGNN8D8T6dN5K75CD9DdncTt/Ve0Pm/j/lmsU= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1421169255-3758-3757/11/27; Tue, 13 Jan 2015 17:14:15 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Tue, 13 Jan 2015 18:14:14 +0100 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.6; X11; Linux; Ubuntu 14.04.1 LTS Mime-Version: 1.0 Message-Id: <1e2448a8-95ef-4ad5-baa0-d439c5013b06@gulbrandsen.priv.no> In-Reply-To: <20150113155123.21938.qmail@ary.lan> References: <20150111215428.13470.qmail@ary.lan> <632a2444-bb0f-4ce9-ad40-4f378f856a57@gulbrandsen.priv.no> <20150113021011.18290.qmail@ary.lan> <46d08f77a738c09bc65d3ba47d4eabecdad3bee307f423e09990ed368d6efaad.sha-256@android.antelope.email> <20150113155123.21938.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 17:14:25 -0000 On Tuesday, January 13, 2015 4:51:23 PM CEST, John Levine wrote: > Unless you have some way to know what servers handle what mail, which > you don't, a DKIM signature provides no benefit. You send mail to > bogus@gurus.org, my server responds with a DSN signed by > miucha.iecc.com. Now what? Now I have a DSN with ENVID+DKIM, ie. I know someone signed for having performed successful final delivery, and I know that someone is called miucha.iecc.com. If nonreputiation turns out to matter for this particular message, you might perhaps want to disclaim ever having received the message and signed for it. If you can change miucha's DKIM keys before I've asked forty-two neutral third parties to verify the DKIM signature, you can repudiate the message. If not, you cannot. It's not the world, but it is something. I like it since it's cheap. > Also keep in mind that anyone with access to the message can produce a > 100% authentic DSN, either by forwarding it to a bad address, or just > by faking one up and mailing it out, quite likely getting it signed on > the way. All a DSN really tells you is that someone saw the message, > and it's entirely up to you whether you believe what the DSN says > about it. I do have access to the test messages Claudio sent me earlier today and do not see the ENVID anywhere. While I could forge a DSN without the ENVID and get it signed, Claudio might regard the result as less than 100% authentic. Arnt From nobody Tue Jan 13 09:26:03 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7E71A8FD6 for ; Tue, 13 Jan 2015 09:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.766 X-Spam-Level: X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfkDKPmk_u7v for ; Tue, 13 Jan 2015 09:25:58 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6654F1A8BB2 for ; Tue, 13 Jan 2015 09:25:58 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 24A1676806A; Tue, 13 Jan 2015 09:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=LC7ZbYJAEzaRokkCGOZ8wSftED8=; b=g6ExZZdqhaR H8ry9h422JkJpC/5qSHeTCTd4qP8Cd0G2vqpqnOyC5R1NnUFRtb6JASWOkLNyVky xylSEx0GXR3AVl1lT79MXhf/jIucF3QGC29OIKz+d1K55O4rLO8SkgPLERUK1nAz DY0+FNdzefk8ms/SSu8XhTvpOUptltzo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPA id 78746768061; Tue, 13 Jan 2015 09:25:57 -0800 (PST) Date: Tue, 13 Jan 2015 11:25:56 -0600 From: Nico Williams To: =?iso-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= Message-ID: <20150113172551.GB16323@localhost> References: <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <023b01d02d02$d73e1920$4001a8c0@gateway.2wire.net> <54B4EE00.7020702@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <54B4EE00.7020702@it.aoyama.ac.jp> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF Apps Discuss , Larry Masinter Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 17:25:59 -0000 On Tue, Jan 13, 2015 at 07:05:52PM +0900, "Martin J. D=FCrst" wrote: > On 2015/01/11 03:24, t.petch wrote: > >Thinking laterally, I see that > >http://tools.ietf.org/html/draft-ietf-nfsv4-rfc3530bis-35#section-12 > >is in the RFC Editor's Queue and so has IETF consensus. And by our IP= R > >rules we can lift any text we like from it, and it seems a very good > >summary of the situation, perhaps a bit long for our purposes but the > >basis of a way forward. (not just for file:// but for any other scheme > >or indeed for other IETF work). >=20 > Probably for 'file:', because both 'file:' and nfs deal with file > systems. But hopefully NOT for other IETF work, in particular not > for work newly started. There are much better ways to do > internationalization than the mess we have to deal with (for legacy > reasons) with file systems. It's good to see pragmatism as to filesystems. We do have a mess to work with. Sometimes we can identify boundaries where conversions (e.g., RFC3987) can be applied to make things better. Other times we can identify such boundaries but have no hope of getting conversions applied (e.g., filesystems). Nico --=20 From nobody Tue Jan 13 09:59:48 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAC31A9045 for ; Tue, 13 Jan 2015 09:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaEmAEsv967O for ; Tue, 13 Jan 2015 09:59:45 -0800 (PST) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD5751A8BB2 for ; Tue, 13 Jan 2015 09:59:41 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id y19so4482140wgg.4 for ; Tue, 13 Jan 2015 09:59:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=/33fRMt+mBm8chLaWLzVgZCcaNSq/7dwUVzsKhmKvxQ=; b=taDrGilR8ND8EmjimcXQJTnY2aIjdF9kMllvHRgUQuQvoq5irf6Ci+UdFYq3dwbbJi 7HuYeiTKtjfmBgLZ7zMw6yDt3uXSQxrSeNNErXHgLp6CX2cYU3mwXbisdi1SS2MXWg/d hHsBWMdvq7DDHEJDjpnmkWpzfIPG4HpK1kVDUikwcqbx8ey8TgDg0P6Ax+xJenN2HRQJ vxzXuWat9bFavDCFG2D/vJi4qMSdDt5MV7nff1isMmIXuRGKk3kyf6I9KBu3Y9Tx45Ns 4MyXXF33aCTV/OPGgkwG4xOzOxnE2cE1avya3E5+SmIJcApS9p16Si8V5NK/L3ixLu7r CZuw== MIME-Version: 1.0 X-Received: by 10.194.62.76 with SMTP id w12mr42034288wjr.5.1421171980414; Tue, 13 Jan 2015 09:59:40 -0800 (PST) Received: by 10.27.204.198 with HTTP; Tue, 13 Jan 2015 09:59:40 -0800 (PST) In-Reply-To: References: Date: Tue, 13 Jan 2015 09:59:40 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7ba977a40eb6e3050c8c635d Archived-At: Subject: Re: [apps-discuss] Call For Adoption: draft-seantek-windows-image X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 17:59:47 -0000 --047d7ba977a40eb6e3050c8c635d Content-Type: text/plain; charset=UTF-8 On Wed, Dec 17, 2014 at 1:14 PM, Murray S. Kucherawy wrote: > This note starts a Call For Adoption for draft-seantek-windows-image. > This work was presented as two separate drafts at the Honolulu meeting and > appeared to have some support and no objection to processing through > APPSAWG. > > Please reply with support or objection on this thread by January 9, 2015. > This call completed with three expressions of support, including the author, and no further comments. Thus, there does not appear to be enough support at this time to adopt them as working group items. I've consulted with my co-chair and our managing Area Director, and we believe this (and the text/nfo document as well) is an excellent candidate for processing through the Independent Submission Editor rather than APPSAWG. It will still receive the requisite IESG review per RFC6838 and, of course, the media types reviewer(s). The community is welcome to develop those documents on the apps-discuss list until they are submitted to the ISE. -MSK, APPSAWG co-chair --047d7ba977a40eb6e3050c8c635d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 17, 2014 at 1:14 PM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
This note starts a Call For Adoption for draft-seantek-windows-image.=C2= =A0 This work was presented as two separate drafts at the Honolulu meeting = and appeared to have some support and no objection to processing through AP= PSAWG.

Please reply with support or objection on this thread by Janu= ary 9, 2015.

This call comp= leted with three expressions of support, including the author, and no furth= er comments.=C2=A0 Thus, there does not appear to be enough support at this= time to adopt them as working group items.

I've cons= ulted with my co-chair and our managing Area Director, and we believe this = (and the text/nfo document as well) is an excellent candidate for processin= g through the Independent Submission Editor rather than APPSAWG.=C2=A0 It w= ill still receive the requisite IESG review per RFC6838 and, of course, the= media types reviewer(s).

The community is welcome to dev= elop those documents on the apps-discuss list until they are submitted to t= he ISE.

-MSK, APPSAWG co-chair
--047d7ba977a40eb6e3050c8c635d-- From nobody Tue Jan 13 15:11:50 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14CF71B2B7A for ; Tue, 13 Jan 2015 15:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.427 X-Spam-Level: X-Spam-Status: No, score=-0.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFpFhDxWAnJI for ; Tue, 13 Jan 2015 15:11:46 -0800 (PST) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D777C1B2B7D for ; Tue, 13 Jan 2015 15:11:29 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id f12so3547217qad.10 for ; Tue, 13 Jan 2015 15:11:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZXOXX/vlfRGZs26skEC7D3fQBdo2JtXjWUSpmTuIv84=; b=CmqhSLJhNDnzr/ruR16unqp81BhyC03Ri5JDXBa7j6W+Cf/4m5AsuS3DEfeAOwNXiX qz/vbVASrRZ8985DE0z286ZT7ttKZNPKHOmt2LyoRrg3KBC01MMMLAMuOhm7MwTPr+OI rqLimx9s+1DSRSzYa06gnO5l74cbIMUSi5NSuVLsqtkFg/EJdar5LtMGS1Qc5W5susUj KKjtB8XIXUz3cuRGv+BSWE6daNrEHl/Y+FFPRV9aW76hG2zaAXNzJcQKXRMflIlTpXp4 T8sCvCFgktb7FIC9thG719X64WsurJEyJKGO0VDL0TL/PiCBckdpBAfkdxatTjLmsuRJ 1VSg== MIME-Version: 1.0 X-Received: by 10.229.70.133 with SMTP id d5mr1991005qcj.2.1421190689053; Tue, 13 Jan 2015 15:11:29 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Tue, 13 Jan 2015 15:11:28 -0800 (PST) In-Reply-To: <01d501d02f36$530acaa0$4001a8c0@gateway.2wire.net> References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> <036301d02e94$15a95200$4001a8c0@gateway.2wire.net> <01d501d02f36$530acaa0$4001a8c0@gateway.2wire.net> Date: Wed, 14 Jan 2015 09:11:28 +1000 X-Google-Sender-Auth: EVbGPvHKvE5vAqix0vBs-FglqUI Message-ID: From: Matthew Kerwin To: "t.petch" Content-Type: multipart/alternative; boundary=001a113390062de1e9050c90bebd Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 23:11:48 -0000 --001a113390062de1e9050c90bebd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 13 January 2015 at 23:37, t.petch wrote: > Minor tweak > 'its status' is mildly ambiguous > suggest 'the status of RFC 1738' > > That makes sense. I've changed it in my version on github [1]. Thanks=E2=80=8B [1]: < https://github.com/phluid61/internet-drafts/blob/master/file-scheme/mini-ch= arter.md > --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a113390062de1e9050c90bebd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 13 January 2015 at 23:37, t.petch <= ;ietfc@btconnect.c= om> wrote:
Minor tweak
'its status' is mildly ambiguous
suggest 'the status of RFC 1738'


That makes sense. I've changed it in my version on github [1].
=

Thanks=E2=80=8B

<= div class=3D"gmail_default" style=3D"font-family:georgia,serif;color:rgb(7,= 55,99)">
[1]: <https://github.com= /phluid61/internet-drafts/blob/master/file-scheme/mini-charter.md>

--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a113390062de1e9050c90bebd-- From nobody Tue Jan 13 15:36:46 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3471A6F0A for ; Tue, 13 Jan 2015 15:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.054 X-Spam-Level: * X-Spam-Status: No, score=1.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQESafqhsZCA for ; Tue, 13 Jan 2015 15:36:43 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92DB1ACDBE for ; Tue, 13 Jan 2015 15:36:42 -0800 (PST) Received: from [10.171.218.108] (48.sub-70-192-210.myvzw.com [70.192.210.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E4D56C40130; Tue, 13 Jan 2015 17:37:50 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421192271; bh=GVDbOgqnhfHDec6KR00CCbYZEQJ/NJWMt170HF/Gb50=; h=In-Reply-To:References:Subject:From:Date:To:From; b=1fLRL4UnpxemDZA98G/xhR0FbHAZBeDyGncPwBAj4+2MhRvK4BIxfzVRznWmrdaye Mwh7IONIQxEjHtJpBRUI/LZIYm5kF4w4si0U74mtjy++nU+is1+WTP68vLRRaaD/UQ EsDKjxY98lFD9PnXZdX8L/sFPc8zMLsKLVv43WAA= User-Agent: K-9 Mail for Android In-Reply-To: References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> <20150112183935.GP16323@localhost> <3168431.DdMjSJ6525@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----0H26Z1ZD6C81IP01JMFJ4DKEKZET6K" Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 13 Jan 2015 18:28:59 -0500 To: "apps-discuss@ietf.org" Message-ID: <5BF129A4-CB21-4412-A267-02126B65A914@kitterman.com> Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jan 2015 23:36:45 -0000 ------0H26Z1ZD6C81IP01JMFJ4DKEKZET6K Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 >From my point of view, a standard I can't implement is useless. Since these are normative, not informative, they are presumably required to implement file: in a cross-platform manner. What are the license terms associated I can use for code derived from those references? At this point, it's completely unknown. For something as basic as file:, I don't think it's acceptable. Scott K On January 13, 2015 12:34:32 AM EST, Larry Masinter wrote: >I'm still not sure what the problem is with IPR-encumbered normative >references. That said, I'd prefer a list (IANA registry?) of >OS+filesystems and OS+filesystem-specific "file:" mappings, which could >be vendor-supplied or Informational, rather than standards track. > >Even things like case-sensitivity in file systems is likely to change >the mapping. > >Larry >-- >http://larry.masinter.net > >> -----Original Message----- >> From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf >> Of Scott Kitterman >> Sent: Monday, January 12, 2015 12:12 PM >> To: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] I-D Action: >draft-ietf-appsawg-file-scheme- >> 00.txt >> >> On Monday, January 12, 2015 11:15:36 Murray S. Kucherawy wrote: >> > On Mon, Jan 12, 2015 at 10:39 AM, Nico Williams >> >> > >> > wrote: >> > > On Mon, Jan 12, 2015 at 06:17:30PM +0000, t.petch wrote: >> > > > My post earlier today was intended to prod whoever would >> declare >> > > > consensus on adopting your I-D into declaring consensus. I am >not >> sure >> > > > what has happened, I see no statement of adoption in my Inbox >or >> in the >> > > > IETF archives but no matter, as long as the powers that be >agree >> on >> > > > adoption, that is fine. >> > > >> > > The fact that draft-ietf-appsawg-file-scheme-00 got submitted >with >> a >> > > handle that starts with draft-ietf-appsawg- very strongly implies >that >> > > the APPS chairs thought there was consensus to adopt (since the >> author >> > > could not have caused such an I-D to be accepted otherwise). >> > >> > Also correct. An email I sent to the author saying as much and >inviting >> > him to submit a WG-named version should have been sent to the list. >> >> This issue I've previously mentioned about IPR encumbered normative >> references >> is still present in the update. We really, really ought to have >something >> as >> file: standardized in an unemcumbered manner. >> >> Scott K >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss ------0H26Z1ZD6C81IP01JMFJ4DKEKZET6K Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit From my point of view, a standard I can't implement is useless. Since these are normative, not informative, they are presumably required to implement file: in a cross-platform manner.

What are the license terms associated I can use for code derived from those references? At this point, it's completely unknown. For something as basic as file:, I don't think it's acceptable.

Scott K

On January 13, 2015 12:34:32 AM EST, Larry Masinter <masinter@adobe.com> wrote:
I'm still not sure  what the problem is with IPR-encumbered normative references. That said, I'd prefer a list (IANA registry?) of OS+filesystems and OS+filesystem-specific "file:" mappings, which could be vendor-supplied or Informational, rather than standards track. 

Even things like case-sensitivity in file systems is likely to change the mapping.

Larry
--
http://larry.masinter.net

 -----Original Message-----
 From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf
 Of Scott Kitterman
 Sent: Monday, January 12, 2015 12:12 PM
 To: apps-discuss@ietf.org
 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-
 00.txt
 
 On Monday, January 12, 2015 11:15:36 Murray S. Kucherawy wrote:
 On Mon, Jan 12, 2015 at 10:39 AM, Nico Williams
 <nico@cryptonector.com>

 wrote:
 On Mon, Jan 12, 2015 at 06:17:30PM +0000, t.petch wrote:
 My post earlier today was intended to prod whoever would
 declare
 consensus on adopting your I-D into declaring consensus.  I am not
 sure
 what has happened, I see no statement of adoption in my Inbox or
 in the
 IETF archives but no matter, as long as the powers that be agree
 on
 adoption, that is fine.

 The fact that draft-ietf-appsawg-file-scheme-00 got submitted with
 a
 handle that starts with
draft-ietf-appsawg- very strongly implies that
 the APPS chairs thought there was consensus to adopt (since the
 author
 could not have caused such an I-D to be accepted otherwise).

 Also correct.  An email I sent to the author saying as much and inviting
 him to submit a WG-named version should have been sent to the list.
 
 This issue I've previously mentioned about IPR encumbered normative
 references
 is still present in the update.  We really, really ought to have something
 as
 file: standardized in an unemcumbered manner.
 
 Scott K
 

 apps-discuss mailing list
 apps-discuss@ietf.org
 https://www.ietf.org/mailman/listinfo/apps-discuss
------0H26Z1ZD6C81IP01JMFJ4DKEKZET6K-- From nobody Wed Jan 14 02:26:18 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842C11A8A78 for ; Wed, 14 Jan 2015 02:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.469 X-Spam-Level: X-Spam-Status: No, score=0.469 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GU2SUNHtoVIA for ; Wed, 14 Jan 2015 02:26:12 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D124D1ACE3F for ; Wed, 14 Jan 2015 02:26:11 -0800 (PST) Received: internal info suppressed Date: Wed, 14 Jan 2015 11:26:07 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@synx02.dir.garr.it To: Arnt Gulbrandsen In-Reply-To: <1e2448a8-95ef-4ad5-baa0-d439c5013b06@gulbrandsen.priv.no> Message-ID: References: <20150111215428.13470.qmail@ary.lan> <632a2444-bb0f-4ce9-ad40-4f378f856a57@gulbrandsen.priv.no> <20150113021011.18290.qmail@ary.lan> <46d08f77a738c09bc65d3ba47d4eabecdad3bee307f423e09990ed368d6efaad.sha-256@android.antelope.email> <20150113155123.21938.qmail@ary.lan> <1e2448a8-95ef-4ad5-baa0-d439c5013b06@gulbrandsen.priv.no> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1421231168; bh=RMcPB9XBkJwIT9f+ciVLZCbJwAtkV7Kw6sbjPnFFKhU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=mDzj/NGTqsqOgQojAMzFUSK0G+GaWYL1JMuDzYWOTQCEM2NnyAAx/WGu/aA0/XQxB tc5dftQgCgQYZOZ/8kXYCH0PUKEgf9dpfYau1QEMt457B03SOYiHznXO6RSDvD+4WT ZwkbyPkRHPEnfKdLji7zEVnVL9pmxqJ6TEmNFtjY= Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jan 2015 10:26:14 -0000 On Tue, 13 Jan 2015, Arnt Gulbrandsen wrote: > On Tuesday, January 13, 2015 4:51:23 PM CEST, John Levine wrote: >> Unless you have some way to know what servers handle what mail, which >> you don't, a DKIM signature provides no benefit. You send mail to >> bogus@gurus.org, my server responds with a DSN signed by >> miucha.iecc.com. Now what? > > Now I have a DSN with ENVID+DKIM, ie. I know someone signed for having > performed successful final delivery, and I know that someone is called > miucha.iecc.com. Correct. And technically speaking, nothing more. But as a sender I have some non easily repudiable (see below) information. How can I (the sender) know that the DSN sender IS the one which was suppoused to make the final delivery? Very complicated, nearly impossible... maybe some "external tool" can help... but this is not the point... I sent a message, and somebody declares it delivered it and cannot repudiate this declaration. > If nonreputiation turns out to matter for this particular message, you might > perhaps want to disclaim ever having received the message and signed for it. > If you can change miucha's DKIM keys before I've asked forty-two neutral > third parties to verify the DKIM signature, you can repudiate the message. If > not, you cannot. > > It's not the world, but it is something. I like it since it's cheap. ... there is a technical (implementation) problem, though... DSNs come with MAIL FROM:<> ... and as far as I know (and Arnt also verified this problem) current implementations do not DKIM sign a message with such a MAIL FROM SMTP envelope... (maybe I'm wrong... but I do not know of any way to make this...). >> Also keep in mind that anyone with access to the message can produce a >> 100% authentic DSN, either by forwarding it to a bad address, or just >> by faking one up and mailing it out, quite likely getting it signed on >> the way. All a DSN really tells you is that someone saw the message, >> and it's entirely up to you whether you believe what the DSN says >> about it. > > I do have access to the test messages Claudio sent me earlier today and do > not see the ENVID anywhere. While I could forge a DSN without the ENVID and > get it signed, Claudio might regard the result as less than 100% authentic. ENVID+NOTIFY makes impossible to forge a DSN by accessing the message after delivery. To make false DSNs if EVNID is used, you need to act inside the MTAs chain (routing system), e.g. to spoof the DNS to place an MTA-in-the-middle attack. If you are just the real MTA suppoused to make the final delivery to the correct mailbox, and instead of doing this, you deliver it somehwere else, you will be responsible because you DKIM signed the DSN (like a post office delivering my mail to my neighbour and declaring he put it into my mailbox). So... the MTA-in-the-middle (DNS spoofing) is the only tricky case in current Open Internet (as DNSSEC is not yet there...). In such a bad case, the message is intercepted and delivered somehwere else than the real recipient, and the attacker MTA issues a DKIM signed DSN with correct ENVID... but its DKIM key is not the one of the genuine MTA. If DNS is spoofed, then the sender can only make an "out of band" verification etc... but here we are now in case which is very complex and out of scope for most of the normal cases I was thinking on with the original question. Not a perfect solution... as Arnt says... but (if we know how to make signatures of <> !) usable... and likely no need of any protocol development. Am I completely wrong? all the best! > Arnt > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Wed Jan 14 02:56:22 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D350A1B2C2C for ; Wed, 14 Jan 2015 02:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qDVu4i1OdO8 for ; Wed, 14 Jan 2015 02:56:17 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 803EF1ACE5C for ; Wed, 14 Jan 2015 02:56:17 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4FA12FA0004; Wed, 14 Jan 2015 10:56:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1421232975; bh=8yMiie9Acl8Eo1zFFX7OsKCnPkGyp2TlsRPzqpar/fc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=chNuSzjNPKDwL211LtAJ4PrJb6RSJOi3SbYRPNu2QY0dDjX+FdPOdzbFZ6h+3Gri3 XUUA+8HSbd/M7haGgor+o8smi3KsH+METEkmxf0xgD8PINQA6iSn6Ur6UGGDLcuQRA XZntknHhlzEDHibFEq+Xuo6EhBZCl8pKXVnOYQNw= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1421232973-3758-3757/12/108; Wed, 14 Jan 2015 10:56:13 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Wed, 14 Jan 2015 11:56:13 +0100 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.6; X11; Linux; Ubuntu 14.04.1 LTS Mime-Version: 1.0 Message-Id: <679506e9-c52b-46d5-8e39-d4c943e89621@gulbrandsen.priv.no> In-Reply-To: References: <20150111215428.13470.qmail@ary.lan> <632a2444-bb0f-4ce9-ad40-4f378f856a57@gulbrandsen.priv.no> <20150113021011.18290.qmail@ary.lan> <46d08f77a738c09bc65d3ba47d4eabecdad3bee307f423e09990ed368d6efaad.sha-256@android.antelope.email> <20150113155123.21938.qmail@ary.lan> <1e2448a8-95ef-4ad5-baa0-d439c5013b06@gulbrandsen.priv.no> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jan 2015 10:56:20 -0000 Claudio Allocchio writes: > ... there is a technical (implementation) problem, though... > DSNs come with MAIL FROM:<> ... and as far as I know (and Arnt > also verified this problem) current implementations do not DKIM > sign a message with such a MAIL FROM SMTP envelope... (maybe I'm > wrong... but I do not know of any way to make this...). I looked closer, and I now think many current mail servers will sign DSNs. The envelope of a DSN says <>, but the From field of most DSNs says something along the lines of mailer-daemon@example.org, and the most common DKIM implementation looks at the latter when choosing whether to sign, not the former. In my case it wasn't set up to sign for all the domains (long story), notably not the domain it used in the DSN. Arnt From nobody Wed Jan 14 05:15:57 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777251B2C8C for ; Wed, 14 Jan 2015 05:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.469 X-Spam-Level: X-Spam-Status: No, score=0.469 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJvBT3Uitkyr for ; Wed, 14 Jan 2015 05:15:50 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D3A1B2C9A for ; Wed, 14 Jan 2015 05:15:48 -0800 (PST) Received: internal info suppressed Date: Wed, 14 Jan 2015 14:15:42 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@synx02.dir.garr.it To: Arnt Gulbrandsen In-Reply-To: <679506e9-c52b-46d5-8e39-d4c943e89621@gulbrandsen.priv.no> Message-ID: References: <20150111215428.13470.qmail@ary.lan> <632a2444-bb0f-4ce9-ad40-4f378f856a57@gulbrandsen.priv.no> <20150113021011.18290.qmail@ary.lan> <46d08f77a738c09bc65d3ba47d4eabecdad3bee307f423e09990ed368d6efaad.sha-256@android.antelope.email> <20150113155123.21938.qmail@ary.lan> <1e2448a8-95ef-4ad5-baa0-d439c5013b06@gulbrandsen.priv.no> <679506e9-c52b-46d5-8e39-d4c943e89621@gulbrandsen.priv.no> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1421241343; bh=rQ8DIHQnVsWmygP2hKki9uAv93hLONZu0bOs97LCics=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=cnSyo3n2NVcdoLEnUZD6YQiN8dmyfxpfZbKMjk2JUFa+TkA4vRFNwsiDoDcjhPqV+ IQIV3Hhp1FjhcCWtj8JQROU4GaIIxB6sv60XKYMkJouhcXTzYw4HazQAHeMojnZKel qvS1r1kR014u0TsCOnxDbNyfheUqw/1uC9y836WA= Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jan 2015 13:15:52 -0000 On Wed, 14 Jan 2015, Arnt Gulbrandsen wrote: > Claudio Allocchio writes: >> ... there is a technical (implementation) problem, though... DSNs come with >> MAIL FROM:<> ... and as far as I know (and Arnt also verified this problem) >> current implementations do not DKIM sign a message with such a MAIL FROM >> SMTP envelope... (maybe I'm wrong... but I do not know of any way to make >> this...). > > I looked closer, and I now think many current mail servers will sign DSNs. > > The envelope of a DSN says <>, but the From field of most DSNs says something > along the lines of mailer-daemon@example.org, and the most common DKIM > implementation looks at the latter when choosing whether to sign, not the > former. In my case it wasn't set up to sign for all the domains (long story), > notably not the domain it used in the DSN. you are right... here is the DKIM signed DSN coming from my MTAs including the non disclosed (into the message) ENVID field: ---- >From MAILER-DAEMON@garr.it Wed Jan 14 12:24:32 2015 Return-Path: <> Received: from cyrus-c1v2.dir.garr.it ([unix socket]) by cyrus-c1v2 (Cyrus v2.4.17) with LMTPA; Wed, 14 Jan 2015 12:24:32 +0100 X-Sieve: CMU Sieve 2.4 Received: internal info suppressed Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by lx1.dir.garr.it (8.14.4/8.14.4/Debian-4) with ESMTP id t0EBOTj3020160 for ; Wed, 14 Jan 2015 12:24:31 +0100 Received: internal info suppressed Date: Wed, 14 Jan 2015 12:24:29 +0100 From: Mail Delivery Subsystem Message-Id: <201501141124.t0EBOTGP016377@cyrus-c1v2.dir.garr.it> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="t0EBOTGP016377.1421234669/cyrus-c1v2.dir.garr.it" Subject: Return receipt Auto-Submitted: auto-generated (return-receipt) X-SPF-Scan-By: smf-spf v2.0.2 - http://smfs.sf.net/ Received-SPF: None (lx1.dir.garr.it: domain of postmaster@cyrus.dir.garr.it does not designate permitted sender hosts) receiver=lx1.dir.garr.it; client-ip=193.206.158.29; envelope-from=<>; helo=cyrus.dir.garr.it; X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.9 (lx1.dir.garr.it [193.206.158.2]); Wed, 14 Jan 2015 12:24:31 +0100 (CET) X-Virus-Scanned: clamav-milter 0.98.1 at lx1.dir.garr.it X-Virus-Status: Clean DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1421234672; bh=A37ASKIvn5BhAA3FyX2tP3i/Wyjh+GUmf8Mn+w65g1s=; h=Date:From:To:Subject; b=YBzrPn0vyDleEKMrs2YYmdpRnh7taCu3JTPfXbzcYRAK0GR9gtkxQNpOaEbwMERff TxwGRbz1f0mxkCJ+prwNcNvE1qIrrcT2NFT1U1czy0NfniVFjYCXX7BilKhkgie5CF 0zjr3Hj+r3woWuHHsSaYizDpcZ/paOte/LKVjaV8= The original message was received at Wed, 14 Jan 2015 12:24:29 +0100 from lx1.dir.garr.it [193.206.158.2] ----- The following addresses had successful delivery notifications ----- (successfully delivered to mailbox) ----- Transcript of session follows ----- ... Successfully delivered [ Part 2: "Delivery Status" ] Original-Envelope-Id: LOCALTEST14JAN2015122214010512 Reporting-MTA: dns; cyrus-c1v2.dir.garr.it Received-From-MTA: DNS; lx1.dir.garr.it Arrival-Date: Wed, 14 Jan 2015 12:24:29 +0100 Final-Recipient: RFC822; claudio@mail1v2.dir.garr.it X-Actual-Recipient: RFC822; claudio@cyrus-c1v2.dir.garr.it Action: delivered (to mailbox) Status: 2.1.5 Diagnostic-Code: SMTP; 250 2.1.5 ok Last-Attempt-Date: Wed, 14 Jan 2015 12:24:29 +0100 Return-Path: Received: internal info suppressed X-DSN-ENVID: LOCALTEST14JAN2015122214010512 Received: from 140.105.1.2 (synx02.dir.garr.it [140.105.1.2]) by lx1.dir.garr.it (8.14.4/8.14.4/Debian-4) with ESMTP id t0EBME7S019344 for ; Wed, 14 Jan 2015 12:23:25 +0100 Message-Id: <201501141123.t0EBME7S019344@lx1.dir.garr.it> From: Claudio.Allocchio@garr.it To: Claudio.Allocchio@garr.it Subject: DKIM+ENVID local test Date: 14-JAN-2015 12:24 CET X-Greylist: Sender e-mail whitelisted, not delayed by milter-greylist-4.3.9 (lx1.dir.garr.it [193.206.158.2]); Wed, 14 Jan 2015 12:24:27 +0100 (CET) X-Virus-Scanned: clamav-milter 0.98.1 at lx1.dir.garr.it X-Virus-Status: Clean DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1421234669; bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=; h=From:To:Subject:Date; b=tb0eNsjrOJb6TACrzrcIp2VDs2qkShVB/QD8ZDfVuBmTs00MSGDudqOlgasZZMEZV 5sZGvGKqbIVCOyZzSvRusaWkjpQRwmTa9kVu7xZ/dDjT7ZtpUGHtkUNIQzvCG43Zjb PVcvAdrhW+w52TR4veHC+DEVTebFZqb6rLDz+F+k= ---- So, for any further test we can point in case to lx1.dir.garr.it and lx5.dir.garr.it... With such a DSN, the sender can be sure that somebody called cyrus-c1v2.dir.garr.it has delivered the message he sent marked as LOCALTEST14JAN2015122214010512 to a mailbox named claudio@mail1v2.dir.garr.it and the owner of cyrus-c1v2.dir.garr.it cannot resonably repudiate that this machine generated the DSN. Is this enough? I guess that for average use over the Open Internet "as it is now" this IS enough, and also in case one legal case can say it is enough. DNSSEC would defintly fix also the trust problem... but ... > > Arnt > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Wed Jan 14 05:23:08 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B56B1B2C9E for ; Wed, 14 Jan 2015 05:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4v31LbYAbVT9 for ; Wed, 14 Jan 2015 05:23:02 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19DD1A8AAE for ; Wed, 14 Jan 2015 05:23:01 -0800 (PST) Received: internal info suppressed Date: Wed, 14 Jan 2015 14:22:55 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@synx02.dir.garr.it To: Claudio Allocchio In-Reply-To: Message-ID: References: <20150111215428.13470.qmail@ary.lan> <632a2444-bb0f-4ce9-ad40-4f378f856a57@gulbrandsen.priv.no> <20150113021011.18290.qmail@ary.lan> <46d08f77a738c09bc65d3ba47d4eabecdad3bee307f423e09990ed368d6efaad.sha-256@android.antelope.email> <20150113155123.21938.qmail@ary.lan> <1e2448a8-95ef-4ad5-baa0-d439c5013b06@gulbrandsen.priv.no> <679506e9-c52b-46d5-8e39-d4c943e89621@gulbrandsen.priv.no> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1421241776; bh=xMRiGkyhBlghjQNtEsTFE4L2zW/M/S/rJ+/CEyMDW3I=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=NNuaeOM3x3OmTuN+H/FHYrNyaOLNoKBzNyfYrLdBH5DUccqR2X3VRduHYy8YpXKwr FGq7BRoUtzCwJ3WXxO5SMihBVsYsFlgQ7hI3/FbM4WnWhYWi0OvDD1t0XkBKsbyPSd 7vMC6NuwNrVpWFEY70JsXVH6WnuEUIPTCBm6gTOs= Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jan 2015 13:23:05 -0000 ops... sorry, I copy/pasted the wrong DSN example (the one where I foced the ENVID to be shown in the headers - not the default!). Here is the corect couple of "received message" and "DSN": --- >From claudio.allocchio@garr.it Wed Jan 14 14:07:29 2015 Return-Path: Received: from cyrus-c1v2.dir.garr.it ([unix socket]) by cyrus-c1v2 (Cyrus v2.4.17) with LMTPA; Wed, 14 Jan 2015 14:07:29 +0100 X-Sieve: CMU Sieve 2.4 Received: internal info suppressed Received: from 140.105.1.2 (synx02.dir.garr.it [140.105.1.2]) by lx1.dir.garr.it (8.14.4/8.14.4/Debian-4) with ESMTP id t0ED6t4l000515 for ; Wed, 14 Jan 2015 14:07:27 +0100 Date: Wed, 14 Jan 2015 14:06:55 +0100 From: claudio.allocchio@garr.it Message-Id: <201501141307.t0ED6t4l000515@lx1.dir.garr.it> X-Greylist: Sender e-mail whitelisted, not delayed by milter-greylist-4.3.9 (lx1.dir.garr.it [193.206.158.2]); Wed, 14 Jan 2015 14:07:27 +0100 (CET) X-Virus-Scanned: clamav-milter 0.98.1 at lx1.dir.garr.it X-Virus-Status: Clean DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1421240849; bh=ReAL9pORYWYuuZJelufTOuqRnuIQpODVpiiRzjPRJpk=; h=Date:From; b=rDQYwm8w+32rsh+13bHil4S32dl7l7iawEdcZ33gbE6H6AdumaCU8iT0pxur9oxL2 rFOHTlg0j6EozQXHsl263csimE6kJFp5uigAlql4C1qBwtfAyK7kWZxZOcsr2AB8QS Y0cAj9UnURLtduvhbb6dNK4VE4yYxLPVDEIyWz94= test --- the DSN: --- >From MAILER-DAEMON@garr.it Wed Jan 14 14:07:31 2015 Return-Path: <> Received: from cyrus-c1v2.dir.garr.it ([unix socket]) by cyrus-c1v2 (Cyrus v2.4.17) with LMTPA; Wed, 14 Jan 2015 14:07:31 +0100 X-Sieve: CMU Sieve 2.4 Received: internal info suppressed Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by lx1.dir.garr.it (8.14.4/8.14.4/Debian-4) with ESMTP id t0ED7T5a000808 for ; Wed, 14 Jan 2015 14:07:31 +0100 Received: internal info suppressed Date: Wed, 14 Jan 2015 14:07:29 +0100 From: Mail Delivery Subsystem Message-Id: <201501141307.t0ED7T3V025633@cyrus-c1v2.dir.garr.it> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="t0ED7T3V025633.1421240849/cyrus-c1v2.dir.garr.it" Subject: Return receipt Auto-Submitted: auto-generated (return-receipt) X-SPF-Scan-By: smf-spf v2.0.2 - http://smfs.sf.net/ Received-SPF: None (lx1.dir.garr.it: domain of postmaster@cyrus.dir.garr.it does not designate permitted sender hosts) receiver=lx1.dir.garr.it; client-ip=193.206.158.29; envelope-from=<>; helo=cyrus.dir.garr.it; X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.9 (lx1.dir.garr.it [193.206.158.2]); Wed, 14 Jan 2015 14:07:31 +0100 (CET) X-Virus-Scanned: clamav-milter 0.98.1 at lx1.dir.garr.it X-Virus-Status: Clean DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1421240851; bh=8h9Y+427SSgCqB7xEjT6Cwpko9OfLwsjQpU3Z2qG0qk=; h=Date:From:To:Subject; b=uvKpdNw/X6ad8mmhh23KUZLSedLfkxE2hVvjtYaKnsFvLwnqwJCCNzt7l8FHIBuvw Q0PbfqGU7j4egwyu8j4ebThlaWCmzFBxtiDXaVE7Vs+9/3RMJn4YDXCylGEzNx0lkE +kKtzP3tIvvXlbgwcQrD5dM1mSPK+olkvNiPQENw= The original message was received at Wed, 14 Jan 2015 14:07:29 +0100 from lx1.dir.garr.it [193.206.158.2] ----- The following addresses had successful delivery notifications ----- (successfully delivered to mailbox) ----- Transcript of session follows ----- ... Successfully delivered [ Part 2: "Delivery Status" ] Original-Envelope-Id: LOCALTEST14JAN2015BIS122214010512 Reporting-MTA: dns; cyrus-c1v2.dir.garr.it Received-From-MTA: DNS; lx1.dir.garr.it Arrival-Date: Wed, 14 Jan 2015 14:07:29 +0100 Final-Recipient: RFC822; claudio@mail1v2.dir.garr.it X-Actual-Recipient: RFC822; claudio@cyrus-c1v2.dir.garr.it Action: delivered (to mailbox) Status: 2.1.5 Diagnostic-Code: SMTP; 250 2.1.5 ok Last-Attempt-Date: Wed, 14 Jan 2015 14:07:29 +0100 Return-Path: Received: internal info suppressed Received: from 140.105.1.2 (synx02.dir.garr.it [140.105.1.2]) by lx1.dir.garr.it (8.14.4/8.14.4/Debian-4) with ESMTP id t0ED6t4l000515 for ; Wed, 14 Jan 2015 14:07:27 +0100 Date: Wed, 14 Jan 2015 14:06:55 +0100 From: claudio.allocchio@garr.it Message-Id: <201501141307.t0ED6t4l000515@lx1.dir.garr.it> X-Greylist: Sender e-mail whitelisted, not delayed by milter-greylist-4.3.9 (lx1.dir.garr.it [193.206.158.2]); Wed, 14 Jan 2015 14:07:27 +0100 (CET) X-Virus-Scanned: clamav-milter 0.98.1 at lx1.dir.garr.it X-Virus-Status: Clean DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1421240849; bh=ReAL9pORYWYuuZJelufTOuqRnuIQpODVpiiRzjPRJpk=; h=Date:From; b=rDQYwm8w+32rsh+13bHil4S32dl7l7iawEdcZ33gbE6H6AdumaCU8iT0pxur9oxL2 rFOHTlg0j6EozQXHsl263csimE6kJFp5uigAlql4C1qBwtfAyK7kWZxZOcsr2AB8QS Y0cAj9UnURLtduvhbb6dNK4VE4yYxLPVDEIyWz94= --- ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Wed Jan 14 10:00:43 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD3B1A916B for ; Wed, 14 Jan 2015 10:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTsKKqo5DErF for ; Wed, 14 Jan 2015 10:00:37 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA901A9129 for ; Wed, 14 Jan 2015 10:00:37 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PHAY65LZKW00CTYB@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 14 Jan 2015 09:55:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1421258131; bh=2ggwlJCXpy2d2UQbnUBvKBEc4w6JI4TbDptxq8gP0U4=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=r7E0whm5m5Gc61y/8iGa3o8nGxAx/ZSQ1OX0r9yKKJybzsYjUz53kI3BWGY6ToMuY c/tTfE4vof50n2u1cyMZU1bmMQK2hswjY9k7xac0GHQ/09AxQCwp2F52kxh09jEF2X 9wJp+1sba3jsu+b3HKiyg77xGZm3tnHYPYtem+tU= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PH4G1QXR7400FTL0@mauve.mrochek.com>; Wed, 14 Jan 2015 09:55:25 -0800 (PST) Message-id: <01PHAY6286CU00FTL0@mauve.mrochek.com> Date: Wed, 14 Jan 2015 09:15:31 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 14 Jan 2015 14:15:42 +0100 (CET)" References: <20150111215428.13470.qmail@ary.lan> <632a2444-bb0f-4ce9-ad40-4f378f856a57@gulbrandsen.priv.no> <20150113021011.18290.qmail@ary.lan> <46d08f77a738c09bc65d3ba47d4eabecdad3bee307f423e09990ed368d6efaad.sha-256@android.antelope.email> <20150113155123.21938.qmail@ary.lan> <1e2448a8-95ef-4ad5-baa0-d439c5013b06@gulbrandsen.priv.no> <679506e9-c52b-46d5-8e39-d4c943e89621@gulbrandsen.priv.no> To: Claudio Allocchio Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jan 2015 18:00:40 -0000 > On Wed, 14 Jan 2015, Arnt Gulbrandsen wrote: > > Claudio Allocchio writes: > >> ... there is a technical (implementation) problem, though... DSNs come with > >> MAIL FROM:<> ... and as far as I know (and Arnt also verified this problem) > >> current implementations do not DKIM sign a message with such a MAIL FROM > >> SMTP envelope... (maybe I'm wrong... but I do not know of any way to make > >> this...). > > > > I looked closer, and I now think many current mail servers will sign DSNs. > > > > The envelope of a DSN says <>, but the From field of most DSNs says something > > along the lines of mailer-daemon@example.org, and the most common DKIM > > implementation looks at the latter when choosing whether to sign, not the > > former. In my case it wasn't set up to sign for all the domains (long story), > > notably not the domain it used in the DSN. > you are right... here is the DKIM signed DSN coming from my MTAs including > the non disclosed (into the message) ENVID field: > ... > [ Part 2: "Delivery Status" ] > ---- > So, for any further test we can point in case to lx1.dir.garr.it and > lx5.dir.garr.it... > With such a DSN, the sender can be sure that somebody called > cyrus-c1v2.dir.garr.it has delivered the message he sent marked as > LOCALTEST14JAN2015122214010512 to a mailbox named > claudio@mail1v2.dir.garr.it > and > the owner of cyrus-c1v2.dir.garr.it cannot resonably repudiate that this > machine generated the DSN. Actually, it can do no such thing, for the simple reason that most systems that sign DKIM mail blindly sign anything that an authenticated user sends out that has the appropriate domain in the From: field. So all someone who happens to have an account on the system has to do is intercept the message, then send out a DSN for that message using their account. That message will be DKIM signed along with all the rest of the mail that system sends out. And even in the unlikely event that you can trust all your users, can you trust all their equipment not to have been messed with? No, I didn't think you could. Of course there may be evidence of this being done: IP addresses in the DSN header, etc. And the log files on the receiving system, assuming a sufficient level of detail and retention, will definitely tell the real story. But regardless, my point is made: If you're operating in a scenario where there's a significant risk of mail being intercepted, then DKIM signatures offer little if any additional assurance. And before anyone says that the fix for this is to prevent regular users from submitting DSNs, allow me to point out that there are any number of mail reinjection/forwarder/downloader/hosted-domain scenarios where this is an essential thing to be able to do. Indeed, by blocking those DSNs, you may be causing a problem that's pretty close to the one you're trying to solve. > Is this enough? I guess that for average use over the Open Internet "as it > is now" this IS enough, and also in case one legal case can say it is > enough. DNSSEC would defintly fix also the trust problem... but ... The evidence on the ground says that unsigned DSNs are enough for most email users. Ned From nobody Wed Jan 14 13:53:24 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F6E1ACD39 for ; Wed, 14 Jan 2015 13:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMbmCeCAx3d9 for ; Wed, 14 Jan 2015 13:53:19 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6B4B1ACCEB for ; Wed, 14 Jan 2015 13:53:18 -0800 (PST) Received: internal info suppressed Date: Wed, 14 Jan 2015 22:53:09 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio5.garrtest.units.it To: Ned Freed In-Reply-To: <01PHAY6286CU00FTL0@mauve.mrochek.com> Message-ID: References: <20150111215428.13470.qmail@ary.lan> <632a2444-bb0f-4ce9-ad40-4f378f856a57@gulbrandsen.priv.no> <20150113021011.18290.qmail@ary.lan> <46d08f77a738c09bc65d3ba47d4eabecdad3bee307f423e09990ed368d6efaad.sha-256@android.antelope.email> <20150113155123.21938.qmail@ary.lan> <1e2448a8-95ef-4ad5-baa0-d439c5013b06@gulbrandsen.priv.no> <679506e9-c52b-46d5-8e39-d4c943e89621@gulbrandsen.priv.no> <01PHAY6286CU00FTL0@mauve.mrochek.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1421272390; bh=Lp4uuQdUP22s4RuWlCDiuXNdWX6Omr0eAiw+11/R088=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MdKbZb6pRNi28qwEaX31V2icRubeEV3b+KEGF4/R4beAU+5JXkXAt/7W3LsdDZ7zx CG/H1FOD3Xmo4Xtj35WJfIr3XYIqa7MzUovOtfcpPKNVpganiwHgU0tX++Aq4Y5lKq 04dx4upXquWsedBjoFuIaWHr8z6joPxuIC6B134s= Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jan 2015 21:53:21 -0000 >> With such a DSN, the sender can be sure that somebody called >> cyrus-c1v2.dir.garr.it has delivered the message he sent marked as >> LOCALTEST14JAN2015122214010512 to a mailbox named >> claudio@mail1v2.dir.garr.it > >> and > >> the owner of cyrus-c1v2.dir.garr.it cannot resonably repudiate that this >> machine generated the DSN. > > Actually, it can do no such thing, for the simple reason that most systems > that sign DKIM mail blindly sign anything that an authenticated user sends > out > that has the appropriate domain in the From: field. True... but... > So all someone who > happens to have an account on the system has to do is intercept the message, > then send out a DSN for that message using their account. That message will > be DKIM signed along with all the rest of the mail that system sends out. but he/she cannot know the ENVID value. It is not in the message (see my correct couple of "message"+"DSN"), and it is "lost" on the recipient MTA after delivery. So the DSN the "interceptor" generates is missing one element (the ENVID value) and the sender can resonably suspect something is wrong. The "ENVID" you can intercept only on the fly transaction. > And even in the unlikely event that you can trust all your users, can you > trust > all their equipment not to have been messed with? No, I didn't think you > could. No, I cannot trust both users and equipment... but the sender can find out easily (no ENVID value in the DSN) that the DSN is fake, and see below your own observation... > Of course there may be evidence of this being done: IP addresses in the > DSN header, etc. And the log files on the receiving system, assuming a > sufficient level of detail and retention, will definitely tell the real > story. And this is the "notary" function of the receiving system. So it will be evident what happened. > But regardless, my point is made: If you're operating in a scenario where > there's a significant risk of mail being intercepted, then DKIM signatures > offer little if any additional assurance. True, mail can be intercepted and DSNs can be faked, but with the combination of an additional field, making fake DSNs is much more complicated, and makes the quite evident. Do you agree on this? > And before anyone says that the fix for this is to prevent regular users from > submitting DSNs, allow me to point out that there are any number of mail > reinjection/forwarder/downloader/hosted-domain scenarios where this is an > essential thing to be able to do. Indeed, by blocking those DSNs, you may be > causing a problem that's pretty close to the one you're trying to solve. I agree and this has not to be done, there is no need. It is not problem if a user can submit a fake DSN, if there are easy ways to find out the trick and invalidate the fake DSN, is it? >> Is this enough? I guess that for average use over the Open Internet "as it >> is now" this IS enough, and also in case one legal case can say it is >> enough. DNSSEC would defintly fix also the trust problem... but ... > > The evidence on the ground says that unsigned DSNs are enough for most email > users. True... but not if you find somebody who then negate he ever received the message in the mailbox (reading it it's a completely different story). I think that having a setup where an MTA cannot negate it sendout that specific DSN, and it is evident if the DSN was faked by a user or by some other system/process is further level of assurance. Most users will not care in many cases of this further level, but some will: imagine I want to send in via email my application for a job within a deadline, and need to prove I sent it and it was delivered in time to a mailbox, and I need some reasonble way to prove this is case somebody deny it was delivered... As we said in the beginning, in a regulated scenario (closed community) we can even give legal value to mails and DSNs, but the above method can give some reasonable "+" value also in an Open invironment... > > Ned > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Wed Jan 14 14:36:45 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3749A1ACEA4 for ; Wed, 14 Jan 2015 14:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1ILpvpEVyrw for ; Wed, 14 Jan 2015 14:36:41 -0800 (PST) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 44B821ACEA7 for ; Wed, 14 Jan 2015 14:36:41 -0800 (PST) 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 1YBWYI-0002ZM-hM; Wed, 14 Jan 2015 22:36:38 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YBWYI-0007DP-Gt; Wed, 14 Jan 2015 22:36:38 +0000 Message-ID: <54B6EF74.3040300@ninebynine.org> Date: Wed, 14 Jan 2015 22:36:36 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin , "t.petch" References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> <036301d02e94$15a95200$4001a8c0@gateway.2wire.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jan 2015 22:36:43 -0000 On 13/01/2015 00:01, Matthew Kerwin wrote: > | The "file" URI scheme is woefully out of date. The document that defines > | it, RFC 1738, has been superseded by the generic URI syntax of RFC 3986, > | and its status is listed as "Obsolete". As such, the "file" URI scheme > | is viewed by many in the internet community as being without a current > | defining standard, and in need of updating to match current standards > | and implementations. > | > | This document defines an updated "file" URI scheme, promoting > | interoperability by being compatible with the generic syntax of > | RFC 3986, while enumerating commonly-encountered variations that have > | arisen during the scheme's long history of vague standardisation. > | > | Reviewers: > | > | * Julian Reschke > | * Nico Williams > | * Sean Leonard I think there are two useful facets for the putative revised file URI spec: 1. A normative syntax specification that defines a subset of RFC 3986 URI syntax that will be considered valid file: URI strings, and sufficient to cover common file: URI usage in the wild where it does not conflict with RFC3986. I think we need to be very careful about extending the scope of any normative specification beyond this. 2. An informative aspect that describes some common file: URI usages and how they map onto underlying file systems. This may reference proprietary documents, but since such material would be informative they wouldn't be normative references. BTW, I'll review, but I can't promise to be always timely. #g From nobody Wed Jan 14 14:51:59 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361351ACE50 for ; Wed, 14 Jan 2015 14:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BB5JTzMHVmA for ; Wed, 14 Jan 2015 14:51:53 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id A15421ACF5E for ; Wed, 14 Jan 2015 14:50:29 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PHB8ALDTFK00I5MX@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 14 Jan 2015 14:45:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1421275525; bh=p9ZNm0usZPDhWtfhrREXeBjeRvlH3IvxFuyhWp2t8aM=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=loSjbITQR4QcV5RCdrRRXQeU7ahYyDLdaXzLpsiLhZS5sKnC0qH6hFOMBTQ3R7yGR 5zIGjnqzzB7EyMk1+pJdGYKKjRdJiXEWFuWamBCx/kTxP2LEWva+eIZFJeSwlxYiWC 5D8Qcdcf6Pc/6N5ybe0GlVItFhdogxrrq8ahfzxM= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PH4G1QXR7400FTL0@mauve.mrochek.com>; Wed, 14 Jan 2015 14:45:20 -0800 (PST) Message-id: <01PHB8AHXGVS00FTL0@mauve.mrochek.com> Date: Wed, 14 Jan 2015 13:59:48 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 14 Jan 2015 22:53:09 +0100 (CET)" References: <20150111215428.13470.qmail@ary.lan> <632a2444-bb0f-4ce9-ad40-4f378f856a57@gulbrandsen.priv.no> <20150113021011.18290.qmail@ary.lan> <46d08f77a738c09bc65d3ba47d4eabecdad3bee307f423e09990ed368d6efaad.sha-256@android.antelope.email> <20150113155123.21938.qmail@ary.lan> <1e2448a8-95ef-4ad5-baa0-d439c5013b06@gulbrandsen.priv.no> <679506e9-c52b-46d5-8e39-d4c943e89621@gulbrandsen.priv.no> <01PHAY6286CU00FTL0@mauve.mrochek.com> To: Claudio Allocchio Archived-At: Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jan 2015 22:51:56 -0000 > >> With such a DSN, the sender can be sure that somebody called > >> cyrus-c1v2.dir.garr.it has delivered the message he sent marked as > >> LOCALTEST14JAN2015122214010512 to a mailbox named > >> claudio@mail1v2.dir.garr.it > > > >> and > > > >> the owner of cyrus-c1v2.dir.garr.it cannot resonably repudiate that this > >> machine generated the DSN. > > > > Actually, it can do no such thing, for the simple reason that most systems > > that sign DKIM mail blindly sign anything that an authenticated user sends > > out > > that has the appropriate domain in the From: field. > True... but... > > So all someone who > > happens to have an account on the system has to do is intercept the message, > > then send out a DSN for that message using their account. That message will > > be DKIM signed along with all the rest of the mail that system sends out. > but he/she cannot know the ENVID value. Of course they do. In my proposed scenario they intercepted the message and it was part of the transaction. But this is really beside the point. The issue at hand is your claim that, to use your own words, "the owner of cyrus-c1v2.dir.garr.it cannot resonably repudiate that this machine generated the DSN". I just showed that that claim isn't reasonable in general, and that in particular DKIM adds almost no additional value in this context. All the owner of cyrus-c1v2.dir.garr.it has to do is point out that the message could have been intercepted, the ENVID determined, and the DSN forged. And then deline your request for them to check their logs, because why should they waste their time doing that for you? > It is not in the message (see my > correct couple of "message"+"DSN"), and it is "lost" on the recipient MTA > after delivery. So the DSN the "interceptor" generates is missing one > element (the ENVID value) and the sender can resonably suspect something > is wrong. The "ENVID" you can intercept only on the fly transaction. You seem to have a very different understanding of how the DSN extension works than I do. > > And even in the unlikely event that you can trust all your users, can you > > trust > > all their equipment not to have been messed with? No, I didn't think you > > could. > No, I cannot trust both users and equipment... but the sender can find out > easily (no ENVID value in the DSN) that the DSN is fake, and see below > your own observation... > > Of course there may be evidence of this being done: IP addresses in the > > DSN header, etc. And the log files on the receiving system, assuming a > > sufficient level of detail and retention, will definitely tell the real > > story. > And this is the "notary" function of the receiving system. So it will be > evident what happened. Not to the recipient of the DSN, it won't. Even if they check both the ENVID and DKIM signature. > > But regardless, my point is made: If you're operating in a scenario where > > there's a significant risk of mail being intercepted, then DKIM signatures > > offer little if any additional assurance. > True, mail can be intercepted and DSNs can be faked, but with the > combination of an additional field, making fake DSNs is much more > complicated, and makes the quite evident. Do you agree on this? You appear to be focusing on a threat I see as a nonissue - that of sending random DSNs to people that don't correspond to a message they actually sent. Or alternately, on DSNs sent to people with knowledge of the message content only and no knowledge of the full transaction or interference in the actual message transfer. If you want to make a cogent case for the serious dangers inherent in receiving a fake failure DSN for a message that was actually delivered, or a success DSN (which the originator almost certainly didn't ask for) in addition to the failure DSN for a message that failed, or some other combination, I'll be happy to consider it. But until you do, I regard this as having nuisance value only. > > And before anyone says that the fix for this is to prevent regular users from > > submitting DSNs, allow me to point out that there are any number of mail > > reinjection/forwarder/downloader/hosted-domain scenarios where this is an > > essential thing to be able to do. Indeed, by blocking those DSNs, you may be > > causing a problem that's pretty close to the one you're trying to solve. > I agree and this has not to be done, there is no need. It is not problem > if a user can submit a fake DSN, if there are easy ways to find out the > trick and invalidate the fake DSN, is it? There aren't any in the scenario I proposed. > >> Is this enough? I guess that for average use over the Open Internet "as it > >> is now" this IS enough, and also in case one legal case can say it is > >> enough. DNSSEC would defintly fix also the trust problem... but ... > > > > The evidence on the ground says that unsigned DSNs are enough for most email > > users. > True... but not if you find somebody who then negate he ever received the > message in the mailbox (reading it it's a completely different story). > I think that having a setup where an MTA cannot negate it sendout that > specific DSN, and it is evident if the DSN was faked by a user or by some > other system/process is further level of assurance. It isn't because there is no such assurance. See above. > Most users will not > care in many cases of this further level, but some will: imagine I want to > send in via email my application for a job within a deadline, and need to > prove I sent it and it was delivered in time to a mailbox, and I need some > reasonble way to prove this is case somebody deny it was delivered... In this scenario the service you actually want is nonrepudiation of submission and nonrepudiation of transfer. (The reality on the ground is that so few large email services support the DSN extension that getting confirmation, let alone nonrepudiation, of delivery through the use of success DSNs is not really practical. But nonrepudiation of transfer is good enough in this case.) And the way you get this is through a third party service, which in effect signs the combination of your message, the time it was sent, and the log showing its successful transfer to the destination system. This is precisely the service that RPost, and probably a bunch of others, provide. For a fee, of course, but if you really need this sort of assurance you should be prepared to pay for it. Sure, it would be nice to be able to get this capability without having to pay for it. But the reality is that nobody with any sense is going to accept the potential liability of, say, warranting that the DKIM signatures on success DSNs actually provide nonrepudiation of delivery. > As we said in the beginning, in a regulated scenario (closed community) we > can even give legal value to mails and DSNs, but the above method can give > some reasonable "+" value also in an Open invironment... Not really. See above. Ned From nobody Wed Jan 14 14:59:20 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E401ACF58 for ; Wed, 14 Jan 2015 14:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2od1yRjcSx7G for ; Wed, 14 Jan 2015 14:59:16 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138C71ACF54 for ; Wed, 14 Jan 2015 14:59:16 -0800 (PST) Received: by mail-qg0-f42.google.com with SMTP id q108so9393102qgd.1 for ; Wed, 14 Jan 2015 14:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4VY93sbSKX+ExF3P+RAkMuIJaPlrjgu9e/nKbNsRHDY=; b=xWx/p6SdHTtRJ3bWFvCOVJSPJoff4MFOTBVd5AuN3E77Rq3mnZgawC6Wjz9IC5Ho6N qd69U+k2G1z4U/Kt9UlcSRecLLHogYXF8ExNhCTNkUJh4+Gc8u1iQjmdz00y0WVwdUQs 7Oo2rcy0xLRN/+Kb59BzMS2CeIJZiGPXxDYsLu8TD6eqFspS4LeWi4eKTDk5fV+op98f 2JSwVNP3lxM1YMcFo/jNcws9otke90OXZyBP1iCNUeUmjf30kXBP4Y+VWXzDhjBk8NSQ xIskwaask+zSpiITL1kG0mFkPyS0khZtvIPQzZjkYeCbxlvwpeOLdIOFBn93pfS6zwVZ umtA== MIME-Version: 1.0 X-Received: by 10.229.70.133 with SMTP id d5mr11577532qcj.2.1421276355181; Wed, 14 Jan 2015 14:59:15 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Wed, 14 Jan 2015 14:59:15 -0800 (PST) In-Reply-To: <54B6EF74.3040300@ninebynine.org> References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> <036301d02e94$15a95200$4001a8c0@gateway.2wire.net> <54B6EF74.3040300@ninebynine.org> Date: Thu, 15 Jan 2015 08:59:15 +1000 X-Google-Sender-Auth: oJB1QlnLOZdy8UofMXWd2bHqbpQ Message-ID: From: Matthew Kerwin To: Graham Klyne Content-Type: multipart/alternative; boundary=001a113390064755ae050ca4b0ef Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jan 2015 22:59:18 -0000 --001a113390064755ae050ca4b0ef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15 January 2015 at 08:36, Graham Klyne wrote: > > I think there are two useful facets for the putative revised file URI spe= c: > > 1. A normative syntax specification that defines a subset of RFC 3986 UR= I > syntax that will be considered valid file: URI strings, and sufficient to > cover common file: URI usage in the wild where it does not conflict with > RFC3986. I think we need to be very careful about extending the scope of > any normative specification beyond this. > > 2. An informative aspect that describes some common file: URI usages and > how they map onto underlying file systems. This may reference proprietar= y > documents, but since such material would be informative they wouldn't be > normative references. > > I think it's good to add specific deliverables like this. I'm pretty sure the current text at < https://github.com/phluid61/internet-drafts/blob/master/file-scheme/mini-ch= arter.md> captures everything we want to say, and doesn't leave anything too vague. Not too long? > =E2=80=8B > =E2=80=8B =E2=80=8B > BTW, I'll review, but I can't promise to be always timely. > =E2=80=8B > > I'm pretty sure lots of people are in the same boat. As long as all discussion happens here on the list, I don't doubt there'll be more than three people with opinions on most aspects of the text. Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a113390064755ae050ca4b0ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 15 January 2015 at 08:36, Graham Klyne <gk@ninebynine.org&g= t; = wrote:

 I think there are two useful facets for the putative revised file URI spec:=

1.=C2=A0 A normative syntax specification that defines a subset of RFC 3986= URI syntax that will be considered valid file: URI strings, and sufficient= to cover common file: URI usage in the wild where it does not conflict wit= h RFC3986.=C2=A0 I think we need to be very careful about extending the sco= pe of any normative specification beyond this.

2. An informative aspect that describes some common file: URI usages and ho= w they map onto underlying file systems.=C2=A0 This may reference proprieta= ry documents, but since such material would be informative they wouldn'= t be normative references.


I think it's good to add = specific deliverables like this. I'm pretty sure the current text at &l= t;https://github.com/phluid61/internet-drafts/blob/mas= ter/file-scheme/mini-charter.md> captures everything we want to say,= and doesn't leave anything too vague. Not too long?

=

=C2=A0
=E2=80=8B
=E2=80=8B
=E2=80=8B
BTW, I'll review, but I can't pr= omise to be always timely.
=E2=80=8B


I'm pretty sure lots of people are in the same boat. As long as all= discussion happens here on the list, I don't doubt there'll be mor= e than three people with opinions on most aspects of the text.


Cheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.= au/
--001a113390064755ae050ca4b0ef-- From nobody Wed Jan 14 15:03:51 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17C41AD351 for ; Wed, 14 Jan 2015 15:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ_ECeqVMUma for ; Wed, 14 Jan 2015 15:03:47 -0800 (PST) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id D363F1ACF54 for ; Wed, 14 Jan 2015 15:03:46 -0800 (PST) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YBWyX-0004pe-id; Wed, 14 Jan 2015 23:03:45 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YBWyX-00059H-Lb; Wed, 14 Jan 2015 23:03:45 +0000 Message-ID: <54B6F5D0.7070506@ninebynine.org> Date: Wed, 14 Jan 2015 23:03:44 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , Julian Reschke References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2ABA8.6030205@gmx.de> <54B2C6FA.80802@intertwingly.net> <54B2EE08.9040705@gmx.de> <54B2F527.7040404@intertwingly.net> In-Reply-To: <54B2F527.7040404@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jan 2015 23:03:49 -0000 On 11/01/2015 22:11, Sam Ruby wrote: > There is no question that a change to the "ASCII-ness" of schemes is clearly a > non-starter. But I would hope that we could discuss whether a change to the > "ASCII-ness" of fragments is a possibility. In particular, I don't believe that > there is any reason why a URL parser (in a browser or elsewhere) needs to > percent encode fragments. Changing the ASCII-ness of URI fragments would almost certainly break a fair amount of my code. Maybe there is a general consensus that the gain is worth the pain for "marginal" applications such as mine (though I'm not hearing it)... But I can't help feeling that the place to attack this would be in IRIs, which turn have a defined mapping to ASCII-only URIs. (also, +1 to pretty much everything I've read that Julian has posted on this topic.) #g -- From nobody Wed Jan 14 15:10:05 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43D71ACEA6; Wed, 14 Jan 2015 15:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gz5TFumBd1_4; Wed, 14 Jan 2015 15:10:02 -0800 (PST) Received: from relay14.mail.ox.ac.uk (relay14.mail.ox.ac.uk [163.1.2.162]) by ietfa.amsl.com (Postfix) with ESMTP id ECCD21ACECB; Wed, 14 Jan 2015 15:10:01 -0800 (PST) Received: from smtp5.mail.ox.ac.uk ([163.1.2.207]) by relay14.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YBX4Z-0003ih-lR; Wed, 14 Jan 2015 23:09:59 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YBX4Z-0007zP-Ho; Wed, 14 Jan 2015 23:09:59 +0000 Message-ID: <54B6F745.4010207@ninebynine.org> Date: Wed, 14 Jan 2015 23:09:57 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , Sean Leonard References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <54B28E0F.8070306@gmx.de> <54B2936B.7030805@intertwingly.net> <05AD7DE2-1C54-45CD-B33A-13766D771E57@mnot.net> <54B2A2CD.5080502@gmx.de> <1A5BBD25-FEBD-49B1-9EFB-4EF8877BF0E7@mnot.net> <54B2A4F9.2070909@gmx.de> <54B2A894.4020201@intertwingly.net> <54B2F4C3.5020008@seantek.com> <54B2F806.2090509@intertwingly.net> In-Reply-To: <54B2F806.2090509@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: "pkix@ietf.org" , apps-discuss@ietf.org Subject: Re: [apps-discuss] character repertoire for fragment identifiers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jan 2015 23:10:03 -0000 On 11/01/2015 22:24, Sam Ruby wrote: > The topic is character repertoire for fragment identifiers, not schemes. I am > not suggesting that we allow non-US-ASCII protocols. *Some* protocols include URIs with fragments. (The restriction on not sending the fragment when dereferencing a URI is a specific to the way resource retrieval is handled on the web.) Even HTTP allows URIs with fragment identifiers in, say, Link: headers. #g -- From nobody Wed Jan 14 15:53:16 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F221B2A6B for ; Wed, 14 Jan 2015 15:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pqps4KKew1Oh for ; Wed, 14 Jan 2015 15:53:12 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABD9B1AD0A2 for ; Wed, 14 Jan 2015 15:53:11 -0800 (PST) Received: internal info suppressed Date: Thu, 15 Jan 2015 00:53:03 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio5.garrtest.units.it To: Ned Freed In-Reply-To: <01PHB8AHXGVS00FTL0@mauve.mrochek.com> Message-ID: References: <20150111215428.13470.qmail@ary.lan> <632a2444-bb0f-4ce9-ad40-4f378f856a57@gulbrandsen.priv.no> <20150113021011.18290.qmail@ary.lan> <46d08f77a738c09bc65d3ba47d4eabecdad3bee307f423e09990ed368d6efaad.sha-256@android.antelope.email> <20150113155123.21938.qmail@ary.lan> <1e2448a8-95ef-4ad5-baa0-d439c5013b06@gulbrandsen.priv.no> <679506e9-c52b-46d5-8e39-d4c943e89621@gulbrandsen.priv.no> <01PHAY6286CU00FTL0@mauve.mrochek.com> <01PHB8AHXGVS00FTL0@mauve.mrochek.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1421279584; bh=PWk7vuWsqm70yuw5Aba/gvr7lHnpVGv8pT7/Z+/rrnQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Inr/7l4zsukljVfTMAHg+vTOZN6TnNnoWmYvBT0YfdQz+2+GHZdRd+SZxBsFr2mPo Tiby94MUgmB/f1vOaJv+XRwa8wOpCMCSMVCLTZjvKWEoLhi7O3bOQf+bxaZue7uGou TpnWbotdqZ+ulVIBg8511UPx81/JUTx908DD5qIo= Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jan 2015 23:53:14 -0000 :-) let me continue a bit this brainstorming (also because it helps in clarifying some scenarios)... On Wed, 14 Jan 2015, Ned Freed wrote: > >> > So all someone who >> > happens to have an account on the system has to do is intercept the >> message, >> > then send out a DSN for that message using their account. That message >> will >> > be DKIM signed along with all the rest of the mail that system sends out. > >> but he/she cannot know the ENVID value. > > Of course they do. In my proposed scenario they intercepted the message and > it > was part of the transaction. a "normal" user of that system can intercept the message during the transation? No, unless the machine has been compromised (but in such a case we are in a different scenario). A system administrator can do that, of course, but again... we are in a different scenario where something has already gone quite wrong there. If we consider these scenarios, also third party certifications can go really wrong if machines or administrators are "compromised". > But this is really beside the point. The issue at hand is your claim that, to > use your own words, "the owner of cyrus-c1v2.dir.garr.it cannot resonably > repudiate that this machine generated the DSN". I just showed that that claim > isn't reasonable in general, and that in particular DKIM adds almost no > additional value in this context. > > All the owner of cyrus-c1v2.dir.garr.it has to do is point out that the > message > could have been intercepted, the ENVID determined, and the DSN forged. So they admit they have a compromised machine or bogus administrators. And yes, in such a situation they can deny... but they also declare a very bad unreliable service level (or a bad reputation, if you like). > And then deline your request for them to check their logs, because why > should they waste their time doing that for you? True, if they are unrealiable or just acting non correctly they can do that. > You seem to have a very different understanding of how the DSN extension > works > than I do. ? :) >> > And even in the unlikely event that you can trust all your users, can you >> > trust >> > all their equipment not to have been messed with? No, I didn't think you >> > could. > >> No, I cannot trust both users and equipment... but the sender can find out >> easily (no ENVID value in the DSN) that the DSN is fake, and see below >> your own observation... > >> > Of course there may be evidence of this being done: IP addresses in the >> > DSN header, etc. And the log files on the receiving system, assuming a >> > sufficient level of detail and retention, will definitely tell the real >> > story. > >> And this is the "notary" function of the receiving system. So it will be >> evident what happened. > > Not to the recipient of the DSN, it won't. Even if they check both the ENVID > and DKIM signature. True, but (at least IMHO) we are in a scenario where there is something really wrong at the recipeint side. >> > But regardless, my point is made: If you're operating in a scenario where >> > there's a significant risk of mail being intercepted, then DKIM >> signatures >> > offer little if any additional assurance. > >> True, mail can be intercepted and DSNs can be faked, but with the >> combination of an additional field, making fake DSNs is much more >> complicated, and makes the quite evident. Do you agree on this? > > You appear to be focusing on a threat I see as a nonissue - that of sending > random DSNs to people that don't correspond to a message they actually sent. no, this is not my issue. > Or > alternately, on DSNs sent to people with knowledge of the message content > only > and no knowledge of the full transaction or interference in the actual > message > transfer. which is the normal end user case. > If you want to make a cogent case for the serious dangers inherent in > receiving > a fake failure DSN for a message that was actually delivered, no again this is not my issue. > or a success > DSN > (which the originator almost certainly didn't ask for) in addition to the > failure DSN for a message that failed, or some other combination, Again not this issue. I'll be > happy > to consider it. But until you do, I regard this as having nuisance value > only. The scenario (and issue) is (I hoped it was already clear): - the user sends a message asking explicitly (via the MUA for example) NOTIFY=SUCCESS,FAILURE for one (or all) recipients; and the sender wants to know that the message was deivered to a mailbox which hopefully belongs to the intended recipient; and the sender wants some assurance that the postive DSN he receives is genuine and cannot be easily repudiated by the people running the recipient mailbox system. - if the sender receives a failure DSN, even if the message was actually delivered and this happen for whichever reason, again it is not an issue here; the sender has indeed accomplished a positive transaction to the recipient mailbox, but he thinks he has not. So... he will try again to send the message. Double delivery is not an issue for him. is this clear enough now ? (sorry if it was not... I thought it was...) >> > And before anyone says that the fix for this is to prevent regular users >> from >> > submitting DSNs, allow me to point out that there are any number of mail >> > reinjection/forwarder/downloader/hosted-domain scenarios where this is an >> > essential thing to be able to do. Indeed, by blocking those DSNs, you may >> be >> > causing a problem that's pretty close to the one you're trying to solve. > >> I agree and this has not to be done, there is no need. It is not problem >> if a user can submit a fake DSN, if there are easy ways to find out the >> trick and invalidate the fake DSN, is it? > > There aren't any in the scenario I proposed. if the recipient site is compromised, no, there aren't. But it is a localized problem at the recipient site. It's a different problem. > In this scenario the service you actually want is nonrepudiation of > submission > and nonrepudiation of transfer. yes, see a more detailed description above. > (The reality on the ground is that so few > large > email services support the DSN extension that getting confirmation, let alone > nonrepudiation, of delivery through the use of success DSNs is not really > practical. But nonrepudiation of transfer is good enough in this case.) Large email service providers have other serious issues, too :-) Free service usually means poor service, and I'm not considering them part of this scenario. Users needing a more serious service either are lucky to belong to some communities (the R&E one for example) or must be willing to pay for a better service, of course. > And the way you get this is through a third party service, which in effect > signs the combination of your message, the time it was sent, and the log > showing its successful transfer to the destination system. > This is precisely the service that RPost, and probably a bunch of others, > provide. For a fee, of course, but if you really need this sort of assurance > you should be prepared to pay for it. I know them and how they work. I'm exploring if there is a different mechanism to obtain the same assurances, without a third party, and using existing protocols... and, if not, if there can be additional protocols to do this in an open environment. > Sure, it would be nice to be able to get this capability without having to > pay > for it. But the reality is that nobody with any sense is going to accept the > potential liability of, say, warranting that the DKIM signatures on success > DSNs actually provide nonrepudiation of delivery. even in the case when you are the owner and administrator of the receiging system issuing these DKIM signed success DSNs ? and you have full control on your logs and maiboxes? Isn't is the same situation of the third party services, running the central MTA? thanks for you time, Ned ;-) > > Ned > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nobody Thu Jan 15 02:40:54 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8BC1B2BD7 for ; Thu, 15 Jan 2015 02:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9u_sxnDCy6B2 for ; Thu, 15 Jan 2015 02:40:51 -0800 (PST) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1E91B2BD5 for ; Thu, 15 Jan 2015 02:40:51 -0800 (PST) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YBhr7-0006Ld-he; Thu, 15 Jan 2015 10:40:49 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YBhr7-0001dX-KN; Thu, 15 Jan 2015 10:40:49 +0000 Message-ID: <54B79930.3070009@ninebynine.org> Date: Thu, 15 Jan 2015 10:40:48 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> In-Reply-To: <54B2CC75.5080900@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Subject: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 10:40:53 -0000 I've been thinking about our discussion, and why we appear to talk past each other. I think it lies in part with this: On 11/01/2015 19:18, Sam Ruby wrote: > I'd like the following Perl expression: > > URI->new_abs(input, base)->scheme . ":" > > ... to produce the same value as the following JavaScript expression: > > new URL(input, base).protocol > > ... for all sets of input and bases. > > Whether that means getting Perl to change, one or more web browsers to change, > or one or more specs to change (and quite possibly, a combination of the above), > is yet to be determined. My view: 1. IN SCOPE: The normative scope of RFC3986 is (a) to define what is a valid URI and URI reference, and (b) to describe the result of combining a valid URI (i.e. a base URI) with a URI reference to obtain a valid URI corresponding to that combination. Everything else (to a first approximation) is explanatory or descriptive. 2. OUT OF SCOPE: it is not the place of RFC3986 to define API behaviour. I think your desire to have a unified API behaviour to access URI components is fine, just not in the scope of RFC3986. Your test data show that different implementations do different things with URI strings, and this may be problematic in some contexts. But I don't think that, of themselves, they show that the problem is with RFC 3986. I use URI parsers in my current work that I know are not entirely conformant with RFC3986, in the sense that they may accept URIs that are not strictly valid according the syntax defined. I believe these divergences show up in your test data. But this has not caused any interoperability problems for me, as long as valid URIs are accepted. For me, it is not an issue that PERL and Javascript APIs may behave slightly differently, but I accept that it may be a concern for others. 3. SUGGESTION: Rather than proposing to update/replace RFC3986 directly, extending the scope to include API behaviour, construct a new specification that builds upon (rather than replacing) RFC 3986 normative content to describe a consistent API behaviour. If doing this exposes any specific problems in the RFC3986 normative content, propose specific updates. #g -- (FWIW, I wrote an early RFC 3986 implementation that was absorbed into the Haskell libraries - http://hackage.haskell.org/package/network-2.1.0.0/docs/Network-URI.html - the API is not without its objectors, but I believe it conforms to the essentials of RFC3986 articulated above. I'm not sure if this is included in your test data.) From nobody Thu Jan 15 04:12:56 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78FD1B2BE3 for ; Thu, 15 Jan 2015 04:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-YXITntMqZx for ; Thu, 15 Jan 2015 04:12:52 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.232]) by ietfa.amsl.com (Postfix) with ESMTP id 98BE71B2B5A for ; Thu, 15 Jan 2015 04:12:52 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:16239] helo=rubix) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id B0/0D-11165-3CEA7B45; Thu, 15 Jan 2015 12:12:52 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 265E5141155; Thu, 15 Jan 2015 07:12:51 -0500 (EST) Message-ID: <54B7AEC2.9010109@intertwingly.net> Date: Thu, 15 Jan 2015 07:12:50 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Graham Klyne , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> In-Reply-To: <54B79930.3070009@ninebynine.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 12:12:54 -0000 On 01/15/2015 05:40 AM, Graham Klyne wrote: > I've been thinking about our discussion, and why we appear to talk past > each other. I think it lies in part with this: > > On 11/01/2015 19:18, Sam Ruby wrote: >> I'd like the following Perl expression: >> >> URI->new_abs(input, base)->scheme . ":" >> >> ... to produce the same value as the following JavaScript expression: >> >> new URL(input, base).protocol >> >> ... for all sets of input and bases. >> >> Whether that means getting Perl to change, one or more web browsers to >> change, >> or one or more specs to change (and quite possibly, a combination of >> the above), >> is yet to be determined. > > > My view: > > 1. IN SCOPE: The normative scope of RFC3986 is (a) to define what is a > valid URI and URI reference, and (b) to describe the result of combining > a valid URI (i.e. a base URI) with a URI reference to obtain a valid URI > corresponding to that combination. Everything else (to a first > approximation) is explanatory or descriptive. > > > 2. OUT OF SCOPE: it is not the place of RFC3986 to define API behaviour. > > I think your desire to have a unified API behaviour to access URI > components is fine, just not in the scope of RFC3986. > > Your test data show that different implementations do different things > with URI strings, and this may be problematic in some contexts. But I > don't think that, of themselves, they show that the problem is with RFC > 3986. > > I use URI parsers in my current work that I know are not entirely > conformant with RFC3986, in the sense that they may accept URIs that are > not strictly valid according the syntax defined. I believe these > divergences show up in your test data. But this has not caused any > interoperability problems for me, as long as valid URIs are accepted. > For me, it is not an issue that PERL and Javascript APIs may behave > slightly differently, but I accept that it may be a concern for others. I see divergences in results even when inputs are valid according to RFC 3986 (note the use of the filter in the below): https://url.spec.whatwg.org/interop/test-results/?filter=valid > 3. SUGGESTION: > > Rather than proposing to update/replace RFC3986 directly, extending the > scope to include API behaviour, construct a new specification that > builds upon (rather than replacing) RFC 3986 normative content to > describe a consistent API behaviour. If doing this exposes any specific > problems in the RFC3986 normative content, propose specific updates. I proposed that the set of characters allowed in a fragment be changed to match the following: https://specs.webplatform.org/url/webspecs/develop/#url-code-points When I did so, people freaked out, piled on, and generally made points unrelated to what was actually proposed. My takeaway: this mailing list is not a receptive place for people who identify specific problems and proposing specific updates. Forgive me if I'm not exactly eager to do that again. So, I will continue to construct a new specification that describes a consistent API behavior. But until and unless there can be a constructive discussion about how to construct a specification in such a way that it builds upon RFC 3986, it simply won't be built upon RFC 3986. Instead, it will likely have an appendix that describes the differences between what it describes are what RFC 3986 describes are. That being said, I remain open to the idea of building upon RFC 3986. This can happen one of two ways: 1) People proposing specific updates to the specification I am working on to make this happen. 2) People being receptive and actively soliciting ways in which RFC 3986 could be changed in order to make this layering possible. Meanwhile, these meta discussions aren't going to get us there, nor am I predisposed to try again with proposing specific updates to RFC 3986. Perhaps a better place to start is with Haskell. See below. > #g > -- > > (FWIW, I wrote an early RFC 3986 implementation that was absorbed into > the Haskell libraries - > http://hackage.haskell.org/package/network-2.1.0.0/docs/Network-URI.html > - the API is not without its objectors, but I believe it conforms to the > essentials of RFC3986 articulated above. I'm not sure if this is > included in your test data.) It is not, but could be. Haskell isn't one of the languages that I happen to know at the moment. I'm confident that I could quickly learn enough Haskell to write the program I need to, but I think it would be a good learning experience for somebody to take the first step. What I am looking for is a program that reads the following test data from a file on disk: https://url.spec.whatwg.org/interop/urltestdata.json This program only needs to look at the "input" and "base" values. It needs to parse the base, resolve the input against that base, and then extract the data that would be produced if the following API were implemented: https://specs.webplatform.org/url/webspecs/develop/#api I realize that the latter is a lot to absorb, and perhaps a better way to understand what the output should look like would be to look at results from other implementations: https://github.com/webspecs/url/tree/develop/evaluate/useragent-results Doing this may mean that you need to implement some parts of the API in your program instead of it being baked into the underlying implementation. That's OK. Examples might include appending a ':' to a scheme to produce a protocol, or splitting an authority into a username and password. I believe that if you would be willing to take a first stab at such a program, we can explore whatever differences that exposes, and whether or not the proposed API should change, and as a consequence, what the implications for RFC 3986 would be. - Sam Ruby From nobody Thu Jan 15 04:35:33 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93521B2BED for ; Thu, 15 Jan 2015 04:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYkoRF5DBlo8 for ; Thu, 15 Jan 2015 04:35:30 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87901B2BEC for ; Thu, 15 Jan 2015 04:35:29 -0800 (PST) Received: by mail-oi0-f42.google.com with SMTP id g201so12088166oib.1 for ; Thu, 15 Jan 2015 04:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5JYGNCcF3q5i8EhJW9BHJtYW4mpoNcYLqhQw/gtUH9o=; b=iLlFfznbSvc5lcXINrCxpSvxJd9e0tsX8AE1ETvnnMRsWatpHaZFFs49RM9JdHDQhp Nm3PjeHeELoCQ4bNiKKQIhTn1C31IXYJsupNCoi1YlHj2aPUU11ZYaIbb/zdto9ZYgke P4EzE3dKUiuE34a1HPWlQ+e/QBux8vpmMPEtc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5JYGNCcF3q5i8EhJW9BHJtYW4mpoNcYLqhQw/gtUH9o=; b=VHJjjxQqcGuJyCQeRap6K/eb8VGkmMuxZ6MNbfrZfFMhzmPqhxhy4fZj0LQKS7WNgc XdeC/AGu5fVzp9V/NWzkWR+cQWdeelm4/DVscGS4XybqVrZ/9AUdDkDi7sASAaPScv69 QKgdvXblgF81/+0qSLB6D7i8n2HgFy2dzzA4IaBOMiJnrh3amXfN0LDlwNuUk8hsXv1n PqicW+YlZgM0/ZTzsTzuJhe5selP0x4rBBKNep1wj8aEtViZdHDVFC/MrWAA0EhtPUtB c7oUkDrprzs1NBpmLYcvFXQsZIGyItC4RUQEna6Lu+lFqjrDTA5q3tmUhp8Z9lvdGsVx jmXg== X-Gm-Message-State: ALoCoQm75N9XYrBdZd+cnUxqdw57PO4vkuCJhhdxGGhK4Wq+h/eN6xQRE/mHcoHAwE3vLeMXuPl7 MIME-Version: 1.0 X-Received: by 10.182.200.135 with SMTP id js7mr5689292obc.71.1421325329177; Thu, 15 Jan 2015 04:35:29 -0800 (PST) Received: by 10.60.84.171 with HTTP; Thu, 15 Jan 2015 04:35:29 -0800 (PST) In-Reply-To: <54B7AEC2.9010109@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> Date: Thu, 15 Jan 2015 12:35:29 +0000 Message-ID: From: Dave Cridland To: Sam Ruby Content-Type: multipart/alternative; boundary=001a11c2c3a65b3794050cb017a2 Archived-At: Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 12:35:32 -0000 --001a11c2c3a65b3794050cb017a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15 January 2015 at 12:12, Sam Ruby wrote: > I proposed that the set of characters allowed in a fragment be changed to > match the following: > > https://specs.webplatform.org/url/webspecs/develop/#url-code-points > > When I did so, people freaked out, piled on, and generally made points > unrelated to what was actually proposed. My takeaway: this mailing list = is > not a receptive place for people who identify specific problems and > proposing specific updates. Forgive me if I'm not exactly eager to do th= at > again. > Well, people told you that changing the code-points allowed in a URI, whether in the fragment portion or any other part, was impractical. In particular, people repeatedly stated that the fragment was not a special thing in most cases. So when you say that this mailing lists isn't receptive to specific updates, I think that's an amusing kind of generalization, given you were provided with a number of very specific cases where your proposal wouldn't fly, including within HTTP and X.509 (both well-used on the web, I believe), and you've not answered any of them. I don't think anyone freaked out - in fact, I'm pretty sure nobody has freaked out since some time in the '60's - I think people voiced their objections. Also, I saw it suggested at least once that one solution to your goal - I don't see it as a problem so much as a desirable enhancement - would be to declare the slots for URIs in HTML, and the browser address bar, to be IRI slots. You'd probably still have to down-convert to URIs for HTTP etc, but still. Now I don't make any claim of knowing much about IRIs, but based on Martin D=C3=BCrst's comment, that seems to fit your goals even better than I'd exp= ected. Therefore, two questions: 1) Do you disagree that X.509 and/or HTTP's use of URIs (including those with a fragment identifier) preclude changing URIs to include non-ASCII? If so, on what basis? 2) Why are IRIs (and moving the web, in general, towards IRIs where practical) not a solution here? Dave. --001a11c2c3a65b3794050cb017a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 15 January 2015 at 12:12, Sam Ruby <rubys@intertwingly.net= > wrote:
=
I proposed that the s= et of characters allowed in a fragment be changed to match the following:

https://specs.webplatform.org/url/webspecs/de= velop/#url-code-points

When I did so, people freaked out, piled on, and generally made points unre= lated to what was actually proposed.=C2=A0 My takeaway: this mailing list i= s not a receptive place for people who identify specific problems and propo= sing specific updates.=C2=A0 Forgive me if I'm not exactly eager to do = that again.

Well, people told you that = changing the code-points allowed in a URI, whether in the fragment portion = or any other part, was impractical. In particular, people repeatedly stated= that the fragment was not a special thing in most cases. So when you say t= hat this mailing lists isn't receptive to specific updates, I think tha= t's an amusing kind of generalization, given you were provided with a n= umber of very specific cases where your proposal wouldn't fly, includin= g within HTTP and X.509 (both well-used on the web, I believe), and you'= ;ve not answered any of them. I don't think anyone freaked out - in fac= t, I'm pretty sure nobody has freaked out since some time in the '6= 0's - I think people voiced their objections.

= Also, I saw it suggested at least once that one solution to your goal - I d= on't see it as a problem so much as a desirable enhancement - would be = to declare the slots for URIs in HTML, and the browser address bar, to be I= RI slots. You'd probably still have to down-convert to URIs for HTTP et= c, but still.

Now I don't make any claim of kn= owing much about IRIs, but based on Martin D=C3=BCrst's comment, that s= eems to fit your goals even better than I'd expected.

Therefore, two questions:

1) Do you disagr= ee that X.509 and/or HTTP's use of URIs (including those with a fragmen= t identifier) preclude changing URIs to include non-ASCII? If so, on what b= asis?

2) Why are IRIs (and moving the web, in gene= ral, towards IRIs where practical) not a solution here?

Dave.
--001a11c2c3a65b3794050cb017a2-- From nobody Thu Jan 15 05:15:00 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA491B2BEE for ; Thu, 15 Jan 2015 05:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aZpgbAD7rUu for ; Thu, 15 Jan 2015 05:14:52 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.225]) by ietfa.amsl.com (Postfix) with ESMTP id AC1E51B2BED for ; Thu, 15 Jan 2015 05:14:52 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:25898] helo=rubix) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id C8/01-11165-B4DB7B45; Thu, 15 Jan 2015 13:14:52 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 6B775140AC1; Thu, 15 Jan 2015 08:14:51 -0500 (EST) Message-ID: <54B7BD4A.1090803@intertwingly.net> Date: Thu, 15 Jan 2015 08:14:50 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Dave Cridland References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 13:14:58 -0000 On 01/15/2015 07:35 AM, Dave Cridland wrote: > > On 15 January 2015 at 12:12, Sam Ruby > wrote: > > I proposed that the set of characters allowed in a fragment be > changed to match the following: > > https://specs.webplatform.org/__url/webspecs/develop/#url-__code-points > > > When I did so, people freaked out, piled on, and generally made > points unrelated to what was actually proposed. My takeaway: this > mailing list is not a receptive place for people who identify > specific problems and proposing specific updates. Forgive me if I'm > not exactly eager to do that again. > > > Well, people told you that changing the code-points allowed in a URI, > whether in the fragment portion or any other part, was impractical. In > particular, people repeatedly stated that the fragment was not a special > thing in most cases. So when you say that this mailing lists isn't > receptive to specific updates, I think that's an amusing kind of > generalization, given you were provided with a number of very specific > cases where your proposal wouldn't fly, including within HTTP and X.509 > (both well-used on the web, I believe), and you've not answered any of > them. I don't think anyone freaked out - in fact, I'm pretty sure nobody > has freaked out since some time in the '60's - I think people voiced > their objections. > > Also, I saw it suggested at least once that one solution to your goal - > I don't see it as a problem so much as a desirable enhancement - would > be to declare the slots for URIs in HTML, and the browser address bar, > to be IRI slots. You'd probably still have to down-convert to URIs for > HTTP etc, but still. > > Now I don't make any claim of knowing much about IRIs, but based on > Martin Dürst's comment, that seems to fit your goals even better than > I'd expected. Let's just agree that neither of us know much about IRIs. > Therefore, two questions: > > 1) Do you disagree that X.509 and/or HTTP's use of URIs (including those > with a fragment identifier) preclude changing URIs to include non-ASCII? > If so, on what basis? I don't know enough about X.509. Meanwhile, I do know that there are a number of implementations that claim to be RFC 3986 compliant that do not percent encode non-ASCII characters contained in fragments. I do not consider it to be a desirable outcome for both those implementations to continue to claim to be RFC 3986 compliant and for X.509 to make a similar claim. I will work with those implementations to come up with a definition that they are compliant with. I welcome people who know about topics such as X.509 to participate in those discussions. As to HTTP, in brief discussions with Mark Nottingham, it seemed likely that there are a number of places within HTTP (in particular, places where fragments may be included) that "dirty URIs" are common. > 2) Why are IRIs (and moving the web, in general, towards IRIs where > practical) not a solution here? All I can say is that I personally am not actively exploring that at this time. I welcome people who know about this topic to participate in this discussion. Given the pervasive lack of awareness of IRI's, I don't believe there would be much interest in an appendix describing the differences between W3C URLs and IETF IRIs. I do continue to believe that there would be interest in such an appending describing the differences between W3C URLs and IETF URIs. > Dave. - Sam Ruby P.S. For whatever reason, the IETF definition of URL hasn't stuck. The common definition for URL doesn't include "Justin Bieber" or whatever people are search for today, but does include bookmarklets: http://en.wikipedia.org/wiki/Bookmarklet To the extent that they do know of the term URI, they treat it as a synonym for URL. I find it more helpful to distinguish "dirty URLs" (i.e., inputs to parsing functions) and "clean URLs" (i.e., the output of parsing and stringifying). It would be ideal if all clean URLs were valid URIs, but at the moment, that's not the case. As a concrete, current, and actionable topic, apparently it is desirable and common practice to include square brackets in the search/query component of "clean URLs": https://bugzilla.mozilla.org/show_bug.cgi?id=1121826 From nobody Thu Jan 15 06:31:20 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCDD1B2BF7 for ; Thu, 15 Jan 2015 06:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXwDn8nCakhG for ; Thu, 15 Jan 2015 06:31:16 -0800 (PST) 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 79CEF1B2BEC for ; Thu, 15 Jan 2015 06:31:16 -0800 (PST) Received: from [192.168.1.194] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MBFUT-1Y1cQk1x9J-00AGGk; Thu, 15 Jan 2015 15:31:11 +0100 Message-ID: <54B7CF28.7060408@gmx.de> Date: Thu, 15 Jan 2015 15:31:04 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Sam Ruby , Dave Cridland References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> In-Reply-To: <54B7BD4A.1090803@intertwingly.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:7ZMAcmEhqituPYKSV6hI22Jihp11UFlVRn0/03s/j5JbSxmbIX6 m/OkJ/zJBilgQIFMiBad5gYj+gPTvsjcjHhodypSo8UWZShT3vxqOWjOaKwq2oVWWoLEfd2 ESDZTQpO9dAvrqwsucDckYlq+y7td9tDkvq+mVmVLSZ07o8VBACXrIhUZiiUcrjAtQ7r6Dx i/oGP4/3dJSHFNF451rPw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 14:31:18 -0000 On 2015-01-15 14:14, Sam Ruby wrote: > ... >> Therefore, two questions: >> >> 1) Do you disagree that X.509 and/or HTTP's use of URIs (including those >> with a fragment identifier) preclude changing URIs to include non-ASCII? >> If so, on what basis? > > I don't know enough about X.509. > > Meanwhile, I do know that there are a number of implementations that > claim to be RFC 3986 compliant that do not percent encode non-ASCII > characters contained in fragments. > ... That is a case of "garbage in, garbage out", no? (where "garbage" means "not a valid URI"). Or do you have a case where a library accepted a RFC3986-valid fragment identifier containing percent-escapes and *removed* that escaping? > ... >> 2) Why are IRIs (and moving the web, in general, towards IRIs where >> practical) not a solution here? > > All I can say is that I personally am not actively exploring that at > this time. I welcome people who know about this topic to participate in > this discussion. > ... If the goal is to widen the set of characters allowed in identifiers, than the right thing to revise/use/build upon might be indeed RFC 3987. > Given the pervasive lack of awareness of IRI's, I don't believe there > would be much interest in an appendix describing the differences between > W3C URLs and IETF IRIs. I do continue to believe that there would be > interest in such an appending describing the differences between W3C > URLs and IETF URIs. Ignoring IDNA etc for a second, you can see IRIs as a superset of URIs where the allowable character repertoire has been extended to allow most of Unicode. >> Dave. > > - Sam Ruby > > P.S. For whatever reason, the IETF definition of URL hasn't stuck. The > common definition for URL doesn't include "Justin Bieber" or whatever Whose definition of "URL" *does* include "Justin Bieber"? > people are search for today, but does include bookmarklets: > > http://en.wikipedia.org/wiki/Bookmarklet It's syntactically a URI (Björn attempted to write down a scheme definition once), so I'm not surprised people call it a URL. > To the extent that they do know of the term URI, they treat it as a > synonym for URL. I find it more helpful to distinguish "dirty URLs" > (i.e., inputs to parsing functions) and "clean URLs" (i.e., the output > of parsing and stringifying). It would be ideal if all clean URLs were > valid URIs, but at the moment, that's not the case. > > As a concrete, current, and actionable topic, apparently it is desirable > and common practice to include square brackets in the search/query > component of "clean URLs": > > https://bugzilla.mozilla.org/show_bug.cgi?id=1121826 > ... I disagree. A recipient that trips over percent-encoding is broken. Best regards, Julian From nobody Thu Jan 15 06:45:59 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6C51B2C03 for ; Thu, 15 Jan 2015 06:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGShGLgsaz_N for ; Thu, 15 Jan 2015 06:45:54 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16551B2C02 for ; Thu, 15 Jan 2015 06:45:53 -0800 (PST) Received: by mail-oi0-f45.google.com with SMTP id x69so12639060oia.4 for ; Thu, 15 Jan 2015 06:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XLW8E+IbCyf8MPmjaYc6KMXvq5rYTMQkYTPivlHwd34=; b=KHPsmTChRWNmzryovOujD2Gr47DOC2N5CrMTmOTDRd18IX3e5MzFK1WzCe44beapC3 iHbiiqbtpIMSt8XvF+BW9PhRO41nh+1ToSrnrbgTfws78nJc1MKerRKGxfaq5t8sHw5C 6NBiKFIKZkBWj0EfSdnul01GKbg6jJbgQuXaI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XLW8E+IbCyf8MPmjaYc6KMXvq5rYTMQkYTPivlHwd34=; b=N7idlk4u7RPVOUJAgh1DZDtX8DsJHnMYKXnB1kiOZ53E8G0DsBUtD7ZO9cp99ZW1Xm lYLT/PF8xn5egEDP6T7/cN1zpxH/ZwkRxRWbksVMekdsmipz1Nx/O29E6SlIhYz7ickL mxveQ6iFi4kiH6Kyt5WnDqrwVmmhn97wJc79KV5ejRl0xryXiBIant6YJFb/tEUXUfJA bz7w3Jd4yZkRemKCNVehtuaq0ORcmc14SCuc/cvH/Su8SVShIRUveRCG/cbiMV9e8j7r 1EMzcIkD4aP/YTjCWr9Byl1xuLcMgX76fwLZxDjgyz69J0LJ+C9QETmV0RIl/k9IqUgD Zp8w== X-Gm-Message-State: ALoCoQmf/iH5mC0Zvbxs/Xw98eP1utPkkZZBSC3p3w16HF2/AWlwTa2DMdj2s99Wdv+3Eqh2FmKK MIME-Version: 1.0 X-Received: by 10.182.200.135 with SMTP id js7mr6076198obc.71.1421333153019; Thu, 15 Jan 2015 06:45:53 -0800 (PST) Received: by 10.60.84.171 with HTTP; Thu, 15 Jan 2015 06:45:52 -0800 (PST) In-Reply-To: <54B7BD4A.1090803@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> Date: Thu, 15 Jan 2015 14:45:52 +0000 Message-ID: From: Dave Cridland To: Sam Ruby Content-Type: multipart/alternative; boundary=001a11c2c3a6b1b1ad050cb1e9e2 Archived-At: Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 14:45:55 -0000 --001a11c2c3a6b1b1ad050cb1e9e2 Content-Type: text/plain; charset=UTF-8 On 15 January 2015 at 13:14, Sam Ruby wrote: > > Let's just agree that neither of us know much about IRIs. > > I'd stress I'm not the one writing a new URI spec. Maybe you should be looking into them, before claiming expertise in this domain. You're coming across as willfully ignorant if you don't. I've now read the specification, at least, and while I make no claim of expertise I'm reasonably confident that this handles everything you could possibly want WRT what one might call "internationalized URLs"; well beyond merely unencoded UTF-8 fragments. Moreover, it seems that XML, and therefore XHTML, natively support IRIs in their anyURI slots, which surprised me - slightly embarrassing given I use XML quite a bit. I have no idea if HTML5 allows IRIs natively; even after reading the spec it's woefully unclear to me, though it does include a reference, and the existence of XHTML5 suggests to me that it most likely does. I would note it's giving you a well-defined process for taking a "URL" class instance and calling a "toASCII()" on it to get an ASCII URI, to express it in API terms. Moreover, I believe that a "W3C URL", as you worryingly put it, is in fact an IRI by definition already. So really, it took me a couple of hours of reading the specs to decide that existing "URL" parsers are probably designed to handle IRIs, really. In which case, I think there's a blindingly obvious path forward for you. Also, congratulations for apparently demanding "internationalized URLs" for use in HTML5 when apparently it already does these via the IRI spec. You know, the one you've ignored our suggestions to look at. > As a concrete, current, and actionable topic, apparently it is desirable > and common practice to include square brackets in the search/query > component of "clean URLs": > > https://bugzilla.mozilla.org/show_bug.cgi?id=1121826 > Speaking personally, I have no objection to this change at all. The problems with adding non-ASCII codepoints to URIs isn't that some parser buried in X.509 isn't expecting them, it's that the containing syntax cannot hold those legally - no URI parser gets a chance to look at these. Which ASCII codepoints are allowed in which parts shouldn't upset anything. Dave. --001a11c2c3a6b1b1ad050cb1e9e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 5 January 2015 at 13:14, Sam Ruby <rubys@intertwingly.net> wrote:
Let's just agree that neither of us know much about IRIs.


I'd stress I'm not the = one writing a new URI spec. Maybe you should be looking into them, before c= laiming expertise in this domain. You're coming across as willfully ign= orant if you don't.

I've now read the spec= ification, at least, and while I make no claim of expertise I'm reasona= bly confident that this handles everything you could possibly want WRT what= one might call "internationalized URLs"; well beyond merely unen= coded UTF-8 fragments.

Moreover, it seems that XML= , and therefore XHTML, natively support IRIs in their anyURI slots, which s= urprised me - slightly embarrassing given I use XML quite a bit. I have no = idea if HTML5 allows IRIs natively; even after reading the spec it's wo= efully unclear to me, though it does include a reference, and the existence= of XHTML5 suggests to me that it most likely does.

I would note it's giving you a well-defined process for taking a &quo= t;URL" class instance and calling a "toASCII()" on it to get= an ASCII URI, to express it in API terms. Moreover, I believe that a "= ;W3C URL", as you worryingly put it, is in fact an IRI by definition a= lready.

So really, it took me a couple of hours of= reading the specs to decide that existing "URL" parsers are prob= ably designed to handle IRIs, really. In which case, I think there's a = blindingly obvious path forward for you.

Also, con= gratulations for apparently demanding "internationalized URLs" fo= r use in HTML5 when apparently it already does these via the IRI spec.

You know, the one you've ignored our suggestions t= o look at.
=C2=A0
As a concrete, current, and actionable topic, apparently it is desirable an= d common practice to include square brackets in the search/query component = of "clean URLs":

https://bugzilla.mozilla.org/show_bug.cgi?id=3D1121826

Speaking personally= , I have no objection to this change at all. The problems with adding non-A= SCII codepoints to URIs isn't that some parser buried in X.509 isn'= t expecting them, it's that the containing syntax cannot hold those leg= ally - no URI parser gets a chance to look at these. Which ASCII codepoints= are allowed in which parts shouldn't upset anything.

Dave.
--001a11c2c3a6b1b1ad050cb1e9e2-- From nobody Thu Jan 15 06:53:26 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546D91B2BFB for ; Thu, 15 Jan 2015 06:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OF8Pdj2GVgbT for ; Thu, 15 Jan 2015 06:53:21 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 70F901B2BF2 for ; Thu, 15 Jan 2015 06:53:20 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id t0FErHLt005412; Thu, 15 Jan 2015 14:53:17 GMT 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 t0FErGBs003278; Thu, 15 Jan 2015 14:53:16 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t0FErG0k019946; Thu, 15 Jan 2015 14:53:16 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id t0FErF71019942; Thu, 15 Jan 2015 14:53:15 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Sam Ruby References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 15 Jan 2015 14:53:15 +0000 In-Reply-To: <54B7BD4A.1090803@intertwingly.net> (Sam Ruby's message of "Thu\, 15 Jan 2015 08\:14\:50 -0500") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 14:53:25 -0000 Sam Ruby writes: > As a concrete, current, and actionable topic, apparently it is > desirable and common practice to include square brackets in the > search/query component of "clean URLs": > > https://bugzilla.mozilla.org/show_bug.cgi?id=3D1121826 So I want to take this (small) part of your message to try to understand your implicit requirements process. The bug report referenced there has a few key factual nuggets: 1) 3986 [1] does not include '[' and ']' among the URL code points; 2) The WHATWG URL document is tricky on this point as it stands today (2015-01-15): ']' and '[' are not allowed in queries, it is a parse error if they do, but the implicit error recovery step taken when they _do_ appear is to include them in the parsed URL without escaping them. 3) IE8 and Chrome? do not %-encode '[' or ']' in the query string, whereas Firefox35 does %-encode; On this basis you assert "apparently it is desirable and common practice to include square brackets in ... 'clean URLS'". My concern here is _not_ with the specifics of how square brackets are _or_ should be handled, in browsers or in specs, but rather with how we should make decisions about such questions. What can we conclude based on the facts listed above in this regard? Insofar as the two documents involved overlap, they agree -- a string with '[' and/or ']' in what would otherwise be the query part of a URI/URL is not in fact a URI/URL -- it fails to conform to the respective definitions thereof. The WHATWG document goes further, into a space which is evidently out-of-scope for 3986, and defines an error recovery procedure for such strings. That procedure, it should be noted, _does_ percent-encode some other non-allowed characters when they appear in the query part, including e.g. '<' and '>'. Standardising error recovery is clearly a reasonable goal, once the decision not to take a draconian approach is made. But in the (manifest) absence of agreement between existing implementations as to what that error recovery should be, how should a choice be made? We now return to your statement, quoted above, as it appears to contain an answer to that question -- might makes right. That is, because Chrome and IE don't %-encode as part of error recovery, and between them they have more market share than Firefox, Firefox loses, and must stop doing it. Obviously that's a caricature of an argument, not an actual argument. I'm confident you _have_ an actual argument in mind, but I can't figure out what it might be. Please enlighten me. Note that "because the WHATWG spec says so" is not sufficient, because there must be a reason _why_ it says so. ht [1] https://tools.ietf.org/html/rfc3986 [2] https://url.spec.whatwg.org/ **Appendix** The relevant bits of the WHATWG URL document are as follows: "A query must be zero or more *URL units*." [3] "The *URL units* are *URL code points* and percent-encoded bytes." [3] "The URL code points are ASCII alphanumeric, "!", ... [a list not including '[' or ']']" [3] "[if c is '[' or ']'], run these steps: 1. If c is not a URL code point and not "%", *parse error*. 2. ... 3. Append c to buffer. [after processing all the characters into the buffer] ... 3. For each byte in buffer run these subsubsteps: 1. If byte is less than 0x21, greater than 0x7E, or is one of 0x22, 0x23, 0x3C, 0x3E, and 0x60, append byte, percent encoded, to url=A2s query. 2. Otherwise, append a code point whose value is byte to url=A2s query." [4] The 'must' in the first quote above is a 2119 'must'. [3] https://url.spec.whatwg.org/#url-writing [4] https://url.spec.whatwg.org/#query-state --=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 s= pam] From nobody Thu Jan 15 07:00:26 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4661B2B24 for ; Thu, 15 Jan 2015 07:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAyJUfyndTFQ for ; Thu, 15 Jan 2015 07:00:23 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.230]) by ietfa.amsl.com (Postfix) with ESMTP id D43851B2BC5 for ; Thu, 15 Jan 2015 07:00:22 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:40473] helo=rubix) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 36/F4-18452-606D7B45; Thu, 15 Jan 2015 15:00:22 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id DBD0C140EE5; Thu, 15 Jan 2015 10:00:21 -0500 (EST) Message-ID: <54B7D605.2060307@intertwingly.net> Date: Thu, 15 Jan 2015 10:00:21 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Julian Reschke References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> In-Reply-To: <54B7CF28.7060408@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 15:00:25 -0000 On 01/15/2015 09:31 AM, Julian Reschke wrote: > On 2015-01-15 14:14, Sam Ruby wrote: >> ... >> >> Meanwhile, I do know that there are a number of implementations that >> claim to be RFC 3986 compliant that do not percent encode non-ASCII >> characters contained in fragments. >> ... > > That is a case of "garbage in, garbage out", no? (where "garbage" means > "not a valid URI"). > > Or do you have a case where a library accepted a RFC3986-valid fragment > identifier containing percent-escapes and *removed* that escaping? Just so that we are understanding one another: this is a case where some software (in particular a browser) attempted to produce valid URIs per RFC 3986 and things broke as a result. From this perspective, percent encoding square brackets in query strings is the thing that is broken. And observing that parsers will retain that brokenness isn't helpful. One possible outcome: this will be yet another case where following RFC 3986 is not recommended. I intend to capture a list of such cases, and produce a recommendation of what should be done instead. >> ... >>> 2) Why are IRIs (and moving the web, in general, towards IRIs where >>> practical) not a solution here? >> >> All I can say is that I personally am not actively exploring that at >> this time. I welcome people who know about this topic to participate in >> this discussion. >> ... > > If the goal is to widen the set of characters allowed in identifiers, > than the right thing to revise/use/build upon might be indeed RFC 3987. If an example of a problem I'm facing is that escaping square brackets in query/search strings causes problems, I'm not likely to find the solution to that problem in IRIs. At the current time, it appears that the only option available to me is to define something that is neither a superset nor a subset of RFC 3986, and document why that is the case. In particular, document why attempting to follow RFC 3986 will cause interoperability problems. I've participated on this list in the hopes that we collectively could come up with a better solution than that. >> P.S. For whatever reason, the IETF definition of URL hasn't stuck. The >> common definition for URL doesn't include "Justin Bieber" or whatever > > Whose definition of "URL" *does* include "Justin Bieber"? I've been told on this very mailing list just a few days ago that folks have been confusing this very thing: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13648.html It is replies like that one, and your comment below that is causing me to rapidly lose interest in trying to build on RFC 3986. >> https://bugzilla.mozilla.org/show_bug.cgi?id=1121826 >> ... > > I disagree. A recipient that trips over percent-encoding is broken. You are certainly entitled to have that opinion. And you have a RFC that you can point to. But I will say that entering into a discuss with that mindset is less than helpful. If you can help change their minds, that would be great. If not, I would encourage you to keep an open mind. > Best regards, Julian - Sam Ruby From nobody Thu Jan 15 07:11:18 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58401B2BFD for ; Thu, 15 Jan 2015 07:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVHOGPszc9dF for ; Thu, 15 Jan 2015 07:11:14 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.230]) by ietfa.amsl.com (Postfix) with ESMTP id 173421B2C23 for ; Thu, 15 Jan 2015 07:10:12 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:41308] helo=rubix) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 51/61-18452-358D7B45; Thu, 15 Jan 2015 15:10:11 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 58856140EE5; Thu, 15 Jan 2015 10:10:10 -0500 (EST) Message-ID: <54B7D851.7060201@intertwingly.net> Date: Thu, 15 Jan 2015 10:10:09 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Henry S. Thompson" References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=iso-8859-7; format=flowed Content-Transfer-Encoding: 8bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 15:11:16 -0000 First, a general comment. Why does this list attract people whose first resource is to go to caricature and sarcasm? Second, I don't know what the right answer is. I just know that real people have sincerely attempted to follow RFC 3866 and encountered real problems with doing so. I'd personally like to see RFC 3986 changed to address problems like this one, and for the W3C specification of API behavior to build upon this changed definition. - Sam Ruby On 01/15/2015 09:53 AM, Henry S. Thompson wrote: > Sam Ruby writes: > >> As a concrete, current, and actionable topic, apparently it is >> desirable and common practice to include square brackets in the >> search/query component of "clean URLs": >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1121826 > > So I want to take this (small) part of your message to try to > understand your implicit requirements process. > > The bug report referenced there has a few key factual nuggets: > > 1) 3986 [1] does not include '[' and ']' among the URL code points; > > 2) The WHATWG URL document is tricky on this point as it stands > today (2015-01-15): ']' and '[' are not allowed in queries, it is > a parse error if they do, but the implicit error recovery step > taken when they _do_ appear is to include them in the parsed URL > without escaping them. > > 3) IE8 and Chrome? do not %-encode '[' or ']' in the query string, > whereas Firefox35 does %-encode; > > On this basis you assert "apparently it is desirable and common > practice to include square brackets in ... 'clean URLS'". > > My concern here is _not_ with the specifics of how square brackets are > _or_ should be handled, in browsers or in specs, but rather with how > we should make decisions about such questions. What can we conclude > based on the facts listed above in this regard? Insofar as the two > documents involved overlap, they agree -- a string with '[' and/or ']' > in what would otherwise be the query part of a URI/URL is not in fact > a URI/URL -- it fails to conform to the respective definitions > thereof. > > The WHATWG document goes further, into a space which is evidently > out-of-scope for 3986, and defines an error recovery procedure for > such strings. That procedure, it should be noted, _does_ > percent-encode some other non-allowed characters when they appear in > the query part, including e.g. '<' and '>'. > > Standardising error recovery is clearly a reasonable goal, once the > decision not to take a draconian approach is made. But in the > (manifest) absence of agreement between existing implementations as to > what that error recovery should be, how should a choice be made? > > We now return to your statement, quoted above, as it appears to > contain an answer to that question -- might makes right. That is, > because Chrome and IE don't %-encode as part of error recovery, and > between them they have more market share than Firefox, Firefox loses, > and must stop doing it. Obviously that's a caricature of an argument, > not an actual argument. I'm confident you _have_ an actual argument > in mind, but I can't figure out what it might be. Please enlighten > me. Note that "because the WHATWG spec says so" is not sufficient, > because there must be a reason _why_ it says so. > > ht > > [1] https://tools.ietf.org/html/rfc3986 > [2] https://url.spec.whatwg.org/ > > **Appendix** > > The relevant bits of the WHATWG URL document are as follows: > > "A query must be zero or more *URL units*." [3] > "The *URL units* are *URL code points* and percent-encoded bytes." [3] > "The URL code points are ASCII alphanumeric, "!", ... [a list > not including '[' or ']']" [3] > > "[if c is '[' or ']'], run these steps: > 1. If c is not a URL code point and not "%", *parse error*. > 2. ... > 3. Append c to buffer. > > [after processing all the characters into the buffer] > ... > 3. For each byte in buffer run these subsubsteps: > 1. If byte is less than 0x21, greater than 0x7E, or is > one of 0x22, 0x23, 0x3C, 0x3E, and 0x60, append byte, > percent encoded, to urls query. > > 2. Otherwise, append a code point whose value is byte to > urls query." [4] > > The 'must' in the first quote above is a 2119 'must'. > > [3] https://url.spec.whatwg.org/#url-writing > [4] https://url.spec.whatwg.org/#query-state > From nobody Thu Jan 15 07:11:46 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699361B2C1E for ; Thu, 15 Jan 2015 07:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yL_tjsmtlaN3 for ; Thu, 15 Jan 2015 07:11:31 -0800 (PST) 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 B129C1B2C2A for ; Thu, 15 Jan 2015 07:11:05 -0800 (PST) Received: from [192.168.1.194] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M9b4B-1Y3HdB188d-00D1bU; Thu, 15 Jan 2015 16:11:02 +0100 Message-ID: <54B7D87F.7070402@gmx.de> Date: Thu, 15 Jan 2015 16:10:55 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Sam Ruby References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> In-Reply-To: <54B7D605.2060307@intertwingly.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:psqQBdscC0OZjNyeGuWdXR3QoiEKxS4jgLD4qwxvQt+C7ucpBQa auuPJ0nbtt8ZU4kXjScFJ29/I3lDesmT6ZDfacrKxXHaBqd/mbObloy/o/pMkq6dWYzUNcs Pf9ADitWBnENYz5U68etsXrrVzKJtZwRMuR24QxSMoWLym1I6mUvwUlubI6iMteX8iyYyuj mfnYB7IfvQVHj/32sfEIQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 15:11:37 -0000 On 2015-01-15 16:00, Sam Ruby wrote: > On 01/15/2015 09:31 AM, Julian Reschke wrote: >> On 2015-01-15 14:14, Sam Ruby wrote: >>> ... >>> >>> Meanwhile, I do know that there are a number of implementations that >>> claim to be RFC 3986 compliant that do not percent encode non-ASCII >>> characters contained in fragments. >>> ... >> >> That is a case of "garbage in, garbage out", no? (where "garbage" means >> "not a valid URI"). >> >> Or do you have a case where a library accepted a RFC3986-valid fragment >> identifier containing percent-escapes and *removed* that escaping? > > Just so that we are understanding one another: this is a case where some > software (in particular a browser) attempted to produce valid URIs per > RFC 3986 and things broke as a result. A broken recipient didn't work, right. What needs to be fixed is the recipient, then. > From this perspective, percent encoding square brackets in query > strings is the thing that is broken. And observing that parsers will > retain that brokenness isn't helpful. So, you're actually asking for two things, right? 1) allow raw "[" and "]" in queries (and paths, presumably) 2) stop requiring recipients to remove percent-encoding before comparison 1) is an interesting discussion to have; it maybe true that the URI spec is too defensive, as "[" and "]" are only special in the authority part. What scares me are the implications of 2) though. > One possible outcome: this will be yet another case where following RFC > 3986 is not recommended. I intend to capture a list of such cases, and > produce a recommendation of what should be done instead. Can you clarify what you think about 2)? If you don't make that change as well, that recipient will continue to be broken. >>> ... >>>> 2) Why are IRIs (and moving the web, in general, towards IRIs where >>>> practical) not a solution here? >>> >>> All I can say is that I personally am not actively exploring that at >>> this time. I welcome people who know about this topic to participate in >>> this discussion. >>> ... >> >> If the goal is to widen the set of characters allowed in identifiers, >> than the right thing to revise/use/build upon might be indeed RFC 3987. > > If an example of a problem I'm facing is that escaping square brackets > in query/search strings causes problems, I'm not likely to find the > solution to that problem in IRIs. That is true. > At the current time, it appears that the only option available to me is > to define something that is neither a superset nor a subset of RFC 3986, > and document why that is the case. In particular, document why > attempting to follow RFC 3986 will cause interoperability problems. The interop problems are caused because some recipients rely on broken behavior in some senders. One way to fix this is to fix the recipient. > I've participated on this list in the hopes that we collectively could > come up with a better solution than that. > >>> P.S. For whatever reason, the IETF definition of URL hasn't stuck. The >>> common definition for URL doesn't include "Justin Bieber" or whatever >> >> Whose definition of "URL" *does* include "Justin Bieber"? > > I've been told on this very mailing list just a few days ago that folks > have been confusing this very thing: > > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13648.html > > It is replies like that one, and your comment below that is causing me > to rapidly lose interest in trying to build on RFC 3986. I re-read Sean's mail and still don't get what you're referring to. >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1121826 >>> ... >> >> I disagree. A recipient that trips over percent-encoding is broken. > > You are certainly entitled to have that opinion. And you have a RFC > that you can point to. But I will say that entering into a discuss with > that mindset is less than helpful. > > If you can help change their minds, that would be great. If not, I > would encourage you to keep an open mind. > >> Best regards, Julian > > - Sam Ruby Best regards, Julian From nobody Thu Jan 15 07:28:21 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139241B2C32 for ; Thu, 15 Jan 2015 07:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CcVRUG2dTuh for ; Thu, 15 Jan 2015 07:28:19 -0800 (PST) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947611B2C2D for ; Thu, 15 Jan 2015 07:28:14 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id wo20so4045141obc.5 for ; Thu, 15 Jan 2015 07:28:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xtJqnjc7p0+pz45PO4+yvIgm4XrIzNZEGC+XDSSSB7s=; b=JqWQ1pY3qo4BBd2/HV7BLZ1VglJiaVxZzcpSRx9UzPdEHGRYZWEZpSrBn/8332kOUR Dc5tDTnsExtaCNzoGaRNE4da/CMKtJCdrs7L5Gw+K/kwAed2oJASMPT0LmA7x8Klq/Qt NZgTR4+SkF/HlX8QnaStZu5qgf0A2m/Gw1QcY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xtJqnjc7p0+pz45PO4+yvIgm4XrIzNZEGC+XDSSSB7s=; b=ZXC7NyEyDF50hG62rVHArXuJiDXdGu1imUKFagmXHYBHsHDgT4eWaoWn6AWQ2NxZBd DlGWxy86jlGJ3hCy+b80oG1uqW+EfO7U7EevkzKbC/VqmhkFeUPcn74g2ormINWcXPZl mgWPpCuZ7rPAz55FArPKLgRUf76QvcNY01r5HCWTRpVPbYTolA40dJBdrWIZ8RqjkajV LKrdLFCl5ahQdD82GqED4xXS/UEZWCwoq9MY0q5u3UYne21rjDOJESV7suN6JpTaGOVo rcJxFZy+hvIF8Ccxygj41Dz5QZJcu4dhloXV7As5RgorvW2gEqXw7MMcVtfnYok/D2ca vRXQ== X-Gm-Message-State: ALoCoQlYwyX+Yoj0CyqP8sNd9gY1v1RmkGa1yJMknmKah9oHLH7+OangKBgL3jZeN9EA+0CV3jZ9 MIME-Version: 1.0 X-Received: by 10.202.104.81 with SMTP id d78mr6021957oic.110.1421335693869; Thu, 15 Jan 2015 07:28:13 -0800 (PST) Received: by 10.60.84.171 with HTTP; Thu, 15 Jan 2015 07:28:13 -0800 (PST) In-Reply-To: <54B7D851.7060201@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net> Date: Thu, 15 Jan 2015 15:28:13 +0000 Message-ID: From: Dave Cridland To: Sam Ruby Content-Type: multipart/alternative; boundary=001a1140fb6223d924050cb28163 Archived-At: Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 15:28:20 -0000 --001a1140fb6223d924050cb28163 Content-Type: text/plain; charset=UTF-8 On 15 January 2015 at 15:10, Sam Ruby wrote: > First, a general comment. Why does this list attract people whose first > resource is to go to caricature and sarcasm? > If that's a reference to me, my first recourse was to suggest you read the relevant specifications and keep to the same terminology as the technical literature. My second recourse was to to attempt to clarify your position, since you hadn't responded to the first. I only did sarcasm on the third try - I've not yet done caricature. Please, read the IRI spec, and the HTML5 spec, and then tell me why you think that IRIs are not *already* the solution. I don't mean "could be", at this stage I hold they already are, and that "URL parsers" are in fact IRI parsers, and this is what you want. Dave. --001a1140fb6223d924050cb28163 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 5 January 2015 at 15:10, Sam Ruby <rubys@intertwingly.net> wrote:
First, a general comment.=C2= =A0 Why does this list attract people whose first resource is to go to cari= cature and sarcasm?

If that's a ref= erence to me, my first recourse was to suggest you read the relevant specif= ications and keep to the same terminology as the technical literature. My s= econd recourse was to to attempt to clarify your position, since you hadn&#= 39;t responded to the first.

I only did sarcasm on= the third try - I've not yet done caricature.

Please, read the IRI spec, and the HTML5 spec, and then tell me why you th= ink that IRIs are not *already* the solution.

I do= n't mean "could be", at this stage I hold they already are, a= nd that "URL parsers" are in fact IRI parsers, and this is what y= ou want.

Dave.


=
--001a1140fb6223d924050cb28163-- From nobody Thu Jan 15 07:32:15 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280FD1B2C5B for ; Thu, 15 Jan 2015 07:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_0PiVOULSRs for ; Thu, 15 Jan 2015 07:32:12 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.226]) by ietfa.amsl.com (Postfix) with ESMTP id 65EBF1B2C59 for ; Thu, 15 Jan 2015 07:32:07 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:44544] helo=rubix) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 32/6C-18452-67DD7B45; Thu, 15 Jan 2015 15:32:06 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 9A0DC140CA1; Thu, 15 Jan 2015 10:32:06 -0500 (EST) Message-ID: <54B7DD76.1010707@intertwingly.net> Date: Thu, 15 Jan 2015 10:32:06 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Julian Reschke References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B7D87F.7070402@gmx.de> In-Reply-To: <54B7D87F.7070402@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 15:32:14 -0000 On 01/15/2015 10:10 AM, Julian Reschke wrote: > On 2015-01-15 16:00, Sam Ruby wrote: >> On 01/15/2015 09:31 AM, Julian Reschke wrote: >>> On 2015-01-15 14:14, Sam Ruby wrote: >>>> ... >>>> >>>> Meanwhile, I do know that there are a number of implementations that >>>> claim to be RFC 3986 compliant that do not percent encode non-ASCII >>>> characters contained in fragments. >>>> ... >>> >>> That is a case of "garbage in, garbage out", no? (where "garbage" means >>> "not a valid URI"). >>> >>> Or do you have a case where a library accepted a RFC3986-valid fragment >>> identifier containing percent-escapes and *removed* that escaping? >> >> Just so that we are understanding one another: this is a case where some >> software (in particular a browser) attempted to produce valid URIs per >> RFC 3986 and things broke as a result. > > A broken recipient didn't work, right. What needs to be fixed is the > recipient, then. That indeed is one point of view. Another point of view is that a sender attempted to follow a broken standard, and what needs to be fixed is the standard. I'm not saying which point of view is right, I'm merely pointing out that there are different points of view. In order to make progress, it would be helpful if everyone involved recognized that there are multiple, valid, points of view. >> From this perspective, percent encoding square brackets in query >> strings is the thing that is broken. And observing that parsers will >> retain that brokenness isn't helpful. > > So, you're actually asking for two things, right? > > 1) allow raw "[" and "]" in queries (and paths, presumably) I'd like to have that discussion for queries at least. > 2) stop requiring recipients to remove percent-encoding before comparison I don't believe I've asked to have that discussion. > 1) is an interesting discussion to have; it maybe true that the URI spec > is too defensive, as "[" and "]" are only special in the authority part. > > What scares me are the implications of 2) though. Again, I don't see why 2) is necessary. >> One possible outcome: this will be yet another case where following RFC >> 3986 is not recommended. I intend to capture a list of such cases, and >> produce a recommendation of what should be done instead. > > Can you clarify what you think about 2)? If you don't make that change > as well, that recipient will continue to be broken. You seem to be assuming a lot, and it will take peeling back a number of layers of the onion to get to where we are understanding each other. For starters, RFC 3986 essentially punts on topics like normalization and comparison: https://tools.ietf.org/html/rfc3986#page-38 In particular, it explicitly acknoledges the possibility of simple string comparison: https://tools.ietf.org/html/rfc3986#section-6.2.1 I conclude that RFC 3986, as it is currently written, does NOT require recipients to remove percent-encoding before comparison, and as such, I'm curious as to why you are suggesting that this requirement be removed? >>> Whose definition of "URL" *does* include "Justin Bieber"? >> >> I've been told on this very mailing list just a few days ago that folks >> have been confusing this very thing: >> >> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13648.html >> >> It is replies like that one, and your comment below that is causing me >> to rapidly lose interest in trying to build on RFC 3986. > > I re-read Sean's mail and still don't get what you're referring to. Here's the quote: "Folks are confusing the "web browser text box at the top" with URIs." It continues with an example: 'For example if you type "? ietf"' - Sam Ruby From nobody Thu Jan 15 07:42:40 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AAA1B2C9A for ; Thu, 15 Jan 2015 07:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ID4xRGxLDcv for ; Thu, 15 Jan 2015 07:42:36 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0B01B2C59 for ; Thu, 15 Jan 2015 07:42:36 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id z2so13182955wiv.5 for ; Thu, 15 Jan 2015 07:42:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Mpp5L+8F8qWBt/3f0wUf/Fgmxys8m6KhT09PwIGUR80=; b=BXeYGgxCdtKWU9OZLNarLl2D9GQAZ1UanjLVQvczrfY0+ZUadavsjjbuUZhewkiO1W YXn0l7Nakm3pjsyg8QTEhNZAzZQ8dh5pijBkN+xuFhX+DcT25hXUeSGG8A4xSanR470v E2dDgWd40P5iFq9lSr1TTV1PbxLTcRYjzJ4yOmcMvg/k1OsgTVQ0sLq/j9Hljc5dcvcR lAQ5LARYg+heQVQLMvL0KzvvoTh1195jLfUMrF13lz8aCGYz/Iz/MFuku9eFhEug32Bq mB/ePF514wqyVEy9ZbIuY4tl08nOqmGlqLhav6Ihkwnlkm5LmvbJHUMmuYqsT3hD3zJc qORg== MIME-Version: 1.0 X-Received: by 10.194.142.174 with SMTP id rx14mr7727762wjb.110.1421336555129; Thu, 15 Jan 2015 07:42:35 -0800 (PST) Received: by 10.27.204.198 with HTTP; Thu, 15 Jan 2015 07:42:35 -0800 (PST) In-Reply-To: <54B7D851.7060201@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net> Date: Thu, 15 Jan 2015 07:42:35 -0800 Message-ID: From: "Murray S. Kucherawy" To: Sam Ruby Content-Type: multipart/alternative; boundary=089e01176ee37994da050cb2b49e Archived-At: Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 15:42:38 -0000 --089e01176ee37994da050cb2b49e Content-Type: text/plain; charset=UTF-8 No hat, but my co-chair hat is nearby. On Thu, Jan 15, 2015 at 7:10 AM, Sam Ruby wrote: > First, a general comment. Why does this list attract people whose first > resource is to go to caricature and sarcasm? > Although this list is far from unique in this regard, I do agree that it shouldn't be a tactic in anyone's toolbelt here. > Second, I don't know what the right answer is. I just know that real > people have sincerely attempted to follow RFC 3866 and encountered real > problems with doing so. > > I'd personally like to see RFC 3986 changed to address problems like this > one, and for the W3C specification of API behavior to build upon this > changed definition. > I see a lot of chatter from multiple participants about what oughta happen. Has anyone put pen to paper yet to propose an update or replacement document that we can really look at? -MSK --089e01176ee37994da050cb2b49e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No hat, but my co-chair hat is nearby.

On Thu,= Jan 15, 2015 at 7:10 AM, Sam Ruby <rubys@intertwingly.net> wrote:
First, a general comment.=C2=A0 Why does this list= attract people whose first resource is to go to caricature and sarcasm?

Although this list is far from unique in = this regard, I do agree that it shouldn't be a tactic in anyone's t= oolbelt here.
=C2=A0
Second, I don't know what the right answer is.=C2=A0 I just know that r= eal people have sincerely attempted to follow RFC 3866 and encountered real= problems with doing so.

I'd personally like to see RFC 3986 changed to address problems like th= is one, and for the W3C specification of API behavior to build upon this ch= anged definition.
=

I see a lot of chatter from multipl= e participants about what oughta happen.=C2=A0 Has anyone put pen to paper = yet to propose an update or replacement document that we can really look at= ?

-MSK
--089e01176ee37994da050cb2b49e-- From nobody Thu Jan 15 07:43:21 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600381B2C93 for ; Thu, 15 Jan 2015 07:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aC8OGxJpjV12 for ; Thu, 15 Jan 2015 07:43:11 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.230]) by ietfa.amsl.com (Postfix) with ESMTP id 1DACB1B2CA5 for ; Thu, 15 Jan 2015 07:43:11 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:45738] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 48/F1-28314-E00E7B45; Thu, 15 Jan 2015 15:43:10 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 79A67140CA1; Thu, 15 Jan 2015 10:43:09 -0500 (EST) Message-ID: <54B7E00D.9040509@intertwingly.net> Date: Thu, 15 Jan 2015 10:43:09 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Dave Cridland References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 15:43:17 -0000 On 01/15/2015 10:28 AM, Dave Cridland wrote: > On 15 January 2015 at 15:10, Sam Ruby > wrote: > > First, a general comment. Why does this list attract people whose > first resource is to go to caricature and sarcasm? > > If that's a reference to me, my first recourse was to suggest you read > the relevant specifications and keep to the same terminology as the > technical literature. My second recourse was to to attempt to clarify > your position, since you hadn't responded to the first. > > I only did sarcasm on the third try - I've not yet done caricature. > > Please, read the IRI spec, and the HTML5 spec, and then tell me why you > think that IRIs are not *already* the solution. Excerpt from RFC 3986: query = *( pchar / "/" / "?" ) pchar = unreserved / pct-encoded / sub-delims / ":" / "@" unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" pct-encoded = "%" HEXDIG HEXDIG sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" Can you point out where in the IRI specification it says that '[' is a valid character to include in a query? Julian has agreed[1] that "If an example of a problem I'm facing is that escaping square brackets in query/search strings causes problems, I'm not likely to find the solution to that problem in IRIs." > I don't mean "could be", at this stage I hold they already are, and that > "URL parsers" are in fact IRI parsers, and this is what you want. I will claim that what exists as "URL parsers", and for that matter "URI parses" are NOT IRI parsers. Nor are the URI parsers. What they parse is neither a superset nor a subset of either URIs or IRIs. My goal is to work with authors of such parsers to remove as much as I can from the right-most column of the following: https://url.spec.whatwg.org/interop/test-results/ If, in the process, I can come up with a definition that is either a proper superset or a proper subset of an existing RFC, that would be great. > Dave. - Sam Ruby [1] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13782.html From nobody Thu Jan 15 07:43:56 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FC41B2CAB for ; Thu, 15 Jan 2015 07:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Spn0k9t7NmN1 for ; Thu, 15 Jan 2015 07:43:34 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 3C28E1B2CA7 for ; Thu, 15 Jan 2015 07:43:34 -0800 (PST) Received: from [192.168.1.194] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M1SLt-1Xvuem2nP7-00tW6p; Thu, 15 Jan 2015 16:43:29 +0100 Message-ID: <54B7E01B.2020000@gmx.de> Date: Thu, 15 Jan 2015 16:43:23 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Sam Ruby References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B7D87F.7070402@gmx.de> <54B7DD76.1010707@intertwingly.net> In-Reply-To: <54B7DD76.1010707@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:+KoB71vC9qtHhhUEKLrfnDd8E+jcVAXKZHMEpEvx90spg8cxlj8 sOzh9SL8K3M1xsqZ6Gd9Yp4ctK4XPVB3ZKDsQwnvjmiCu5LN8anfaNoheh9C4WHzWCfXsZ3 M18t1Bhb5M9Pyr/MLGyf0treFd1tVL/42CpVbxWleEHxAA3fcNazv2J2O1zIA9+lG2pWaWj 5r9SWW+QyG7OuPlNlkcVg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 15:43:39 -0000 On 2015-01-15 16:32, Sam Ruby wrote: > ... >> So, you're actually asking for two things, right? >> >> 1) allow raw "[" and "]" in queries (and paths, presumably) > > I'd like to have that discussion for queries at least. > >> 2) stop requiring recipients to remove percent-encoding before comparison > > I don't believe I've asked to have that discussion. > >> 1) is an interesting discussion to have; it maybe true that the URI spec >> is too defensive, as "[" and "]" are only special in the authority part. >> >> What scares me are the implications of 2) though. > > Again, I don't see why 2) is necessary. if 2) isn't necessary, the receiver mentioned in the bug report continues to be broken (in that it doesn't handle percent-encoding properly). >>> One possible outcome: this will be yet another case where following RFC >>> 3986 is not recommended. I intend to capture a list of such cases, and >>> produce a recommendation of what should be done instead. >> >> Can you clarify what you think about 2)? If you don't make that change >> as well, that recipient will continue to be broken. > > You seem to be assuming a lot, and it will take peeling back a number of > layers of the onion to get to where we are understanding each other. > > For starters, RFC 3986 essentially punts on topics like normalization > and comparison: > > https://tools.ietf.org/html/rfc3986#page-38 > > In particular, it explicitly acknoledges the possibility of simple > string comparison: > > https://tools.ietf.org/html/rfc3986#section-6.2.1 Yes. But it also says it will cause false negatives. > I conclude that RFC 3986, as it is currently written, does NOT require > recipients to remove percent-encoding before comparison, and as such, > I'm curious as to why you are suggesting that this requirement be removed? Just because the list of potential comparisons mentions char-by-char doesn't mean it's *always* the right thing to do (it is for instance for XML namespace names). It would be helpful if you actually stated where you want to go from here. If you don't do 2), a recipient will have to undo percent-encoding before doing comparisons on components. The software mentioned in the Mozilla bug does not, so it's broken as per the current spec. >>>> Whose definition of "URL" *does* include "Justin Bieber"? >>> >>> I've been told on this very mailing list just a few days ago that folks >>> have been confusing this very thing: >>> >>> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13648.html >>> >>> It is replies like that one, and your comment below that is causing me >>> to rapidly lose interest in trying to build on RFC 3986. >> >> I re-read Sean's mail and still don't get what you're referring to. > > Here's the quote: "Folks are confusing the "web browser text box at the > top" with URIs." It continues with an example: 'For example if you type > "? ietf"' Ah, ok. I thought you were referring to some participant on this list. Yes, there are people who don't know what a URL or a URI is. Users in generally do not *need* to know. And even among those who do understand the terms it is not uncommon to say "URL" when what they mean is "what does into a/@href". Best regards, Julian From nobody Thu Jan 15 07:56:33 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B663D1B2CB3 for ; Thu, 15 Jan 2015 07:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKaOfWgLwYK0 for ; Thu, 15 Jan 2015 07:56:27 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.227]) by ietfa.amsl.com (Postfix) with ESMTP id 874CA1B2C9D for ; Thu, 15 Jan 2015 07:56:27 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:48017] helo=rubix) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 54/BA-18452-A23E7B45; Thu, 15 Jan 2015 15:56:27 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id D15A4140CA1; Thu, 15 Jan 2015 10:56:26 -0500 (EST) Message-ID: <54B7E32A.9090800@intertwingly.net> Date: Thu, 15 Jan 2015 10:56:26 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 15:56:30 -0000 On 01/15/2015 10:42 AM, Murray S. Kucherawy wrote: > > Second, I don't know what the right answer is. I just know that > real people have sincerely attempted to follow RFC 3866 and > encountered real problems with doing so. > > I'd personally like to see RFC 3986 changed to address problems like > this one, and for the W3C specification of API behavior to build > upon this changed definition. > > I see a lot of chatter from multiple participants about what oughta > happen. Has anyone put pen to paper yet to propose an update or > replacement document that we can really look at? I was told (perhaps bad advice?) that the first step would be to publish a problem statement, which I have done: https://tools.ietf.org/id/draft-ruby-url-problem-01.txt I'd like to see some future revision of that document be accepted and published as an RFC. And that the next step would be a BOF: http://www.ietf.org/meeting/important-dates-2015.html Based on what I see, and discussions I have held, I'd like to proceed as outlined here: https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Nov/0000.html What that means in practice is reconciling the "authoring advice" and "railroad diagrams" as they appear here: https://specs.webplatform.org/url/webspecs/develop/#url-writing https://specs.webplatform.org/url/webspecs/develop/#rule-url With the collected ABNF for URI: https://tools.ietf.org/html/rfc3986#appendix-A > -MSK - Sam Ruby From nobody Thu Jan 15 07:59:52 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37C91B2CCF for ; Thu, 15 Jan 2015 07:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aub1uNmzlqn5 for ; Thu, 15 Jan 2015 07:59:47 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.231]) by ietfa.amsl.com (Postfix) with ESMTP id 6420A1B2CCC for ; Thu, 15 Jan 2015 07:59:47 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:48750] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id C3/FA-28314-2F3E7B45; Thu, 15 Jan 2015 15:59:46 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 93528140CA1; Thu, 15 Jan 2015 10:59:46 -0500 (EST) Message-ID: <54B7E3F2.4010200@intertwingly.net> Date: Thu, 15 Jan 2015 10:59:46 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Julian Reschke References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B7D87F.7070402@gmx.de> <54B7DD76.1010707@intertwingly.net> <54B7E01B.2020000@gmx.de> In-Reply-To: <54B7E01B.2020000@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 15:59:49 -0000 On 01/15/2015 10:43 AM, Julian Reschke wrote: > On 2015-01-15 16:32, Sam Ruby wrote: > >>>>> Whose definition of "URL" *does* include "Justin Bieber"? >>>> >>>> I've been told on this very mailing list just a few days ago that folks >>>> have been confusing this very thing: >>>> >>>> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13648.html >>>> >>>> It is replies like that one, and your comment below that is causing me >>>> to rapidly lose interest in trying to build on RFC 3986. >>> >>> I re-read Sean's mail and still don't get what you're referring to. >> >> Here's the quote: "Folks are confusing the "web browser text box at the >> top" with URIs." It continues with an example: 'For example if you type >> "? ietf"' > > Ah, ok. I thought you were referring to some participant on this list. Just so it is clear: what I was pointing out is a pure strawman that was posted by a participant on this list. That plus sarcasm plus caricatures all contribute to making this a not very welcome environment for discussion. - Sam Ruby From nobody Thu Jan 15 08:12:50 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0975F1B2C06 for ; Thu, 15 Jan 2015 08:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taYu29nnUoec for ; Thu, 15 Jan 2015 08:12:47 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 92C831B2C04 for ; Thu, 15 Jan 2015 08:12:46 -0800 (PST) Received: from [192.168.1.194] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LiY3U-1XdYgB3taG-00cg0x; Thu, 15 Jan 2015 17:12:44 +0100 Message-ID: <54B7E6F5.1020006@gmx.de> Date: Thu, 15 Jan 2015 17:12:37 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Sam Ruby References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B7D87F.7070402@gmx.de> <54B7DD76.1010707@intertwingly.net> <54B7E01B.2020000@gmx.de> <54B7E3F2.4010200@intertwingly.net> In-Reply-To: <54B7E3F2.4010200@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ZR7LzOBt3tHJQ78Y7qAF7koOWSU0nnlwMO3EZ3gT7kLlH2BDjPe 826yE2Cs7nI8rEKCPw3VPWpaHDh2DntdFMRzXm6S+OCmRR75KosoYmGf3bLOFJOTP0yGRpZ gsDTRoNk+TZfBWsZlWJei7F4d3VLPcKbu+tn4E0WdzuYgAfxKO2rd8Xmdn26By+Wky8SXyn M0UdkiIy0T/uvAdrckFzQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 16:12:49 -0000 On 2015-01-15 16:59, Sam Ruby wrote: > On 01/15/2015 10:43 AM, Julian Reschke wrote: >> On 2015-01-15 16:32, Sam Ruby wrote: >> >>>>>> Whose definition of "URL" *does* include "Justin Bieber"? >>>>> >>>>> I've been told on this very mailing list just a few days ago that >>>>> folks >>>>> have been confusing this very thing: >>>>> >>>>> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13648.html >>>>> >>>>> >>>>> It is replies like that one, and your comment below that is causing me >>>>> to rapidly lose interest in trying to build on RFC 3986. >>>> >>>> I re-read Sean's mail and still don't get what you're referring to. >>> >>> Here's the quote: "Folks are confusing the "web browser text box at the >>> top" with URIs." It continues with an example: 'For example if you type >>> "? ietf"' >> >> Ah, ok. I thought you were referring to some participant on this list. > > Just so it is clear: what I was pointing out is a pure strawman that was > posted by a participant on this list. That plus sarcasm plus > caricatures all contribute to making this a not very welcome environment > for discussion. Sam, I really really honestly don't know why you are upset about what Sean wrote in that mail, or by my request for clarification. In email conversations it *does* happen that people talk past each other, have different backgrounds with respect to terminology etc. The best way we can do here is to stay polite, and to ask for clarification in order to understand the other side. Right now, I'm completely confused about what you were trying to say when you wrote that sentence I asked about. Best regards, Julian From nobody Thu Jan 15 08:16:29 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F6D1B2D36 for ; Thu, 15 Jan 2015 08:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-0tqad5bdv7 for ; Thu, 15 Jan 2015 08:16:22 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4BE31B2D27 for ; Thu, 15 Jan 2015 08:16:20 -0800 (PST) Received: by mail-oi0-f47.google.com with SMTP id z81so13102050oif.6 for ; Thu, 15 Jan 2015 08:16:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A7Bh7XdR0SLFVTmN4vROfi1CnX/LQ0k/mzKIF5/UKhM=; b=OHnoSpzpmmJzelqce8QEVcsP3ffg+HT1eqMVVTtHrooHCwOkRbc3kC0uQLzU6diic7 mRHivetB3LLsS8y0rBEdWWhW9E6ooGQWn8jbGE0j9kvgSLo8D3kAxZmnNZc3Du2YYopY bhPjXrzlUZerhFKykFtCG2XaZezJvz0F0QRvg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=A7Bh7XdR0SLFVTmN4vROfi1CnX/LQ0k/mzKIF5/UKhM=; b=O7U2Kz/gsDq8s7p5gJmrM/XFeTllztjnifoTZh5lHNGkyVIIcHrVQF1XArKpY49bpZ IyVXI9G9Co+McTIdcBxkA4Wzu0EOKhTNYisZj/QBM/hEUf3Y6A8lDDFI3ttvqp8nL/tq YiHPhMHsIEyx+K8pNohuKirctpzEnzm4U9sWq1tOHNjh2XhIHSicUFLFbevjvqyU1jMs kaLYRUJry+CRyKAj6eGYDi0MtKvKQNga9KCtVAh9Rq0/5D39gThcOVwQMNS62kKvAgPE Aj+VREgPl+UT2FUUMhBt9eZOYzLlJh278ktV4Z+2fPFo4gB0mVQVxMbrRDXym+ZiKBYh jEVQ== X-Gm-Message-State: ALoCoQmeTHLVe0UdfGAcPXK8eeRcWy6cAdW33/d71gBwkI1gPWHDHXtIhESKffJOUVKT7HInMjL4 MIME-Version: 1.0 X-Received: by 10.202.187.10 with SMTP id l10mr6102949oif.86.1421338580081; Thu, 15 Jan 2015 08:16:20 -0800 (PST) Received: by 10.60.84.171 with HTTP; Thu, 15 Jan 2015 08:16:19 -0800 (PST) In-Reply-To: <54B7E00D.9040509@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net> <54B7E00D.9040509@intertwingly.net> Date: Thu, 15 Jan 2015 16:16:19 +0000 Message-ID: From: Dave Cridland To: Sam Ruby Content-Type: multipart/alternative; boundary=001a113ce0402bf4c8050cb32d92 Archived-At: Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 16:16:25 -0000 --001a113ce0402bf4c8050cb32d92 Content-Type: text/plain; charset=UTF-8 On 15 January 2015 at 15:43, Sam Ruby wrote: > > > On 01/15/2015 10:28 AM, Dave Cridland wrote: > >> On 15 January 2015 at 15:10, Sam Ruby > > wrote: >> >> First, a general comment. Why does this list attract people whose >> first resource is to go to caricature and sarcasm? >> >> If that's a reference to me, my first recourse was to suggest you read >> the relevant specifications and keep to the same terminology as the >> technical literature. My second recourse was to to attempt to clarify >> your position, since you hadn't responded to the first. >> >> I only did sarcasm on the third try - I've not yet done caricature. >> >> Please, read the IRI spec, and the HTML5 spec, and then tell me why you >> think that IRIs are not *already* the solution. >> > > Excerpt from RFC 3986: > > query = *( pchar / "/" / "?" ) > pchar = unreserved / pct-encoded / sub-delims / ":" / "@" > unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" > pct-encoded = "%" HEXDIG HEXDIG > sub-delims = "!" / "$" / "&" / "'" / "(" / ")" > / "*" / "+" / "," / ";" / "=" > > That's the URI spec, not the IRI spec... > Can you point out where in the IRI specification it says that '[' is a > valid character to include in a query? > > Julian has agreed[1] that "If an example of a problem I'm facing is that > escaping square brackets in query/search strings causes problems, I'm not > likely to find the solution to that problem in IRIs." > > *sigh* One argument at a time. I've already stated that I do not have any problem in principle with changing the rules on reserved characters in queries in this respect; moreover I'd be fine with "[]" in a number of places. It makes the specification slightly more complex, but I can live with that. Personally, I feel that on finding an unambiguous character that technically should have been %-encoded, passing it through seems fine - it's a bit of a pest to specify "unambiguous", but I think that's a paragraph or two. With respect to having non-ASCII characters in fragments (or anywhere else), can you *please* read the IRI spec and consider how that satisfies (or fails to satisfy) your requirements? > I don't mean "could be", at this stage I hold they already are, and that >> "URL parsers" are in fact IRI parsers, and this is what you want. >> > > I will claim that what exists as "URL parsers", and for that matter "URI > parses" are NOT IRI parsers. Nor are the URI parsers. What they parse is > neither a superset nor a subset of either URIs or IRIs. > > OK, I'll trust you that they don't parse only entirely valid IRIs. But modulo the odd reserved character not being %-encoded, I'm pretty sure they're the same. The reason I'm claiming that "URL parsers" are in fact aiming to parse IRIs is because they are, in general, aiming to parse "things that live in HREF attributes" - and these are IRIs and IRI relative-references as far as I can tell, so naturally the parsers have gravitated to that (if not by observation of the specifications). > My goal is to work with authors of such parsers to remove as much as I can > from the right-most column of the following: > > https://url.spec.whatwg.org/interop/test-results/ > > That's a great goal. By the way, when I switch to "conforming URLs", I see nothing there on first glance that would appear to be an invalid IRI reference. I think that's important. Also I think many of your "invalid URIs" are actually valid. For example, I don't see why "http://www.example.com/foo/%2e" is invalid; it's over-using %-encoding but that's legal if undesirable. > If, in the process, I can come up with a definition that is either a > proper superset or a proper subset of an existing RFC, that would be great. > > OK. I don't really see why you want to discard all existing RFCs and write your own. But I'm pretty sure you're after 99% of IRI. > Dave. >> > > - Sam Ruby > > [1] http://www.ietf.org/mail-archive/web/apps-discuss/ > current/msg13782.html > --001a113ce0402bf4c8050cb32d92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 15 January 2015 at 15:43, Sam Ruby <rubys@intertwingly.net= > wrote:


On 01/15/2015 10:28 AM, Dave Cridland wrote:
On 15 January 2015 at 15:10, Sam Ruby <rubys@intertwingly.net
 <mailto:ruby= s@intertwingly.net>> wrote:

=C2=A0 =C2=A0 First, a general comment.=C2=A0 Why does this list attract pe= ople whose
=C2=A0 =C2=A0 first resource is to go to caricature and sarcasm?

If that's a reference to me, my first recourse was to suggest you read<= br> the relevant specifications and keep to the same terminology as the
technical literature. My second recourse was to to attempt to clarify
your position, since you hadn't responded to the first.

I only did sarcasm on the third try - I've not yet done caricature.

Please, read the IRI spec, and the HTML5 spec, and then tell me why you
think that IRIs are not *already* the solution.

Excerpt from RFC 3986:

query=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D *( pchar / "/" / "= ;?" )
pchar=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D unreserved / pct-encoded / sub-d= elims / ":" / "@"
unreserved=C2=A0 =C2=A0 =3D ALPHA / DIGIT / "-" / "." /= "_" / "~"
pct-encoded=C2=A0 =C2=A0=3D "%" HEXDIG HEXDIG
sub-delims=C2=A0 =C2=A0 =3D "!" / "$" / "&&quo= t; / "'" / "(" / ")"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ "*&quo= t; / "+" / "," / ";" / "=3D"


That's the URI spec, not the IRI s= pec...
=C2=A0
Can you point out where in the IRI specification it says that '[' i= s a valid character to include in a query?

Julian has agreed[1] that "If an example of a problem I'm facing i= s that escaping square brackets in query/search strings causes problems, I&= #39;m not likely to find the solution to that problem in IRIs."


*sigh*

One argument at a time. I've already stated that I do not have any pro= blem in principle with changing the rules on reserved characters in queries= in this respect; moreover I'd be fine with "[]" in a number = of places. It makes the specification slightly more complex, but I can live= with that.

Personally, I feel that on finding an = unambiguous character that technically should have been %-encoded, passing = it through seems fine - it's a bit of a pest to specify "unambiguo= us", but I think that's a paragraph or two.

With respect to having non-ASCII characters in fragments (or anywhere el= se), can you *please* read the IRI spec and consider how that satisfies (or= fails to satisfy) your requirements?
=C2=A0
I don't mean "could be", at this stage I hold they already ar= e, and that
"URL parsers" are in fact IRI parsers, and this is what you want.=

I will claim that what exists as "URL parsers", and for that matt= er "URI parses" are NOT IRI parsers.=C2=A0 Nor are the URI parser= s.=C2=A0 What they parse is neither a superset nor a subset of either URIs = or IRIs.


OK, I'll trust you that they don&#= 39;t parse only entirely valid IRIs. But modulo the odd reserved character = not being %-encoded, I'm pretty sure they're the same.
The reason I'm claiming that "URL parsers" are i= n fact aiming to parse IRIs is because they are, in general, aiming to pars= e "things that live in HREF attributes" - and these are IRIs and = IRI relative-references as far as I can tell, so naturally the parsers have= gravitated to that (if not by observation of the specifications).
=C2=A0
My goal is to work with authors of such parsers to remove as much as I can = from the right-most column of the following:

https://url.spec.whatwg.org/interop/test-results/


That's a great goal.
By the way, when I switch to "conforming URLs", I see= nothing there on first glance that would appear to be an invalid IRI refer= ence. I think that's important. Also I think many of your "invalid= URIs" are actually valid. For example, I don't see why "http://www.example.com/foo/%2e&q= uot; is invalid; it's over-using %-encoding but that's legal if und= esirable.
=C2=A0
If, in the process, I can come up with a definition that is either a proper= superset or a proper subset of an existing RFC, that would be great.


OK. I don't really see why you wan= t to discard all existing RFCs and write your own. But I'm pretty sure = you're after 99% of IRI.
=C2=A0
Dave.

- Sam Ruby

[1] http://www.ietf.org/mail-archive/web/= apps-discuss/current/msg13782.html

--001a113ce0402bf4c8050cb32d92-- From nobody Thu Jan 15 08:28:15 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE6D1B2D7C for ; Thu, 15 Jan 2015 08:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LHBAz91btU9 for ; Thu, 15 Jan 2015 08:28:06 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 EFAC81B2C0C for ; Thu, 15 Jan 2015 08:28:05 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CCB6F22E1F4; Thu, 15 Jan 2015 11:27:58 -0500 (EST) Message-ID: <54B7EA36.7000804@seantek.com> Date: Thu, 15 Jan 2015 08:26:30 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Sam Ruby , Dave Cridland References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> In-Reply-To: <54B7BD4A.1090803@intertwingly.net> Content-Type: multipart/alternative; boundary="------------010102030806020400060307" Archived-At: Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 16:28:09 -0000 This is a multi-part message in MIME format. --------------010102030806020400060307 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit [SNIP] On 1/15/2015 5:14 AM, Sam Ruby wrote: > On 01/15/2015 07:35 AM, Dave Cridland wrote: >> 2) Why are IRIs (and moving the web, in general, towards IRIs where >> practical) not a solution here? > > All I can say is that I personally am not actively exploring that at > this time. I welcome people who know about this topic to participate > in this discussion. > > Given the pervasive lack of awareness of IRI's, I don't believe there > would be much interest in an appendix describing the differences > between W3C URLs and IETF IRIs. I do continue to believe that there > would be interest in such an appending describing the differences > between W3C URLs and IETF URIs. Ummmmm............... RDF, a W3C Recommendation, moved to IRIs *exclusively* in RDF v1.1 (25 Feb 2014). See . With all due respect to the W3C's activity, it seems that ought to be sufficient institutional knowledge amongst its participants to make use of IRIs and to distinguish them from URIs [RFC3986]. To quote from RDF Section 3.2: *URIs and IRIs:*IRIs are a generalization ofURIs[RFC3986 ] that permits a wider range of Unicode characters. Every absoluteURIand URL is anIRI, but not everyIRIis anURI. When IRIs are used in operations that are only defined for URIs, they must first be converted according to the mapping defined insection 3.1 of [RFC3987 ]. A notable example is retrieval over the HTTP protocol. The mapping involves UTF-8 encoding of non-ASCII characters, %-encoding of octets not allowed in URIs, and Punycode-encoding of domain names. It would be nice if the W3C maintains similar consistency across all of its specifications... Kind regards, Sean --------------010102030806020400060307 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
[SNIP]

On 1/15/2015 5:14 AM, Sam Ruby wrote:
On 01/15/2015 07:35 AM, Dave Cridland wrote:
2) Why are IRIs (and moving the web, in general, towards IRIs where
practical) not a solution here?

All I can say is that I personally am not actively exploring that at this time.  I welcome people who know about this topic to participate in this discussion.

Given the pervasive lack of awareness of IRI's, I don't believe there would be much interest in an appendix describing the differences between W3C URLs and IETF IRIs.  I do continue to believe that there would be interest in such an appending describing the differences between W3C URLs and IETF URIs.

Ummmmm...............

RDF, a W3C Recommendation, moved to IRIs *exclusively* in RDF v1.1 (25 Feb 2014). See <http://www.w3.org/TR/rdf11-concepts/>.

With all due respect to the W3C's activity, it seems that ought to be sufficient institutional knowledge amongst its participants to make use of IRIs and to distinguish them from URIs [RFC3986].

To quote from RDF Section 3.2:
URIs and IRIs: IRIs are a generalization of URIs [RFC3986] that permits a wider range of Unicode characters. Every absolute URI and URL is an IRI, but not every IRI is an URI. When IRIs are used in operations that are only defined for URIs, they must first be converted according to the mapping defined in section 3.1 of [RFC3987]. A notable example is retrieval over the HTTP protocol. The mapping involves UTF-8 encoding of non-ASCII characters, %-encoding of octets not allowed in URIs, and Punycode-encoding of domain names.

It would be nice if the W3C maintains similar consistency across all of its specifications...

Kind regards,

Sean

--------------010102030806020400060307-- From nobody Thu Jan 15 08:37:05 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A36E1B2D8A for ; Thu, 15 Jan 2015 08:36:57 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GySD_zU_tHHD for ; Thu, 15 Jan 2015 08:36:54 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 BB4FD1B2D88 for ; Thu, 15 Jan 2015 08:36:54 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 90BC922E25F; Thu, 15 Jan 2015 11:36:53 -0500 (EST) Message-ID: <54B7EC4D.9080603@seantek.com> Date: Thu, 15 Jan 2015 08:35:25 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , "apps-discuss@ietf.org" References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 16:36:57 -0000 It seems that many folks have some heated opinions, probably related to different backgrounds or technical experience on the matter. May I suggest that this topical area be included in a structured discussion on the agenda at IETF 92, either in APPSAWG or another appropriate forum, where the parties can be in one room and understand each others' perspectives. Cheers, Sean From nobody Thu Jan 15 08:38:49 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0E31B2D8E for ; Thu, 15 Jan 2015 08:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTYaLYjn2lhu for ; Thu, 15 Jan 2015 08:38:45 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.230]) by ietfa.amsl.com (Postfix) with ESMTP id 868A81B2D8C for ; Thu, 15 Jan 2015 08:38:45 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:57143] helo=rubix) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 63/36-31347-41DE7B45; Thu, 15 Jan 2015 16:38:45 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id F35E61409A6; Thu, 15 Jan 2015 11:38:43 -0500 (EST) Message-ID: <54B7ED13.8020709@intertwingly.net> Date: Thu, 15 Jan 2015 11:38:43 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Dave Cridland References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net> <54B7E00D.9040509@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 16:38:48 -0000 On 01/15/2015 11:16 AM, Dave Cridland wrote: > > Can you point out where in the IRI specification it says that '[' is > a valid character to include in a query? > > Julian has agreed[1] that "If an example of a problem I'm facing is > that escaping square brackets in query/search strings causes > problems, I'm not likely to find the solution to that problem in IRIs." > > *sigh* > > One argument at a time. I've already stated that I do not have any > problem in principle with changing the rules on reserved characters in > queries in this respect; moreover I'd be fine with "[]" in a number of > places. It makes the specification slightly more complex, but I can live > with that. So discussing how to change RFC 3986 to better match what is commonly deployed is indeed a possibility. > With respect to having non-ASCII characters in fragments (or anywhere > else), can you *please* read the IRI spec and consider how that > satisfies (or fails to satisfy) your requirements? I'm not personally convinced that layering URLs on top of IRIs which, in turn is layered on top of URIs solve more problems than it introduces. In addition, it clearly doesn't solve the problem mentioned above. > OK, I'll trust you that they don't parse only entirely valid IRIs. But > modulo the odd reserved character not being %-encoded, I'm pretty sure > they're the same. Given that IRIs are a superset of URIs, and there are demonstrable differences between how such parsers handle even pure ASCII strings, then the claim that they are the same are IRIs is clearly not true. > The reason I'm claiming that "URL parsers" are in fact aiming to parse > IRIs is because they are, in general, aiming to parse "things that live > in HREF attributes" - and these are IRIs and IRI relative-references as > far as I can tell, so naturally the parsers have gravitated to that (if > not by observation of the specifications). If what you are saying is that they both attempt to achieve the same goal, then I will agree. The recommendation I got from IETF area directors, W3C tag members, and liaisons was to propose URL as a replacement for RFC 3987. https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Nov/0000.html > My goal is to work with authors of such parsers to remove as much as > I can from the right-most column of the following: > > https://url.spec.whatwg.org/__interop/test-results/ > > > That's a great goal. Thanks! > By the way, when I switch to "conforming URLs", I see nothing there on > first glance that would appear to be an invalid IRI reference. I think > that's important. Also I think many of your "invalid URIs" are actually > valid. For example, I don't see why "http://www.example.com/foo/%2e" is > invalid; it's over-using %-encoding but that's legal if undesirable. That is entirely intentional. I have been working to make conforming URLs be a proper subset of valid IRIs, and where possible URIs. Allowing square brackets in query/search strings is an example where that isn't currently possible. As to valid URIs, I'm using the following code for validation: https://gist.github.com/think49/770087 If you know of a better test I can perform (preferably in JavaScript so it can run in a browser), please let me know. > If, in the process, I can come up with a definition that is either a > proper superset or a proper subset of an existing RFC, that would be > great. > > OK. I don't really see why you want to discard all existing RFCs and > write your own. But I'm pretty sure you're after 99% of IRI. Please don't. Strawmen on this list are getting rather tiring: https://yourlogicalfallacyis.com/strawman I am not discarding all existing RFCs. Based on advice I have received to date from people I trust, I don't believe that IRIs solve the problems I'm trying to address. Your cursory read of that spec hasn't changed my mind. Others have successfully dissuaded me from pursuing that goal further. If people are amenable to discussing changes to RFC 3986, perhaps we could work together. > Dave. - Sam Ruby From nobody Thu Jan 15 08:45:45 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D470B1B2BF9 for ; Thu, 15 Jan 2015 08:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.018 X-Spam-Level: X-Spam-Status: No, score=-0.018 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, FREEMAIL_REPLY=1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmZl6WdxGW0W for ; Thu, 15 Jan 2015 08:45:40 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0816A1B2DC7 for ; Thu, 15 Jan 2015 08:45:40 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id i8so4341486qcq.3 for ; Thu, 15 Jan 2015 08:45:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:from:to:subject:importance:date:in-reply-to :references:content-type; bh=9mBTbtnc86hq6zTbsHcf+TvizgNuajN0F8MF23DQrEk=; b=LMBREM/lHJhVZAIX5wRVLmbeubcWFmrzEKjN4RPrPyl1A4JEyOZ5MN2x/pWo6/WhEo l4jRyDr6PUQWV1rCr1Jivk1ntHKlKEj2mXWucX3HC3xVQpsWVTqrrUmc4DqH1904TOju nsYFDsN+WvQRToMIAfgbNPiwd6TX0c/PLufnyiG5K0tuXPhv/kMLw33j8RAflYnuyHMl J9Pz2Ok0oGSLDPa+JYWKhJxn9DQs401rHxFcr2qr1FzSkGhzOPFJe7OQwLLfyQjnz3cV kTRpTlVV94IcYEXOoTGiw8YMfIHtAdhFpPekbrSsOP1D9wT4yGjJlwGRAc/5i2rass+H hGEA== X-Received: by 10.140.91.201 with SMTP id z67mr7611214qgd.27.1421340339158; Thu, 15 Jan 2015 08:45:39 -0800 (PST) Received: from Pecan (bas11-montreal02-1128535737.dsl.bell.ca. [67.68.22.185]) by mx.google.com with ESMTPSA id l93sm480816qgd.23.2015.01.15.08.45.38 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 15 Jan 2015 08:45:38 -0800 (PST) Message-ID: <54b7eeb2.e6548c0a.45db.3890@mx.google.com> MIME-Version: 1.0 From: To: =?utf-8?Q?IETF_Apps_Discuss?= Importance: Normal Date: Thu, 15 Jan 2015 16:15:06 +0000 In-Reply-To: <54B7E32A.9090800@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net> , <54B7E32A.9090800@intertwingly.net> Content-Type: multipart/alternative; boundary="_28C31E10-59E9-4DAD-8119-582AD9413265_" Archived-At: Subject: Re: [apps-discuss] =?utf-8?q?Scope_of_RFC3986_and_successor_-_what_is?= =?utf-8?q?_a_URI=3F?= X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 16:45:42 -0000 --_28C31E10-59E9-4DAD-8119-582AD9413265_ Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" U2FtLA0KDQoNCg0KDQpXaGVuIHByb2Nlc3NpbmcgcXVlcnkgc3RyaW5nIHBhcmFtZXRlcnMsIGl0 IGlzIG5vcm1hbCB0aGF0ICUgZW5jb2RlZCB2YWx1ZXMgYmUgZGVjb2RlZC4gIFRoaXMgaXMgdGhl IHBvaW50IG9mIHRoZSAlZW5jb2RpbmcsIHRvIGFsbG93IHJlc2VydmVkIGNoYXJhY3RlcnMgdG8g YmUgY29udGFpbmVkIGluIHBhcmFtZXRlciB2YWx1ZXMuICBJZiBhIHJlY2lwaWVudCBvZiBhIFVS SSBkb2VzIG5vdCBwZXJjZW50IGRlY29kZSBwYXJhbWV0ZXIgdmFsdWVzIGJlZm9yZSB1c2luZyB0 aGVtLCB0aGVuIHRoZXkgYXJlIGdvaW5nIHRvIGJlIHVzaW5nIGludmFsaWQgZGF0YS4NCg0KVGhl cmVmb3JlLCBJIGRvbid0IHNlZSBob3cgYW55IGNvZGUgdGhhdCB3YXMgcHJldmlvdXNseSBjb3Jy ZWN0IHdvdWxkIGJlIGJyb2tlbiBieSBGaXJlZm94IGRlY2lkaW5nIHRvIGZvbGxvdyBSRkMgMzk4 NiBhbmQgJSBlbmNvZGUgdGhlIHNxdWFyZSBicmFja2V0cy4NCg0KDQpIb3dldmVyLCBpZiB5b3Ug ZmVlbCB0aGF0IFJGQyAzOTg2IHNob3VsZCBiZSBjaGFuZ2VkLCBJIHdvdWxkbuKAmXQgb2JqZWN0 Lg0KDQoNCg0KDQpEYXJyZWwNCg0KDQoNCg0KDQoNCg0KDQoNClNlbnQgZnJvbSBTdXJmYWNlDQoN Cg0KDQoNCg0KRnJvbTogU2FtIFJ1YnkNClNlbnQ6IOKAjlRodXJzZGF54oCOLCDigI5KYW51YXJ5 4oCOIOKAjjE14oCOLCDigI4yMDE1IOKAjjEw4oCOOuKAjjU24oCOIOKAjkFNDQpUbzogTXVycmF5 IFMuIEt1Y2hlcmF3eQ0KQ2M6IElFVEYgQXBwcyBEaXNjdXNzDQoNCg0KDQoNCg0KT24gMDEvMTUv MjAxNSAxMDo0MiBBTSwgTXVycmF5IFMuIEt1Y2hlcmF3eSB3cm90ZToNCj4NCj4gICAgIFNlY29u ZCwgSSBkb24ndCBrbm93IHdoYXQgdGhlIHJpZ2h0IGFuc3dlciBpcy4gIEkganVzdCBrbm93IHRo YXQNCj4gICAgIHJlYWwgcGVvcGxlIGhhdmUgc2luY2VyZWx5IGF0dGVtcHRlZCB0byBmb2xsb3cg UkZDIDM4NjYgYW5kDQo+ICAgICBlbmNvdW50ZXJlZCByZWFsIHByb2JsZW1zIHdpdGggZG9pbmcg c28uDQo+DQo+ICAgICBJJ2QgcGVyc29uYWxseSBsaWtlIHRvIHNlZSBSRkMgMzk4NiBjaGFuZ2Vk IHRvIGFkZHJlc3MgcHJvYmxlbXMgbGlrZQ0KPiAgICAgdGhpcyBvbmUsIGFuZCBmb3IgdGhlIFcz QyBzcGVjaWZpY2F0aW9uIG9mIEFQSSBiZWhhdmlvciB0byBidWlsZA0KPiAgICAgdXBvbiB0aGlz IGNoYW5nZWQgZGVmaW5pdGlvbi4NCj4NCj4gSSBzZWUgYSBsb3Qgb2YgY2hhdHRlciBmcm9tIG11 bHRpcGxlIHBhcnRpY2lwYW50cyBhYm91dCB3aGF0IG91Z2h0YQ0KPiBoYXBwZW4uICBIYXMgYW55 b25lIHB1dCBwZW4gdG8gcGFwZXIgeWV0IHRvIHByb3Bvc2UgYW4gdXBkYXRlIG9yDQo+IHJlcGxh Y2VtZW50IGRvY3VtZW50IHRoYXQgd2UgY2FuIHJlYWxseSBsb29rIGF0Pw0KDQpJIHdhcyB0b2xk IChwZXJoYXBzIGJhZCBhZHZpY2U/KSB0aGF0IHRoZSBmaXJzdCBzdGVwIHdvdWxkIGJlIHRvIHB1 Ymxpc2ggDQphIHByb2JsZW0gc3RhdGVtZW50LCB3aGljaCBJIGhhdmUgZG9uZToNCg0KICAgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1ydWJ5LXVybC1wcm9ibGVtLTAxLnR4dA0KDQpJ J2QgbGlrZSB0byBzZWUgc29tZSBmdXR1cmUgcmV2aXNpb24gb2YgdGhhdCBkb2N1bWVudCBiZSBh Y2NlcHRlZCBhbmQgDQpwdWJsaXNoZWQgYXMgYW4gUkZDLg0KDQpBbmQgdGhhdCB0aGUgbmV4dCBz dGVwIHdvdWxkIGJlIGEgQk9GOg0KDQogICBodHRwOi8vd3d3LmlldGYub3JnL21lZXRpbmcvaW1w b3J0YW50LWRhdGVzLTIwMTUuaHRtbA0KDQpCYXNlZCBvbiB3aGF0IEkgc2VlLCBhbmQgZGlzY3Vz c2lvbnMgSSBoYXZlIGhlbGQsIEknZCBsaWtlIHRvIHByb2NlZWQgYXMgDQpvdXRsaW5lZCBoZXJl Og0KDQogDQpodHRwczovL2xpc3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvcHVibGljLXdoYXR3 Zy1hcmNoaXZlLzIwMTROb3YvMDAwMC5odG1sDQoNCldoYXQgdGhhdCBtZWFucyBpbiBwcmFjdGlj ZSBpcyByZWNvbmNpbGluZyB0aGUgImF1dGhvcmluZyBhZHZpY2UiIGFuZCANCiJyYWlscm9hZCBk aWFncmFtcyIgYXMgdGhleSBhcHBlYXIgaGVyZToNCg0KICAgaHR0cHM6Ly9zcGVjcy53ZWJwbGF0 Zm9ybS5vcmcvdXJsL3dlYnNwZWNzL2RldmVsb3AvI3VybC13cml0aW5nDQogICBodHRwczovL3Nw ZWNzLndlYnBsYXRmb3JtLm9yZy91cmwvd2Vic3BlY3MvZGV2ZWxvcC8jcnVsZS11cmwNCg0KV2l0 aCB0aGUgY29sbGVjdGVkIEFCTkYgZm9yIFVSSToNCg0KICAgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzM5ODYjYXBwZW5kaXgtQQ0KDQo+IC1NU0sNCg0KLSBTYW0gUnVieQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KYXBwcy1kaXNjdXNz IG1haWxpbmcgbGlzdA0KYXBwcy1kaXNjdXNzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vzcw== --_28C31E10-59E9-4DAD-8119-582AD9413265_ Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" CjxodG1sPgo8aGVhZD4KPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJXaW5kb3dzIE1h aWwgMTcuNS45NjAwLjIwNjg5Ij4KPHN0eWxlPjwhLS0KaHRtbCB7CmZvbnQtZmFtaWx5OiJDb2xv ciBFbW9qaSIsICJDYWxpYnJpIiwgIlNlZ29lIFVJIiwgIk1laXJ5byIsICJNaWNyb3NvZnQgWWFI ZWkgVUkiLCAiTWljcm9zb2Z0IEpoZW5nSGVpIFVJIiwgIk1hbGd1biBHb3RoaWMiLCAic2Fucy1z ZXJpZiI7Cn0KLS0+PC9zdHlsZT48c3R5bGUgZGF0YS1leHRlcm5hbHN0eWxlPSJ0cnVlIj48IS0t CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGggewptYXJnaW4tdG9wOjBpbjsKbWFyZ2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTow aW47Cm1hcmdpbi1sZWZ0Oi41aW47Cm1hcmdpbi1ib3R0b206LjAwMDFwdDsKfQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsIHsKbWFyZ2luOjBpbjsKbWFyZ2luLWJvdHRv bTouMDAwMXB0Owp9CnAuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgbGkuTXNvTGlzdFBhcmFn cmFwaEN4U3BGaXJzdCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIApwLk1zb0xpc3RQ YXJhZ3JhcGhDeFNwTWlkZGxlLCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCAKcC5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QsIGxp Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCB7 Cm1hcmdpbi10b3A6MGluOwptYXJnaW4tcmlnaHQ6MGluOwptYXJnaW4tYm90dG9tOjBpbjsKbWFy Z2luLWxlZnQ6LjVpbjsKbWFyZ2luLWJvdHRvbTouMDAwMXB0OwpsaW5lLWhlaWdodDoxMTUlOwp9 Ci0tPjwvc3R5bGU+PC9oZWFkPgo8Ym9keSBkaXI9Imx0ciI+CjxkaXYgZGF0YS1leHRlcm5hbHN0 eWxlPSJmYWxzZSIgZGlyPSJsdHIiIHN0eWxlPSJmb250LWZhbWlseTogJ0NhbGlicmknLCAnU2Vn b2UgVUknLCAnTWVpcnlvJywgJ01pY3Jvc29mdCBZYUhlaSBVSScsICdNaWNyb3NvZnQgSmhlbmdI ZWkgVUknLCAnTWFsZ3VuIEdvdGhpYycsICdzYW5zLXNlcmlmJztmb250LXNpemU6MTJwdDsiPgoK CgoKPGRpdj5TYW0sPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5XaGVuIHByb2Nlc3NpbmcgcXVl cnkgc3RyaW5nIHBhcmFtZXRlcnMsIGl0IGlzIG5vcm1hbCB0aGF0ICUgZW5jb2RlZCB2YWx1ZXMg YmUgZGVjb2RlZC4mbmJzcDsgVGhpcyBpcyB0aGUgcG9pbnQgb2YgdGhlICVlbmNvZGluZywgdG8g YWxsb3cgcmVzZXJ2ZWQgY2hhcmFjdGVycyB0byBiZSBjb250YWluZWQgaW4gcGFyYW1ldGVyIHZh bHVlcy4mbmJzcDsgSWYgYSByZWNpcGllbnQgb2YgYSBVUkkgZG9lcyBub3QgcGVyY2VudCBkZWNv ZGUgcGFyYW1ldGVyIHZhbHVlcyBiZWZvcmUgdXNpbmcgdGhlbSwgdGhlbiB0aGV5IGFyZSBnb2lu ZyB0byBiZSB1c2luZyBpbnZhbGlkIGRhdGEuPC9kaXY+PGRpdj5UaGVyZWZvcmUsIEkgZG9uJ3Qg c2VlIGhvdyBhbnkgY29kZSB0aGF0IHdhcyBwcmV2aW91c2x5Jm5ic3A7Y29ycmVjdCB3b3VsZCBi ZSBicm9rZW4gYnkgRmlyZWZveCBkZWNpZGluZyB0byBmb2xsb3cgUkZDIDM5ODYgYW5kJm5ic3A7 JSBlbmNvZGUgdGhlIHNxdWFyZSBicmFja2V0cy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pkhv d2V2ZXIsIGlmIHlvdSBmZWVsIHRoYXQgUkZDIDM5ODYgc2hvdWxkIGJlIGNoYW5nZWQsIEkgd291 bGRu4oCZdCBvYmplY3QuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5EYXJyZWw8YnI+PC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdiBkYXRhLXNpZ25hdHVyZWJsb2NrPSJ0cnVlIj48ZGl2Pjxicj48 L2Rpdj48ZGl2PlNlbnQgZnJvbSBTdXJmYWNlPC9kaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+PGRp diBzdHlsZT0icGFkZGluZy10b3A6IDVweDsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDIyOSwgMjI5 LCAyMjkpOyBib3JkZXItdG9wLXdpZHRoOiAxcHg7IGJvcmRlci10b3Atc3R5bGU6IHNvbGlkOyI+ PGRpdj48Zm9udCBmYWNlPSIgJ0NhbGlicmknLCAnU2Vnb2UgVUknLCAnTWVpcnlvJywgJ01pY3Jv c29mdCBZYUhlaSBVSScsICdNaWNyb3NvZnQgSmhlbmdIZWkgVUknLCAnTWFsZ3VuIEdvdGhpYycs ICdzYW5zLXNlcmlmJyIgc3R5bGU9J2xpbmUtaGVpZ2h0OiAxNXB0OyBsZXR0ZXItc3BhY2luZzog MC4wMmVtOyBmb250LWZhbWlseTogIkNhbGlicmkiLCAiU2Vnb2UgVUkiLCAiTWVpcnlvIiwgIk1p Y3Jvc29mdCBZYUhlaSBVSSIsICJNaWNyb3NvZnQgSmhlbmdIZWkgVUkiLCAiTWFsZ3VuIEdvdGhp YyIsICJzYW5zLXNlcmlmIjsgZm9udC1zaXplOiAxMnB0Oyc+PGI+RnJvbTo8L2I+Jm5ic3A7PGEg aHJlZj0ibWFpbHRvOnJ1YnlzQGludGVydHdpbmdseS5uZXQiIHRhcmdldD0iX3BhcmVudCI+U2Ft IFJ1Ynk8L2E+PGJyPjxiPlNlbnQ6PC9iPiZuYnNwO+KAjlRodXJzZGF54oCOLCDigI5KYW51YXJ5 4oCOIOKAjjE14oCOLCDigI4yMDE1IOKAjjEw4oCOOuKAjjU24oCOIOKAjkFNPGJyPjxiPlRvOjwv Yj4mbmJzcDs8YSBocmVmPSJtYWlsdG86c3VwZXJ1c2VyQGdtYWlsLmNvbSIgdGFyZ2V0PSJfcGFy ZW50Ij5NdXJyYXkgUy4gS3VjaGVyYXd5PC9hPjxicj48Yj5DYzo8L2I+Jm5ic3A7PGEgaHJlZj0i bWFpbHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9yZyIgdGFyZ2V0PSJfcGFyZW50Ij5JRVRGIEFwcHMg RGlzY3VzczwvYT48L2ZvbnQ+PC9kaXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBkaXI9IiI+ PGRpdiBpZD0icmVhZGluZ1BhbmVCb2R5Q29udGVudCI+T24gMDEvMTUvMjAxNSAxMDo0MiBBTSwg TXVycmF5IFMuIEt1Y2hlcmF3eSB3cm90ZTo8YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFNlY29uZCwgSSBkb24ndCBrbm93IHdoYXQgdGhlIHJpZ2h0IGFuc3dlciBpcy4m bmJzcDsgSSBqdXN0IGtub3cgdGhhdDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJl YWwgcGVvcGxlIGhhdmUgc2luY2VyZWx5IGF0dGVtcHRlZCB0byBmb2xsb3cgUkZDIDM4NjYgYW5k PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW5jb3VudGVyZWQgcmVhbCBwcm9ibGVt cyB3aXRoIGRvaW5nIHNvLjxicj4mZ3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg SSdkIHBlcnNvbmFsbHkgbGlrZSB0byBzZWUgUkZDIDM5ODYgY2hhbmdlZCB0byBhZGRyZXNzIHBy b2JsZW1zIGxpa2U8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGlzIG9uZSwgYW5k IGZvciB0aGUgVzNDIHNwZWNpZmljYXRpb24gb2YgQVBJIGJlaGF2aW9yIHRvIGJ1aWxkPGJyPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdXBvbiB0aGlzIGNoYW5nZWQgZGVmaW5pdGlvbi48 YnI+Jmd0Ozxicj4mZ3Q7IEkgc2VlIGEgbG90IG9mIGNoYXR0ZXIgZnJvbSBtdWx0aXBsZSBwYXJ0 aWNpcGFudHMgYWJvdXQgd2hhdCBvdWdodGE8YnI+Jmd0OyBoYXBwZW4uJm5ic3A7IEhhcyBhbnlv bmUgcHV0IHBlbiB0byBwYXBlciB5ZXQgdG8gcHJvcG9zZSBhbiB1cGRhdGUgb3I8YnI+Jmd0OyBy ZXBsYWNlbWVudCBkb2N1bWVudCB0aGF0IHdlIGNhbiByZWFsbHkgbG9vayBhdD88YnI+PGJyPkkg d2FzIHRvbGQgKHBlcmhhcHMgYmFkIGFkdmljZT8pIHRoYXQgdGhlIGZpcnN0IHN0ZXAgd291bGQg YmUgdG8gcHVibGlzaCA8YnI+YSBwcm9ibGVtIHN0YXRlbWVudCwgd2hpY2ggSSBoYXZlIGRvbmU6 PGJyPjxicj4mbmJzcDsmbmJzcDsgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1ydWJ5 LXVybC1wcm9ibGVtLTAxLnR4dDxicj48YnI+SSdkIGxpa2UgdG8gc2VlIHNvbWUgZnV0dXJlIHJl dmlzaW9uIG9mIHRoYXQgZG9jdW1lbnQgYmUgYWNjZXB0ZWQgYW5kIDxicj5wdWJsaXNoZWQgYXMg YW4gUkZDLjxicj48YnI+QW5kIHRoYXQgdGhlIG5leHQgc3RlcCB3b3VsZCBiZSBhIEJPRjo8YnI+ PGJyPiZuYnNwOyZuYnNwOyBodHRwOi8vd3d3LmlldGYub3JnL21lZXRpbmcvaW1wb3J0YW50LWRh dGVzLTIwMTUuaHRtbDxicj48YnI+QmFzZWQgb24gd2hhdCBJIHNlZSwgYW5kIGRpc2N1c3Npb25z IEkgaGF2ZSBoZWxkLCBJJ2QgbGlrZSB0byBwcm9jZWVkIGFzIDxicj5vdXRsaW5lZCBoZXJlOjxi cj48YnI+Jm5ic3A7PGJyPmh0dHBzOi8vbGlzdHMudzMub3JnL0FyY2hpdmVzL1B1YmxpYy9wdWJs aWMtd2hhdHdnLWFyY2hpdmUvMjAxNE5vdi8wMDAwLmh0bWw8YnI+PGJyPldoYXQgdGhhdCBtZWFu cyBpbiBwcmFjdGljZSBpcyByZWNvbmNpbGluZyB0aGUgImF1dGhvcmluZyBhZHZpY2UiIGFuZCA8 YnI+InJhaWxyb2FkIGRpYWdyYW1zIiBhcyB0aGV5IGFwcGVhciBoZXJlOjxicj48YnI+Jm5ic3A7 Jm5ic3A7IGh0dHBzOi8vc3BlY3Mud2VicGxhdGZvcm0ub3JnL3VybC93ZWJzcGVjcy9kZXZlbG9w LyN1cmwtd3JpdGluZzxicj4mbmJzcDsmbmJzcDsgaHR0cHM6Ly9zcGVjcy53ZWJwbGF0Zm9ybS5v cmcvdXJsL3dlYnNwZWNzL2RldmVsb3AvI3J1bGUtdXJsPGJyPjxicj5XaXRoIHRoZSBjb2xsZWN0 ZWQgQUJORiBmb3IgVVJJOjxicj48YnI+Jm5ic3A7Jm5ic3A7IGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmMzOTg2I2FwcGVuZGl4LUE8YnI+PGJyPiZndDsgLU1TSzxicj48YnI+LSBTYW0g UnVieTxicj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+YXBwcy1kaXNjdXNzIG1haWxpbmcgbGlzdDxicj5hcHBzLWRpc2N1c3NAaWV0Zi5vcmc8 YnI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3M8YnI+ PC9kaXY+PC9kaXY+CgoKCgoKCgoKCgoKCgoKPC9kaXY+CjwvYm9keT4KPC9odG1sPgo= --_28C31E10-59E9-4DAD-8119-582AD9413265_-- From nobody Thu Jan 15 08:48:26 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D919B1B2DF6 for ; Thu, 15 Jan 2015 08:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAaysKMdLj5s for ; Thu, 15 Jan 2015 08:48:17 -0800 (PST) Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) by ietfa.amsl.com (Postfix) with ESMTP id 52BAA1B2DF5 for ; Thu, 15 Jan 2015 08:48:17 -0800 (PST) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YBnah-0002jU-q1; Thu, 15 Jan 2015 16:48:15 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YBnag-0003YA-MK; Thu, 15 Jan 2015 16:48:15 +0000 Message-ID: <54B7EF4E.8040703@ninebynine.org> Date: Thu, 15 Jan 2015 16:48:14 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , "Murray S. Kucherawy" References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net> <54B7E32A.9090800@intertwingly.net> In-Reply-To: <54B7E32A.9090800@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 16:48:24 -0000 On 15/01/2015 15:56, Sam Ruby wrote: > I was told (perhaps bad advice?) that the first step would be to publish a > problem statement, which I have done: > > https://tools.ietf.org/id/draft-ruby-url-problem-01.txt > > I'd like to see some future revision of that document be accepted and > published as an RFC. > Taking a look at section 4 of that document, here are my thoughts (with premise my previous comments about Scope of RFC3986): ... o Nomenclature: over the years, a number of different sets of terminology has been used. This may be a problem, but I don't see it as a problem specifically with RFC3986. And, while it may be confusing, I don't see it as a root cause of interoperability problems. ... o Deterministic parsing and transformation: I don't see this as a problem with RFC3986. ... o Parameterization: standards in this area need to define such matters as normalization forms and values for parameters such as UseSTD3ASCIIRules. I'm not entirely sure what this means, so I may be missing something. But I don't see this as a problem with RFC3986. ... o Interoperability: even after accounting for the above, there is a demonstrable lack of interoperability across popular libraries and browsers. I don't see this demonstrates a problem with RFC3986, though I'd be open to consider specific claims that it is. If developers or dependent standards writers choose to not follow an established standard, I don't see that writing a new standard solves anything. (http://xkcd.com/927/ anyone? I apologize if that seems like sarcasm, but I think it makes a valid point.) ... o Stability: Before any standard document can be marked as obsoleted, the requirements other specs that normatively reference the to-be-obsoleted standard need to be considered, to avoid dangling references. I don't see this as a problem with RFC3986. But if the proposal is to obsolete RFC3986, I think it's a major problem for all the other standards that depend on it. ... o IDNA: [RFC3490] defines processing for 'IDN-aware domain name slots' (where "the host portion of the URI in the src attribute of an HTML tag" is given as an example. Later, "IDNA is applicable to all domain names in all domain name slots". So in mailto:user@host, is the host a IDN-aware domain name slot? A domain name slot at all? I don't see this as a problem with RFC3986. ... o Bidi URLs: The problems with writing URLs using characters from right-to-left languages are well-known among experts; what is not known is a solution for these problems. The solution given in [RFC3987] has some obvious errors (how to handle combining marks); it's general approach also probably can be improved on, but it's not sure how. I don't see this as a problem with RFC3986 (which is, by design, restricted to USASCII characters). ... o Specific scheme definitions: some UR* scheme definitions are woefully out of date, incomplete, or don't correspond to current practice, but updating their definitions is unclear. This includes 'file:', for which there is a current effort, but there are others which need review (including 'ftp:', 'data:'). I don't see this as a problem with RFC3986. ... I fear I sound like a broken record here. I don't deny there are problems in all the areas you mention, but for the most part I don't see them as problems with RFC 3986. I think we need to look beyond RFC3986, and build upon it, the solutions that can address the problems. If it turns out there is a consensus that there are changes that should be made to base URI syntax (e.g. the recent discussion around '[' and ']') then fine, lets discuss those as possible evolutionary updates, but with careful consideration for applications that do take note of RFC3986. Personally, I think that introducing '[' and ']' now as valid URI characters would be a violation of Postel's robustness principle (http://en.wikipedia.org/wiki/Robustness_principle). #g -- From nobody Thu Jan 15 09:19:42 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D59F1B2E60 for ; Thu, 15 Jan 2015 09:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4zkaeLjs7PI for ; Thu, 15 Jan 2015 09:19:33 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 770561B2E33 for ; Thu, 15 Jan 2015 09:19:33 -0800 (PST) Received: by mail-oi0-f46.google.com with SMTP id a3so13389831oib.5 for ; Thu, 15 Jan 2015 09:19:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3j3C5TnYaRHyezAKSyHC0+B7HGBoWlSHuM/MMBRSYTY=; b=DCTIPQfvOt2HVKkBt5zBCj2SejFzAF70YDo0sH38FslaZsToAI57dODgtS4maAPnx2 vDSmRStf7+gB8K6JUCK5UGpFYv01x6SKQr8bGgyhxUofIBoBakbYfIa6ORiD4bhJDsSU apA2BjjwUBuaZuDEqHncaD2rmBanG+9hkuec8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3j3C5TnYaRHyezAKSyHC0+B7HGBoWlSHuM/MMBRSYTY=; b=QJ9EbslwotgRwzvpuG9/wimtXg8viQGP0Ar5geZi/KiQFDmr56EtOQ6m9u1ezoRcyL nrQTiytVwYLrPniCkgVu7K3KD8TPAromoE8YxC5mNaOOFaGsisITKwueZX2qRs6DgJz7 3NLMrDDMvO9VXv2UUu67iEiF6FfAd5h+9KqOwbtBIFzrlROUG4OUmTLtGalY8laQcTu0 L9HAbQsA4bwLy+ZgiklBKCQHbGxxQTwntBVrAxBini/LZE+c7B6hTHYkF14HN4MChZ+0 R6mileIfTFpsWT8Qcef9C5bpgqTgpf5dow0BtX9pxeJwfIk7CiLPcEOxxpLWPU+J649O O2Pw== X-Gm-Message-State: ALoCoQmzbqlsoojO3EYtnK9PSQGWFFZSPK1nrg0s3Fngn9hK82n6jYlLme5RXVa2AhLBZ+86XIy0 MIME-Version: 1.0 X-Received: by 10.202.1.200 with SMTP id 191mr6237688oib.31.1421342372685; Thu, 15 Jan 2015 09:19:32 -0800 (PST) Received: by 10.60.84.171 with HTTP; Thu, 15 Jan 2015 09:19:32 -0800 (PST) In-Reply-To: <54B7ED13.8020709@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net> <54B7E00D.9040509@intertwingly.net> <54B7ED13.8020709@intertwingly.net> Date: Thu, 15 Jan 2015 17:19:32 +0000 Message-ID: From: Dave Cridland To: Sam Ruby Content-Type: multipart/alternative; boundary=001a1137dd103a8184050cb40fb8 Archived-At: Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 17:19:36 -0000 --001a1137dd103a8184050cb40fb8 Content-Type: text/plain; charset=UTF-8 On 15 January 2015 at 16:38, Sam Ruby wrote: > On 01/15/2015 11:16 AM, Dave Cridland wrote: > >> >> Can you point out where in the IRI specification it says that '[' is >> a valid character to include in a query? >> >> Julian has agreed[1] that "If an example of a problem I'm facing is >> that escaping square brackets in query/search strings causes >> problems, I'm not likely to find the solution to that problem in >> IRIs." >> >> *sigh* >> >> One argument at a time. I've already stated that I do not have any >> problem in principle with changing the rules on reserved characters in >> queries in this respect; moreover I'd be fine with "[]" in a number of >> places. It makes the specification slightly more complex, but I can live >> with that. >> > > So discussing how to change RFC 3986 to better match what is commonly > deployed is indeed a possibility. > > You would need to, I think, change both RFC 3986 and RFC 3987, but no, there's no fundamental objection from me. Discarding them both out of hand would, I think, be a serious mistake, as would using specific localized problems to declare them entirely irrelevant. > With respect to having non-ASCII characters in fragments (or anywhere >> else), can you *please* read the IRI spec and consider how that >> satisfies (or fails to satisfy) your requirements? >> > > I'm not personally convinced that layering URLs on top of IRIs which, in > turn is layered on top of URIs solve more problems than it introduces. In > addition, it clearly doesn't solve the problem mentioned above. > > Multiple layers do actually solve problems. But I don't think you need to. I think that - while there's tweaks to the specification that can (and perhaps should) be made, IRIs fit your essential requirements for syntax. That is, you can, more or less, ignore URIs, and concentrate on IRIs for parsing purposes. Then you add a "toASCII" operation on your object, and you're done. Parsing them consistently, especially for some error cases, is a different matter, and something a new W3C/WHATWG spec can usefully address. Put another way your "URLs" - and really, it'd be much easier if we could at least agree to use the existing terminology - are essentially IRIs. > OK, I'll trust you that they don't parse only entirely valid IRIs. But >> modulo the odd reserved character not being %-encoded, I'm pretty sure >> they're the same. >> > > Given that IRIs are a superset of URIs, and there are demonstrable > differences between how such parsers handle even pure ASCII strings, then > the claim that they are the same are IRIs is clearly not true. > > "modulo the odd reserved character not being %-encoded", I said. If there's other differences, you've not mentioned them, and I've yet to see them. > The reason I'm claiming that "URL parsers" are in fact aiming to parse >> IRIs is because they are, in general, aiming to parse "things that live >> in HREF attributes" - and these are IRIs and IRI relative-references as >> far as I can tell, so naturally the parsers have gravitated to that (if >> not by observation of the specifications). >> > > If what you are saying is that they both attempt to achieve the same goal, > then I will agree. The recommendation I got from IETF area directors, W3C > tag members, and liaisons was to propose URL as a replacement for RFC 3987. > > https://lists.w3.org/Archives/Public/public-whatwg-archive/ > 2014Nov/0000.html > > Which Area Directors? I honestly don't recall this being raised before, and I find it surprising it went unremarked. > My goal is to work with authors of such parsers to remove as much as >> I can from the right-most column of the following: >> >> https://url.spec.whatwg.org/__interop/test-results/ >> >> >> That's a great goal. >> > > Thanks! > > By the way, when I switch to "conforming URLs", I see nothing there on >> first glance that would appear to be an invalid IRI reference. I think >> that's important. Also I think many of your "invalid URIs" are actually >> valid. For example, I don't see why "http://www.example.com/foo/%2e" is >> invalid; it's over-using %-encoding but that's legal if undesirable. >> > > That is entirely intentional. I have been working to make conforming URLs > be a proper subset of valid IRIs, and where possible URIs. Allowing square > brackets in query/search strings is an example where that isn't currently > possible. > > OK, but how do you know if they're conformant to the IRI spec if you don't read it? > As to valid URIs, I'm using the following code for validation: > > https://gist.github.com/think49/770087 > > If you know of a better test I can perform (preferably in JavaScript so it > can run in a browser), please let me know. > > Huh. I don't immediately see why the example I gave isn't valid according to that code either (unless it's case sensitivity in HEXDIGIT). I do see the example I gave is valid according to RFC 3986, though. I imagine you could persuade https://github.com/hildjj/node-abnf to run in a browser, and avoid hand-crafted regexps. > If, in the process, I can come up with a definition that is either a >> proper superset or a proper subset of an existing RFC, that would be >> great. >> >> OK. I don't really see why you want to discard all existing RFCs and >> write your own. But I'm pretty sure you're after 99% of IRI. >> > > Please don't. Strawmen on this list are getting rather tiring: > > https://yourlogicalfallacyis.com/strawman > > That's not a strawman, it's hyperbole, but okay, I can play that game. You're discarding RFC 3987 without even reading it, and your stated desire is to discard RFC 3986, writing a new specification without reference. That's neither hyperbole nor a strawman, that is genuinely what I understand your goal to be. > I am not discarding all existing RFCs. Based on advice I have received to > date from people I trust, I don't believe that IRIs solve the problems I'm > trying to address. Your cursory read of that spec hasn't changed my mind. > Others have successfully dissuaded me from pursuing that goal further. > > https://yourlogicalfallacyis.com/appeal-to-authority So, you're being willfully ignorant, then, albeit on the poor advice of others. If your aim is to replace RFC 3987, you really need to read it and decide for yourself on its own merits. Speaking entirely personally, the thing that discomforts me about it is the name. I can't ever think of typing an IRI into a web browser, despite the fact that's exactly what I do. > If people are amenable to discussing changes to RFC 3986, perhaps we could > work together. > > Dave. >> > > - Sam Ruby > --001a1137dd103a8184050cb40fb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 5 January 2015 at 16:38, Sam Ruby <rubys@intertwingly.net> wrote:
On 01/15/2015 11:16 AM, Dav= e Cridland wrote:

=C2=A0 =C2=A0 Can you point out where in the IRI specification it says that= '[' is
=C2=A0 =C2=A0 a valid character to include in a query?

=C2=A0 =C2=A0 Julian has agreed[1] that "If an example of a problem I&= #39;m facing is
=C2=A0 =C2=A0 that escaping square brackets in query/search strings causes<= br> =C2=A0 =C2=A0 problems, I'm not likely to find the solution to that pro= blem in IRIs."

*sigh*

One argument at a time. I've already stated that I do not have any
problem in principle with changing the rules on reserved characters in
queries in this respect; moreover I'd be fine with "[]" in a = number of
places. It makes the specification slightly more complex, but I can live with that.

 So discussing how to change RFC 3986 to better match what is commonly deplo= yed is indeed a possibility.


You would need to, I think, cha= nge both RFC 3986 and RFC 3987, but no, there's no fundamental objectio= n from me. Discarding them both out of hand would, I think, be a serious mi= stake, as would using specific localized problems to declare them entirely = irrelevant.
=C2=A0
With respect to having non-ASCII characters in fragments (or anywhere
else), can you *please* read the IRI spec and consider how that
satisfies (or fails to satisfy) your requirements?

 I'm not personally convinced that layering URLs on top of IRIs which, i= n turn is layered on top of URIs solve more problems than it introduces. In= addition, it clearly doesn't solve the problem mentioned above.


Multiple layers do actually sol= ve problems.

But I don't think you need to.

I think that - while there's tweaks to the speci= fication that can (and perhaps should) be made, IRIs fit your essential req= uirements for syntax. That is, you can, more or less, ignore URIs, and conc= entrate on IRIs for parsing purposes. Then you add a "toASCII" op= eration on your object, and you're done.

Parsi= ng them consistently, especially for some error cases, is a different matte= r, and something a new W3C/WHATWG spec can usefully address.

=
Put another way your "URLs" - and really, it'd be = much easier if we could at least agree to use the existing terminology - ar= e essentially IRIs.
=C2=A0
OK, I'll trust you that they don't parse only entirely valid IRIs. = But
modulo the odd reserved character not being %-encoded, I'm pretty sure<= br> they're the same.

 Given that IRIs are a superset of URIs, and there are demonstrable differen= ces between how such parsers handle even pure ASCII strings, then the claim= that they are the same are IRIs is clearly not true.


"modulo the odd reserved c= haracter not being %-encoded", I said.

If the= re's other differences, you've not mentioned them, and I've yet= to see them.
=C2=A0
The reason I'm claiming that "URL parsers" are in fact aiming= to parse
IRIs is because they are, in general, aiming to parse "things that liv= e
in HREF attributes" - and these are IRIs and IRI relative-references a= s
far as I can tell, so naturally the parsers have gravitated to that (if
not by observation of the specifications).

 If what you are saying is that they both attempt to achieve the same goal, = then I will agree.=C2=A0 The recommendation I got from IETF area directors,= W3C tag members, and liaisons was to propose URL as a replacement for RFC = 3987.

https://lists.w3.org/Archives/Public= /public-whatwg-archive/2014Nov/0000.html


Which Area Directors? I honestly don&#= 39;t recall this being raised before, and I find it surprising it went unre= marked.
=C2=A0
=C2=A0 =C2=A0 My goal is to work with authors of such parsers to remove as = much as
=C2=A0 =C2=A0 I can from the right-most column of the following:

 =C2=A0 =C2=A0 https://url.spec.whatwg.org/__interop/test-resu= lts/
=C2=A0 =C2=A0 <https://url.spec.whatwg.org/interop/test-resu= lts/>

That's a great goal.

Thanks!

By the way, when I switch to "conforming URLs", I see nothing the= re on
first glance that would appear to be an invalid IRI reference. I think
that's important. Also I think many of your "invalid URIs" ar= e actually
valid. For example, I don't see why "http://www.example.com/foo/%2e&q= uot; is
invalid; it's over-using %-encoding but that's legal if undesirable= .

 That is entirely intentional.=C2=A0 I have been working to make conforming = URLs be a proper subset of valid IRIs, and where possible URIs. Allowing sq= uare brackets in query/search strings is an example where that isn't cu= rrently possible.


OK, but how do you know if they're= conformant to the IRI spec if you don't read it?
=C2=A0
As to valid URIs, I'm using the following code for validation:

https:= //gist.github.com/think49/770087

If you know of a better test I can perform (preferably in JavaScript so it = can run in a browser), please let me know.


Huh. I don't immediately se= e why the example I gave isn't valid according to that code either (unl= ess it's case sensitivity in HEXDIGIT). I do see the example I gave is = valid according to RFC 3986, though.

I imagine you= could persuade=C2=A0https:= //github.com/hildjj/node-abnf to run in a browser, and avoid hand-craft= ed regexps.
=C2=A0
=C2=A0 =C2=A0 If, in the process, I can come up with a definition that is e= ither a
=C2=A0 =C2=A0 proper superset or a proper subset of an existing RFC, that w= ould be
=C2=A0 =C2=A0 great.

OK. I don't really see why you want to discard all existing RFCs and write your own. But I'm pretty sure you're after 99% of IRI.

 Please don't.=C2=A0 Strawmen on this list are getting rather tiring:
htt= ps://yourlogicalfallacyis.com/strawman


That's not a strawman, it's hy= perbole, but okay, I can play that game.

You'r= e discarding RFC 3987 without even reading it, and your stated desire is to= discard RFC 3986, writing a new specification without reference. That'= s neither hyperbole nor a strawman, that is genuinely what I understand you= r goal to be.
=C2=A0
I am not discarding all existing RFCs.=C2=A0 Based on advice I have receive= d to date from people I trust, I don't believe that IRIs solve the prob= lems I'm trying to address.=C2=A0 Your cursory read of that spec hasn&#= 39;t changed my mind.=C2=A0 Others have successfully dissuaded me from purs= uing that goal further.



So, you're being willfully ignora= nt, then, albeit on the poor advice of others.

If = your aim is to replace RFC 3987, you really need to read it and decide for = yourself on its own merits.

Speaking entirely pers= onally, the thing that discomforts me about it is the name. I can't eve= r think of typing an IRI into a web browser, despite the fact that's ex= actly what I do.
=C2=A0
If people are amenable to discussing changes to RFC 3986, perhaps we could = work together.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Dave.<= br>

- Sam Ruby

--001a1137dd103a8184050cb40fb8-- From nobody Thu Jan 15 09:20:00 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89531B2E67 for ; Thu, 15 Jan 2015 09:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWw2qvj1oVwR for ; Thu, 15 Jan 2015 09:19:54 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 6132C1B2E6B for ; Thu, 15 Jan 2015 09:19:41 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id t0FHJdUG029719; Thu, 15 Jan 2015 17:19:39 GMT 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 t0FHJc4H010439; Thu, 15 Jan 2015 17:19:38 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t0FHJcoV023577; Thu, 15 Jan 2015 17:19:38 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id t0FHJc4w023573; Thu, 15 Jan 2015 17:19:38 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Sam Ruby References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 15 Jan 2015 17:19:38 +0000 In-Reply-To: <54B7D605.2060307@intertwingly.net> (Sam Ruby's message of "Thu\, 15 Jan 2015 10\:00\:21 -0500") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Cc: Julian Reschke , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 17:19:58 -0000 Sam Ruby writes: > On 01/15/2015 09:31 AM, Julian Reschke wrote: >> On 2015-01-15 14:14, Sam Ruby wrote: >>> ... >>> >>> Meanwhile, I do know that there are a number of implementations that >>> claim to be RFC 3986 compliant that do not percent encode non-ASCII >>> characters contained in fragments. >>> ... >> >> That is a case of "garbage in, garbage out", no? (where "garbage" means >> "not a valid URI"). >> >> Or do you have a case where a library accepted a RFC3986-valid fragment >> identifier containing percent-escapes and *removed* that escaping? > > Just so that we are understanding one another: this is a case where > some software (in particular a browser) attempted to produce valid > URIs per RFC 3986 and things broke as a result. Ah, so perhaps here is the missing argument! I didn't see anything in https://bugzilla.mozilla.org/show_bug.cgi?id=1121826 which suggested that anything had broken. All I saw was the OP calling attention to the difference between different browser behaviours, and stating his preference for the no-escaping alternative. Did I miss something? Or [per private communication], if your the problem is not with the error recovery as such, but rather with the current consensus position that '[' and ']' are invalid in query in the first place, _that_ becomes the point on which I'd like to hear what kind of arguments have convinced you that, as between the following possible situations, what you would prefer is option (3): [using 'I_URI' for URIs as defined in 3986, and 'W_URL' for URLs as defined in [1]] 1) (the _status quo_): Square brackets are not valid in the query part of I_URI or W_URL; [1] specifies non-%-encoded error recovery; browsers differ; 2) (what I thought you wanted): Square brackets are not valid in the query part of I_URI or W_URL; [1] specifies non-%-encoded error recovery; browsers all implement non-%-encoded error recovery; 3) (what I now think you want): Square brackets are valid in the query part of I_URI and W_URL, i.e. 3986 is superseded with an appropriate change to the relevant productions and [1] is modified to similar effect; no error-recovery is needed. ht [1] https://url.spec.whatwg.org/, as of 2015-01-15 -- 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 Jan 15 09:33:06 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487E51B2E7F for ; Thu, 15 Jan 2015 09:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iD7jkT9N8bMO for ; Thu, 15 Jan 2015 09:33:01 -0800 (PST) Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBDE1B2E9D for ; Thu, 15 Jan 2015 09:32:42 -0800 (PST) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YBoHg-0008NX-pJ; Thu, 15 Jan 2015 17:32:40 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YBoHg-0004u0-LL; Thu, 15 Jan 2015 17:32:40 +0000 Message-ID: <54B7F9B8.6050900@ninebynine.org> Date: Thu, 15 Jan 2015 17:32:40 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> In-Reply-To: <54B7AEC2.9010109@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 17:33:04 -0000 On 15/01/2015 12:12, Sam Ruby wrote: > On 01/15/2015 05:40 AM, Graham Klyne wrote: >> I've been thinking about our discussion, and why we appear to talk past >> each other. I think it lies in part with this: >> >> On 11/01/2015 19:18, Sam Ruby wrote: >>> I'd like the following Perl expression: >>> >>> URI->new_abs(input, base)->scheme . ":" >>> >>> ... to produce the same value as the following JavaScript expression: >>> >>> new URL(input, base).protocol >>> >>> ... for all sets of input and bases. >>> >>> Whether that means getting Perl to change, one or more web browsers to >>> change, >>> or one or more specs to change (and quite possibly, a combination of >>> the above), >>> is yet to be determined. >> >> >> My view: >> >> 1. IN SCOPE: The normative scope of RFC3986 is (a) to define what is a >> valid URI and URI reference, and (b) to describe the result of combining >> a valid URI (i.e. a base URI) with a URI reference to obtain a valid URI >> corresponding to that combination. Everything else (to a first >> approximation) is explanatory or descriptive. >> >> >> 2. OUT OF SCOPE: it is not the place of RFC3986 to define API behaviour. >> >> I think your desire to have a unified API behaviour to access URI >> components is fine, just not in the scope of RFC3986. >> >> Your test data show that different implementations do different things >> with URI strings, and this may be problematic in some contexts. But I >> don't think that, of themselves, they show that the problem is with RFC >> 3986. >> >> I use URI parsers in my current work that I know are not entirely >> conformant with RFC3986, in the sense that they may accept URIs that are >> not strictly valid according the syntax defined. I believe these >> divergences show up in your test data. But this has not caused any >> interoperability problems for me, as long as valid URIs are accepted. >> For me, it is not an issue that PERL and Javascript APIs may behave >> slightly differently, but I accept that it may be a concern for others. > > I see divergences in results even when inputs are valid according to RFC 3986 > (note the use of the filter in the below): > > https://url.spec.whatwg.org/interop/test-results/?filter=valid As far as I can tell, based on a cursory scan, the divergences are in API behaviour. Which I claim is not in scope of RFC3986, so it's not an RFC3986 problem. I explicitly said that your desire for consistent API behaviour is reasonable. I just don't think that updating RFC3986 is the best way to get there. > >> 3. SUGGESTION: >> >> Rather than proposing to update/replace RFC3986 directly, extending the >> scope to include API behaviour, construct a new specification that >> builds upon (rather than replacing) RFC 3986 normative content to >> describe a consistent API behaviour. If doing this exposes any specific >> problems in the RFC3986 normative content, propose specific updates. > > I proposed that the set of characters allowed in a fragment be changed to match > the following: > > https://specs.webplatform.org/url/webspecs/develop/#url-code-points > > When I did so, people freaked out, piled on, and generally made points unrelated > to what was actually proposed. My takeaway: this mailing list is not a > receptive place for people who identify specific problems and proposing specific > updates. Forgive me if I'm not exactly eager to do that again. I guess there are a lot of people here (myself included) who are quite heavily invested in what RFC3986 has to say about URIs, and for whom the change you propose would cause pain. That was the gist of my response. I think these are legitimate concerns that you have to respect if you want to discuss changes to RFC3986. Making changes to an established standard without upsetting a deployed base is HARD! Which is why I try to suggest building on top of what exists. It may be that (e.g. for href values in HTML5) you need an identifier string that is not a URI (e.g. to allow non-ASCII characters in fragment identifiers). If that's what you need then they are not URIs as we currently know them, and they can no longer be fully interoperable with software that does work with URIs as defined by RFC3986. So what are the choices: 1. Change the definition of URI and screw the deployed base. Sometimes that is the right answer, but for a 10-year-old widely used standard I suspect this isn't one of those cases. 2. Change your spec/software to work within the constraints of that RFC3986 allows. It seems the community you're talking to has already dismissed this option, which is a choice for them to make. 3. Use something other than URIs. (IRIs, URLs, whatever. Let's call them BOBs.) If you want these BOBs to benefit from the deployed use of URIs, then you need to define a procedure for mapping BOBs to URIs, and software that uses BOBs in contexts that expect URIs will need to apply that mapping. > > So, I will continue to construct a new specification that describes a consistent > API behavior. But until and unless there can be a constructive discussion about > how to construct a specification in such a way that it builds upon RFC 3986, it > simply won't be built upon RFC 3986. Instead, it will likely have an appendix > that describes the differences between what it describes are what RFC 3986 > describes are. I guess it's ultimately a power struggle. Are the new applications that use BOBs more important to the world than all the old applications that use URIs? Maybe. (a) If so, you may be able to deploy BOBs and effectively cut off from the rest of the world who use URIs, or force them to upgrade to be part of your new world order. (b) But if the new BOB-using applications also need the features of the deployed systems who are disinclined to upgrade, then they will need to bend. > > That being said, I remain open to the idea of building upon RFC 3986. This can > happen one of two ways: > > 1) People proposing specific updates to the specification I am working on to > make this happen. > > 2) People being receptive and actively soliciting ways in which RFC 3986 could > be changed in order to make this layering possible. That sounds to me a lot like the options (1) and (a) above. It implies that the existing base of URI users have to engage with your solution or deal with bifurcation of resource locators in use on the Internet and the Web. To my mind, it's clearly *possible* to define consistent API behaviour that respects the URI syntax as described by RFC3986. But that may mean excluding some forms of identifier that are considered important by the community you're advocate for, such as unescaped UTF-8 characters in fragment identifiers. In a sense, I think you may be right, that this (the IETF) may be the wrong community for this discussion, as the biggest loser if bifurcation happens will be the Web community. Given the centrality of URIs to the Web, I think these options should be discussed by W3C TAG. #g -- From nobody Thu Jan 15 09:39:57 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0915A1B2F12 for ; Thu, 15 Jan 2015 09:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hMxYagfUF2Y for ; Thu, 15 Jan 2015 09:39:53 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.229]) by ietfa.amsl.com (Postfix) with ESMTP id DD7FB1B2F0F for ; Thu, 15 Jan 2015 09:39:51 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:62310] helo=rubix) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id B1/05-18452-76BF7B45; Thu, 15 Jan 2015 17:39:51 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id B1F041409A6; Thu, 15 Jan 2015 12:39:50 -0500 (EST) Message-ID: <54B7FB66.2070004@intertwingly.net> Date: Thu, 15 Jan 2015 12:39:50 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Graham Klyne , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7F9B8.6050900@ninebynine.org> In-Reply-To: <54B7F9B8.6050900@ninebynine.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 17:39:55 -0000 On 01/15/2015 12:32 PM, Graham Klyne wrote: > > In a sense, I think you may be right, that this (the IETF) may be the > wrong community for this discussion, as the biggest loser if bifurcation > happens will be the Web community. Given the centrality of URIs to the > Web, I think these options should be discussed by W3C TAG. FYI, I flew up to NY and met with the W3C TAG last week. I received only encouragement and constructive suggestions. Separate from that, I don't see bifurcation as a necessary outcome. It certainly isn't my first choice. > #g > -- - Sam Ruby From nobody Thu Jan 15 10:05:44 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC81D1B2E3A for ; Thu, 15 Jan 2015 10:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K40JvE8s8f1 for ; Thu, 15 Jan 2015 10:05:40 -0800 (PST) Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 57A911B2DBE for ; Thu, 15 Jan 2015 10:05:40 -0800 (PST) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YBonb-0002FF-ms; Thu, 15 Jan 2015 18:05:39 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YBona-0005pL-MY; Thu, 15 Jan 2015 18:05:39 +0000 Message-ID: <54B80172.2000308@ninebynine.org> Date: Thu, 15 Jan 2015 18:05:38 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7F9B8.6050900@ninebynine.org> <54B7FB66.2070004@intertwingly.net> In-Reply-To: <54B7FB66.2070004@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 18:05:43 -0000 On 15/01/2015 17:39, Sam Ruby wrote: > On 01/15/2015 12:32 PM, Graham Klyne wrote: >> >> In a sense, I think you may be right, that this (the IETF) may be the >> wrong community for this discussion, as the biggest loser if bifurcation >> happens will be the Web community. Given the centrality of URIs to the >> Web, I think these options should be discussed by W3C TAG. > > FYI, I flew up to NY and met with the W3C TAG last week. I received only > encouragement and constructive suggestions. Good! > Separate from that, I don't see bifurcation as a necessary outcome. It > certainly isn't my first choice. I guess the devil is in the details. If, for example, you want to introduce non-ASCII characters into URI fragments, I can't see how bifurcation can be avoided. How damaging that turns out to be is hard to say. I think a lot of the positioning around IRIs was primarily an attempt to avoid this while introducing localized identifiers. Which is what I was describing as BOBs in my previous message. But, as you say, far better we don't go down that path. I think that if we had a clear enumeration of areas where RFC3986 updates might be proposed, it would be an easier discussion to have. But as I said before, changing an existing standard with a deployed base is hard. #g -- From nobody Thu Jan 15 10:16:49 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69881B2F3A for ; Thu, 15 Jan 2015 10:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1d7COQt_9qa for ; Thu, 15 Jan 2015 10:16:36 -0800 (PST) Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id CE9B21B2FB7 for ; Thu, 15 Jan 2015 10:16:35 -0800 (PST) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YBoyB-0006JJ-mX; Thu, 15 Jan 2015 18:16:35 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YBoyA-00062W-M4; Thu, 15 Jan 2015 18:16:34 +0000 Message-ID: <54B80402.6040408@ninebynine.org> Date: Thu, 15 Jan 2015 18:16:34 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> In-Reply-To: <54B7AEC2.9010109@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 18:16:42 -0000 Much as I'd love to take a stab at this, I haven't used Haskell myself for a while and don't know if I have a working tool chain installed. Maybe if I stop reading and writing emails I might be able to find some time to have a look! I'm sure it wouldn't take too long to construct the framework you describe, once I have the basic tool chain up and running. But don't hold your breath! BTW, my implementation would almost certainly be found wanting in some of your behavioural consistency tests. #g -- On 15/01/2015 12:12, Sam Ruby wrote: >> (FWIW, I wrote an early RFC 3986 implementation that was absorbed into >> the Haskell libraries - >> http://hackage.haskell.org/package/network-2.1.0.0/docs/Network-URI.html >> - the API is not without its objectors, but I believe it conforms to the >> essentials of RFC3986 articulated above. I'm not sure if this is >> included in your test data.) > > It is not, but could be. Haskell isn't one of the languages that I happen to > know at the moment. I'm confident that I could quickly learn enough Haskell to > write the program I need to, but I think it would be a good learning experience > for somebody to take the first step. > > What I am looking for is a program that reads the following test data from a > file on disk: > > https://url.spec.whatwg.org/interop/urltestdata.json > > This program only needs to look at the "input" and "base" values. It needs to > parse the base, resolve the input against that base, and then extract the data > that would be produced if the following API were implemented: > > https://specs.webplatform.org/url/webspecs/develop/#api > > I realize that the latter is a lot to absorb, and perhaps a better way to > understand what the output should look like would be to look at results from > other implementations: > > https://github.com/webspecs/url/tree/develop/evaluate/useragent-results > > Doing this may mean that you need to implement some parts of the API in your > program instead of it being baked into the underlying implementation. That's > OK. Examples might include appending a ':' to a scheme to produce a protocol, > or splitting an authority into a username and password. > > I believe that if you would be willing to take a first stab at such a program, > we can explore whatever differences that exposes, and whether or not the > proposed API should change, and as a consequence, what the implications for RFC > 3986 would be. > > - Sam Ruby From nobody Thu Jan 15 10:21:58 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754B51B2FF7 for ; Thu, 15 Jan 2015 10:21:43 -0800 (PST) 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, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuzwLF9ANXqc for ; Thu, 15 Jan 2015 10:21:36 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::700]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFF761B2FF6 for ; Thu, 15 Jan 2015 10:21:35 -0800 (PST) Received: from pc6 (81.151.167.59) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.53.17; Thu, 15 Jan 2015 17:57:17 +0000 Message-ID: <02f101d030ec$8e721280$4001a8c0@gateway.2wire.net> From: t.petch To: Sam Ruby , Dave Cridland References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A557E1.6050502@intertwingly.net><54A94109.5010901@intertwingly.net><00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net><54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net><54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net><54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net><012001d02d91$6ec42300$4001a8c0@gateway.2wire.net><54B2781C.4040505@intertwingly.net><018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net><54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org><54B7AEC2.9010109@intertwingly.net><54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net> <54B7E00D.9040509@intertwingly.net> Date: Thu, 15 Jan 2015 17:56:08 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB3PR05CA0052.eurprd05.prod.outlook.com (25.160.41.180) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB3PR07MB060; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DB3PR07MB060; X-Forefront-PRVS: 0457F11EAF X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(189002)(24454002)(377454003)(199003)(479174004)(87976001)(101416001)(116806002)(50226001)(93886004)(19580405001)(84392001)(46102003)(19580395003)(81816999)(106356001)(105586002)(76176999)(86362001)(50986999)(81686999)(44736004)(23756003)(50466002)(92566002)(66066001)(40100003)(64706001)(47776003)(122386002)(62236002)(44716002)(97736003)(68736005)(42186005)(61296003)(77096005)(15975445007)(33646002)(14496001)(62966003)(77156002)(1456003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2015 17:57:17.0810 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060 Archived-At: Cc: Graham Klyne , apps-discuss Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 18:21:44 -0000 ----- Original Message ----- From: "Sam Ruby" To: "Dave Cridland" Cc: "Graham Klyne" ; Sent: Thursday, January 15, 2015 3:43 PM > On 01/15/2015 10:28 AM, Dave Cridland wrote: > > On 15 January 2015 at 15:10, Sam Ruby > > wrote: > > > > First, a general comment. Why does this list attract people whose > > first resource is to go to caricature and sarcasm? > > > > If that's a reference to me, my first recourse was to suggest you read > > the relevant specifications and keep to the same terminology as the > > technical literature. My second recourse was to to attempt to clarify > > your position, since you hadn't responded to the first. > > > > I only did sarcasm on the third try - I've not yet done caricature. > > > > Please, read the IRI spec, and the HTML5 spec, and then tell me why you > > think that IRIs are not *already* the solution. > > Excerpt from RFC 3986: > > query = *( pchar / "/" / "?" ) > pchar = unreserved / pct-encoded / sub-delims / ":" / "@" > unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" > pct-encoded = "%" HEXDIG HEXDIG > sub-delims = "!" / "$" / "&" / "'" / "(" / ")" > / "*" / "+" / "," / ";" / "=" > > Can you point out where in the IRI specification it says that '[' is a > valid character to include in a query? I do not think that it does (unless percent encoded). >From RFC3987 iquery = *( ipchar / iprivate / "/" / "?" ) ipchar = iunreserved / pct-encoded / sub-delims / ":" / "@" iunreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar ucschar = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF / %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD / %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD / %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD / %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD / %xD0000-DFFFD / %xE1000-EFFFD iprivate = %xE000-F8FF / %xF0000-FFFFD / %x100000-10FFFD where sub-delims is taken from RFC3986. If by [ and ] you mean x'5B' and x'5D', then they remain invalid in an IRI query. That said, [ and ] are interesting in that RFC3986, as updated by RFC6874, reserves them purely for IPv6 addresses, which I always saw as a statement that IPv6 was a work in progress whose ramifications were unknown (still true today). So for everyone has followed RFC3986, then relaxing the rules on [ and ] could just be a question of asking the v6ops and 6man IETF WGs if they saw problems in allowing them in a query or fragment. Of course, for those who have not followed RFC3986 and used them for other purposes, then it is a question of looking at all the hundreds of schemes based on RFC3986 and evaluating the impact of such a relaxation; or perhaps a question of saying that if you have not followed RFC3986, well you took a risk. Tom Petch > Julian has agreed[1] that "If an example of a problem I'm facing is that > escaping square brackets in query/search strings causes problems, I'm > not likely to find the solution to that problem in IRIs." > > > I don't mean "could be", at this stage I hold they already are, and that > > "URL parsers" are in fact IRI parsers, and this is what you want. > > I will claim that what exists as "URL parsers", and for that matter "URI > parses" are NOT IRI parsers. Nor are the URI parsers. What they parse > is neither a superset nor a subset of either URIs or IRIs. > > My goal is to work with authors of such parsers to remove as much as I > can from the right-most column of the following: > > https://url.spec.whatwg.org/interop/test-results/ > > If, in the process, I can come up with a definition that is either a > proper superset or a proper subset of an existing RFC, that would be great. > > > Dave. > > - Sam Ruby > > [1] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13782.html > > From nobody Thu Jan 15 10:28:02 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788061B2FCE for ; Thu, 15 Jan 2015 10:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PC1WSntJhnS1 for ; Thu, 15 Jan 2015 10:27:48 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.228]) by ietfa.amsl.com (Postfix) with ESMTP id C0D391B2FC3 for ; Thu, 15 Jan 2015 10:27:47 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:1505] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 4E/1E-28314-2A608B45; Thu, 15 Jan 2015 18:27:47 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id BFD071409A6; Thu, 15 Jan 2015 13:27:46 -0500 (EST) Message-ID: <54B806A2.8020803@intertwingly.net> Date: Thu, 15 Jan 2015 13:27:46 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Henry S. Thompson" References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 18:27:54 -0000 On 01/15/2015 12:19 PM, Henry S. Thompson wrote: > > Or [per private communication], if your the problem is not with the > error recovery as such, but rather with the current consensus position > that '[' and ']' are invalid in query in the first place, _that_ > becomes the point on which I'd like to hear what kind of arguments > have convinced you that, as between the following possible situations, > what you would prefer is option (3): > > [using 'I_URI' for URIs as defined in 3986, and 'W_URL' for URLs as > defined in [1]] > > 1) (the _status quo_): Square brackets are not valid in the query > part of I_URI or W_URL; [1] specifies non-%-encoded error recovery; > browsers differ; > > 2) (what I thought you wanted): Square brackets are not valid in the query > part of I_URI or W_URL; [1] specifies non-%-encoded error recovery; > browsers all implement non-%-encoded error recovery; > > 3) (what I now think you want): Square brackets are valid in the > query part of I_URI and W_URL, i.e. 3986 is superseded with an > appropriate change to the relevant productions and [1] is > modified to similar effect; no error-recovery is needed. Good question. Please forgive the lengthy answer. Lets posit the existence of a W_URL parser. Given a string, it produces an object. One of the operations that object performs is "stringification" (an IDL term that I don't particularly care for which essentially means serialization to a string form). - - - If you look at the sequence of operations: parse followed by stringification, you get a string transformation. This can be an identity transform. If you want, try the following in Firefox or Chrome's console: new URL('http://example.com/').href == 'http://example.com/' The result will be true. The result can be some transformation. For example: new URL('HTTP://EXAMPLE.COM/PATH').href == 'http://example.com/PATH' Finally, the result can be to give up. new URL('http://example.com:port/') Both Firefox and Chrome throw an exception. - - - Now if you take a look at that transformation, we can discuss the what should be desirable characteristics of the set of outputs. The first characteristic that I would like to suggest is that the outputs round trip, and by that I mean that if you feed that output back into the transformation, you get the same result back. The second characteristic is that it actually works. This isn't a precisely specified criteria, but it means that if you attempt to use the result it doesn't break anything. One example of this would be placing the string 'http://ietf.org/' into the href attribute of an HTML element, rendering it on the screen, and having somebody click on the link. If this goes to the right place, then all is good. The definition of "works" for data: W-URLs, and for javascript: W-URLs are different, but that's not an obstacle at this level of discussion. - - - At this point, I'm troubled. Despite the set of desirable characteristics I have specified, I have a well defined set which is neither a superset of I-URI's nor I-IRI's, nor a proper subset of either. An example of something that is not a conforming URL, but is both a valid URI and a valid IRI: http://257.257.257.257/ Here is something that round-trips a URL parse/stringify transformation, and actually works, despite being an invalid URI and invalid IRI: https://www.google.com/?q=[z] To further compound this, RFC 3986 claims that the following strings are to be treated as equivalent (and perhaps even preferred as they are deemed to be 'valid'): https://www.google.com/?q=%5Bz%5D https://www.google.com/?q=%5bz%5d Indeed in many, and generally most, situations, those are considered equivalent. But this is not necessarily so. To it's credit RFC 3986 does describe a Comparison Ladder. Unfortunately it does so using terms like "false positives" and "false negatives" when in fact, they aren't false at all. - - - So much for a deep dive. Returning to the surface: I'd like to simultaneously loosen up the definition of validity for I-URI's in some places while tightening it up in others. This is a work in progress, so which I can't say exactly where just yet in each case, I can say that now would be a good time for interested parties to participate. > ht - Sam Ruby > [1] https://url.spec.whatwg.org/, as of 2015-01-15 From nobody Thu Jan 15 11:19:54 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3510E1B3129 for ; Thu, 15 Jan 2015 11:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6slnF0KYA_Y for ; Thu, 15 Jan 2015 11:19:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DAE1B312A for ; Thu, 15 Jan 2015 11:19:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150115191947.19534.63067.idtracker@ietfa.amsl.com> Date: Thu, 15 Jan 2015 11:19:47 -0800 From: IETF Secretariat Archived-At: Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 19:19:51 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-multipart-form-data", resolved as "Done". Changed milestone "Publication requested for draft-ietf-appsawg-uri-scheme-reg", resolved as "Done". URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Thu Jan 15 11:23:36 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8691B3134 for ; Thu, 15 Jan 2015 11:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvfCzPBodm0M for ; Thu, 15 Jan 2015 11:23:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA5A1B313A for ; Thu, 15 Jan 2015 11:23:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150115192329.6204.62702.idtracker@ietfa.amsl.com> Date: Thu, 15 Jan 2015 11:23:29 -0800 From: IETF Secretariat Archived-At: Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 19:23:32 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-http-problem", set state to active from review, accepting new milestone. Changed milestone "Publication requested for draft-ietf-appsawg-file-scheme", set state to active from review, accepting new milestone. Changed milestone "Publication requested for draft-ietf-appsawg-mdn-3798bis", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Thu Jan 15 11:30:47 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10021B316A for ; Thu, 15 Jan 2015 11:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gj4GKzzMjsUu for ; Thu, 15 Jan 2015 11:30:39 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659E01B315B for ; Thu, 15 Jan 2015 11:30:39 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id l18so16893477wgh.0 for ; Thu, 15 Jan 2015 11:30:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4ugUuIxmZyIjsBX01sResAACfewmfdJpgRRqAV/JXlc=; b=TIAMZr6HBxZTa+VAcGZHERexWrfa3yRJMlco/LRRHTArnDnl7t3uTQDIr9Kum2xtev l9diFoKmi9YTimCFWMBeGsixLhBmeUudU9rF81Or1lPRQVgyJsS1GBRatU5xN/2pJdbX lhHoHRnzqw5BoW3KpiDpAqhyo+7RIubJ9XitTWq6XLdw8oruuvMJoN1dedRkiVa59InT MHv0Ew+TOnmxPJLlhYQn6pfgYAOHHyh0jgeXdld2wldQ2Z9NvdemhDQE0EhCZ1ZYSFwn /A3UoTmtZEbkgUoYXq8qybqtky1k3SJdXjjWAIEUB0a4JWaaizsGt/7YkL2hGEKshNEi jZGw== MIME-Version: 1.0 X-Received: by 10.180.75.199 with SMTP id e7mr64269175wiw.21.1421350231108; Thu, 15 Jan 2015 11:30:31 -0800 (PST) Received: by 10.27.204.198 with HTTP; Thu, 15 Jan 2015 11:30:30 -0800 (PST) In-Reply-To: <54B7E32A.9090800@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net> <54B7E32A.9090800@intertwingly.net> Date: Thu, 15 Jan 2015 11:30:30 -0800 Message-ID: From: "Murray S. Kucherawy" To: Sam Ruby Content-Type: multipart/alternative; boundary=f46d04389577a070f3050cb5e386 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 19:30:45 -0000 --f46d04389577a070f3050cb5e386 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 15, 2015 at 7:56 AM, Sam Ruby wrote: > I was told (perhaps bad advice?) that the first step would be to publish a > problem statement, which I have done: > > https://tools.ietf.org/id/draft-ruby-url-problem-01.txt > It's not bad advice. Drafts are roughly free. :-) I'd like to see some future revision of that document be accepted and > published as an RFC. > > And that the next step would be a BOF: > > http://www.ietf.org/meeting/important-dates-2015.html > > Based on what I see, and discussions I have held, I'd like to proceed as > outlined here: > If you're looking at doing a BoF, I think that aligns with what I was going to suggest: Given the current number of participants and especially the more passionate ones, I'm wondering if this shouldn't have a dedicated tightly-focused working group to house this work separately from apps-discuss (which is the home of both APPSAWG and the APP area general traffic). Have you thought of writing up a charter to define the work? Such a working group could include your problem statement draft as its first deliverable. I'm also curious to hear, and probably see in such a charter, why this work belongs in the IETF and not the W3C. I'm not making an argument for either, just don't have the history to understand that part of it. -MSK --f46d04389577a070f3050cb5e386 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 15, 2015 at 7:56 AM, Sam Ruby <rubys@int= ertwingly.net> wrote:
I was told (perhaps bad advice?) that the first step would be to publish a = problem statement, which I have done:

=C2=A0 https://tools.ietf.org/id/draft-ruby-url-problem-01.txt

I'd like to see some future revision of that document be accepted and p= ublished as an RFC.

And that the next step would be a BOF:

=C2=A0 http://www.ietf.org/meeting/important-dates-2015.htm= l

Based on what I see, and discussions I have held, I'd like to proceed a= s outlined here:

If you're looking = at doing a BoF, I think that aligns with what I was going to suggest:
Given the current number of participants and especially the mo= re passionate ones, I'm wondering if this shouldn't have a dedicate= d tightly-focused working group to house this work separately from apps-dis= cuss (which is the home of both APPSAWG and the APP area general traffic).= =C2=A0 Have you thought of writing up a charter to define the work?

=
Such a working group could include your problem statement draft = as its first deliverable.

I'm also curious= to hear, and probably see in such a charter, why this work belongs in the = IETF and not the W3C.=C2=A0 I'm not making an argument for either, just= don't have the history to understand that part of it.
-MSK
--f46d04389577a070f3050cb5e386-- From nobody Thu Jan 15 11:40:28 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6851B31BE for ; Thu, 15 Jan 2015 11:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyguFKHTBJKB for ; Thu, 15 Jan 2015 11:40:11 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D521B31BA for ; Thu, 15 Jan 2015 11:40:05 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id q59so16594221wes.8 for ; Thu, 15 Jan 2015 11:40:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ypboT5YxWhFamIDOeWdv671810MxfNNqaTL3gBqkR4U=; b=WrR7qvLxiW+Iak/Utyt2gTJb1GNEK7lVJMaibalWjD2t49rR+7mr1Bq2V6UKxZx/Re at/RGjZqAbgzlJP88gEc5YQe+pLbogLiLkTIo9jmT+eZb4trnkCCFi41i6yGpkfbnlSO bPMTQlmBQ1knFg9BsNY760/60Tt99K4nWuXL2X/N2uzd1FkJ/T3OFkBiHlxpgiKFjPgB 7PncmqMgEQVzeureL74mERmcjniPPjmtNIJhGZbLjOj7wtZAilb8Xk7P9zGaC941huR2 jiyyA0/kg20MkSuJd/UlkNf7UBRp+p032rmd3U7h6SISXjjnjbiHWt+JIjIGCpCzsLB8 wOdQ== MIME-Version: 1.0 X-Received: by 10.180.95.4 with SMTP id dg4mr16777033wib.61.1421350803992; Thu, 15 Jan 2015 11:40:03 -0800 (PST) Received: by 10.27.204.198 with HTTP; Thu, 15 Jan 2015 11:40:03 -0800 (PST) In-Reply-To: <54B7EC4D.9080603@seantek.com> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net> <54B7EC4D.9080603@seantek.com> Date: Thu, 15 Jan 2015 11:40:03 -0800 Message-ID: From: "Murray S. Kucherawy" To: Sean Leonard Content-Type: multipart/alternative; boundary=f46d0444028ec5f658050cb6055f Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 19:40:13 -0000 --f46d0444028ec5f658050cb6055f Content-Type: text/plain; charset=UTF-8 On Thu, Jan 15, 2015 at 8:35 AM, Sean Leonard wrote: > It seems that many folks have some heated opinions, probably related to > different backgrounds or technical experience on the matter. > > May I suggest that this topical area be included in a structured > discussion on the agenda at IETF 92, either in APPSAWG or another > appropriate forum, where the parties can be in one room and understand each > others' perspectives. > Thanks for the reminder: I need to make the general call for agenda items for the upcoming meeting. For this particular item, I'm concerned that there are several people (Sam in particular) participating on this topic that don't usually attend IETF meetings. Unless most or all of them will attend, I'm not sure that would be a good use of our usually-precious face time. I'm reasonably sure Sean and Julian will be there, but what about the rest? Otherwise, continuing to use the list to figure out a path forward here seems more appropriate. -MSK --f46d0444028ec5f658050cb6055f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 15, 2015 at 8:35 AM, Sean Leonard <dev+iet= f@seantek.com> wrote:
It seems that many folks h= ave some heated opinions, probably related to different backgrounds or tech= nical experience on the matter.

May I suggest that this topical area be included in a structured discussion= on the agenda at IETF 92, either in APPSAWG or another appropriate forum, = where the parties can be in one room and understand each others' perspe= ctives.

Thanks for the reminder: I need= to make the general call for agenda items for the upcoming meeting.
For this particular item, I'm concerned that there are seve= ral people (Sam in particular) participating on this topic that don't u= sually attend IETF meetings.=C2=A0 Unless most or all of them will attend, = I'm not sure that would be a good use of our usually-precious face time= .=C2=A0 I'm reasonably sure Sean and Julian will be there, but what abo= ut the rest?=C2=A0 Otherwise, continuing to use the list to figure out a pa= th forward here seems more appropriate.

-MSK
--f46d0444028ec5f658050cb6055f-- From nobody Thu Jan 15 11:53:49 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C47B1B32C2 for ; Thu, 15 Jan 2015 11:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVfOPLpcHinq for ; Thu, 15 Jan 2015 11:53:42 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 648231B3288 for ; Thu, 15 Jan 2015 11:52:18 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id y19so16932879wgg.3 for ; Thu, 15 Jan 2015 11:52:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=aqcGmWwxsSjSKdmgNz8XCmPZB4aXZasOo+EC8Nhgruw=; b=O5VCIfdAtnO5z1PNbiNO6cfsVdiw47ErDflW1FMkcWw3RxeRqpEaeiGZZOBkt6ORn9 5UQ9aveScYOetbN+1r6DRzx4LJ0GTdm2d1YfZwqmMlMGeQApUdsn9xuziTFlgO66MBFs 8IakKTU13DwbPhzW0Qmai7aP1IJXzg4HkO+RiYhqVkKgiI2BOVO9RrL6DbCRpWMJ/53O BWuEiaU4wKk8yBHKtDnS4K/0QotILUeuqP1WKlxbUd2MPudtkwpBQ5yk/Cvz2bLoEftY Y1A0TOWT0kshAxkTy1McZxAA7d1muELHShzFEB4uTwinlUJWaZKrJstBamSBsjZbW9C1 pvLA== MIME-Version: 1.0 X-Received: by 10.194.10.68 with SMTP id g4mr5746347wjb.5.1421351537197; Thu, 15 Jan 2015 11:52:17 -0800 (PST) Received: by 10.27.204.198 with HTTP; Thu, 15 Jan 2015 11:52:17 -0800 (PST) Date: Thu, 15 Jan 2015 11:52:17 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7b5d997f79c9c0050cb63115 Archived-At: Subject: [apps-discuss] IETF 92 Scheduling X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 19:53:44 -0000 --047d7b5d997f79c9c0050cb63115 Content-Type: text/plain; charset=UTF-8 Colleagues, We have requested our usual APPSAWG/APPAREA Monday morning 9:30 slot, with the usual conflict set, for the Dallas meeting. Please propose agenda items for this meeting in response to this thread. We'll have our usual updates from the co-chairs and ADs and will be inviting chairs of BoFs and newly formed working groups to give short presentations on what's happening during the week. If you are working on a document already in APPSAWG that requires face time to resolve some issues, or would like to make or request a presentation on a particular topic, please let us know as soon as possible. Our preliminary agenda is due to the Secretariat on Monday, March 9th, which is also the final date to be able to submit drafts to the datatracker before the meeting. We will generally only admit documents that have already been introduced to on this list. The in-person meetings are not appropriate places to propose brand new work items. Please email appsawg-chairs@tools.ietf.org if you have any questions. -MSK, APPSAWG co-chair --047d7b5d997f79c9c0050cb63115 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

We have requested = our usual=20 APPSAWG/APPAREA Monday morning 9:30 slot, with the usual conflict set, for = the Dallas meeting.

Please propose agenda items for this=20 meeting in response to this thread.=C2=A0 We'll have our usual updates = from=20 the co-chairs and ADs and will be inviting chairs of BoFs and newly=20 formed working groups to give short presentations on what's happening= =20 during the week.

If you are working on a document already in APPSAWG that requires face = time=20 to resolve some issues, or would like to make or request a presentation=20 on a particular topic, please let us know as soon as possible.=C2=A0 Our pr= eliminary agenda is due to the Secretariat on Monday, March 9th, which is also the=20 final date to be able to submit drafts to the datatracker before the=20 meeting.

We will generally only admit documents that have= already been introduced to on this list.=C2=A0 The in-person meetings are = not appropriate places to propose brand new work items.

P= lease email appsawg-chairs= @tools.ietf.org if you have any questions.

-MSK, APPSAWG co-chair
--047d7b5d997f79c9c0050cb63115-- From nobody Thu Jan 15 13:23:41 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728A71B29C8 for ; Thu, 15 Jan 2015 13:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUwiBvX5rgrL for ; Thu, 15 Jan 2015 13:23:37 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.227]) by ietfa.amsl.com (Postfix) with ESMTP id C8D9B1AD358 for ; Thu, 15 Jan 2015 13:23:36 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:23461] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 16/A3-28314-8DF28B45; Thu, 15 Jan 2015 21:23:36 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 0ECE11409A6; Thu, 15 Jan 2015 16:23:35 -0500 (EST) Message-ID: <54B82FD7.9060208@intertwingly.net> Date: Thu, 15 Jan 2015 16:23:35 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net> <54B7E32A.9090800@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 21:23:40 -0000 On 01/15/2015 02:30 PM, Murray S. Kucherawy wrote: > On Thu, Jan 15, 2015 at 7:56 AM, Sam Ruby > wrote: > > I was told (perhaps bad advice?) that the first step would be to > publish a problem statement, which I have done: > > https://tools.ietf.org/id/draft-ruby-url-problem-01.txt > > It's not bad advice. Drafts are roughly free. :-) Indeed :-) > I'd like to see some future revision of that document be accepted > and published as an RFC. > > And that the next step would be a BOF: > > http://www.ietf.org/meeting/__important-dates-2015.html > > > Based on what I see, and discussions I have held, I'd like to > proceed as outlined here: > > If you're looking at doing a BoF, I think that aligns with what I was > going to suggest: To be clear: I'm perfectly willing to do a BoF, but it is unclear to me what it would accomplish. > Given the current number of participants and especially the more > passionate ones, I'm wondering if this shouldn't have a dedicated > tightly-focused working group to house this work separately from > apps-discuss (which is the home of both APPSAWG and the APP area general > traffic). Have you thought of writing up a charter to define the work? I do believe that a WG is in order. See related discussion at the bottom of the following: https://lists.w3.org/Archives/Public/public-ietf-w3c/2014Dec/0088.html Is there a how-to for writing an IETF charter? Trust me, there isn't any suggestion that I won't aggressively follow up on, so if you want me to write up a charter and attend a BoF, not a problem. > Such a working group could include your problem statement draft as its > first deliverable. That works for me. > I'm also curious to hear, and probably see in such a charter, why this > work belongs in the IETF and not the W3C. I'm not making an argument > for either, just don't have the history to understand that part of it. I'm venue agnostic. In fact, I have already written up a draft W3C Charter: http://rawgit.com/webspecs/url/develop/docs/url-charter.html If we could get the interested parties here to join that WG, that would be great. One obstacle is that the W3C Invited Expert agreement as currently written would prevent IETF participants from making use of their own work in IETF drafts. I'm working to change that. That being said, I think that if the W3C were to embark on defining a concept that overlaps with URIs but it not either a proper superset or a proper subset of that concept, then it would be best if we were to find a way for the IETF to endorse such. Not knowing how to make that happen, I would suggest a division of labor. Roughly thus: 1) Have the W3C take responsibility for what once was IRIs, but will be known as URLs. Ideally the IETF would license or assign copyright for RFC 3987 in such a way that much of it could be reused. This WG would also document a parsing API. One constraint would be that all outputs produced are valid URIs. 2) Have the IETF charter a WG with responsibility for creating an RFC 3986bis. It would be responsible for updating the nomenclature for aligning with the new (and, in some sense, original) definition for the term URL. The intent would also be to update the definition of the term URI to align with the validity constraints defined in conjunction with the W3C. I don't work for a browser vendor, but my expectation is that browser vendors would have an interest in seeing everything that they produce for http: and https: be considered valid. If anything that they produce is a problem, then lets discuss it. If it isn't a problem and isn't currently defined as valid by RFC 3986, then that should be changed. As for schemes other than http and https, browser vendors aren't likely to feel as strongly, so if there is a better definition then they I don't expect much of a problem. The one exception is file:, and a part of this discussion should be whether this hypothetical new WG would assume responsibility for what now is draft-ietf-appsawg-file-scheme. My proposal would be that it is assigned this responsibility. > -MSK - Sam Ruby From nobody Thu Jan 15 14:09:24 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490EC1A897B for ; Thu, 15 Jan 2015 14:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id km5foqyqx40G for ; Thu, 15 Jan 2015 14:09:19 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D30A1A1B91 for ; Thu, 15 Jan 2015 14:09:19 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id nt9so15987166obb.10 for ; Thu, 15 Jan 2015 14:09:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0XVzUrZGn1wquJk+Frx0xse9SLMz85sddsiXVtje3rs=; b=j5u/CnJ5WBJSU5WotlJVwKnu+sxx767WUHD2imiav0KV6mxZSjUUUJGxufVpeI02RK O1VOiFhsQY5JS65TNk3F7y0zVOsA4dHwcl/FQeuxM0CPxnpLJ+GBn7q9HQ3i16H7Cni1 xI4fCA9L8MeEGtMkGuPu3KI0ePwBQL6g+15+I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0XVzUrZGn1wquJk+Frx0xse9SLMz85sddsiXVtje3rs=; b=k80hH0E5fFJzuJ8qHHAsOaplVotNK7eaHldviUwP+AvqV8y3Pw7mAfdUybVZ+vakzh 92bChwfQvXFJcXNMvzYjSyHx2b3t5LYeEeXpgclAAEnh3cQRn4SQwNgkP3MXa+qjVs2b 1AcKiwu65gX5feJs/LAEAUT9u5RsYI9Wqh388ztJhPli8Ikl/n5j7f6alBc4AQl6zvtd RBXisWf7z+cLGkhd6xcWFpOnMDz2sI14OzzUfpwIcu6ifej8nrPuEol5YiR5FHvzqMHF ay5JevlTZ9DPXUZWoBpf+xYn0niGuc5WHMCO0cfN45QH614VFj7C+kApLYNDi12Ubkb+ xWtw== X-Gm-Message-State: ALoCoQkuzYo9wvAV3OwQzpH73yk3q8Ctr0n6PieUF/s6Pj/Q2zzgyuERlelhTuTxl2P6lrk41CU5 MIME-Version: 1.0 X-Received: by 10.182.153.39 with SMTP id vd7mr7488783obb.78.1421359758600; Thu, 15 Jan 2015 14:09:18 -0800 (PST) Received: by 10.60.84.171 with HTTP; Thu, 15 Jan 2015 14:09:18 -0800 (PST) In-Reply-To: <54B806A2.8020803@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B806A2.8020803@intertwingly.net> Date: Thu, 15 Jan 2015 22:09:18 +0000 Message-ID: From: Dave Cridland To: Sam Ruby Content-Type: multipart/alternative; boundary=089e013a01e68281a1050cb81b86 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 22:09:22 -0000 --089e013a01e68281a1050cb81b86 Content-Type: text/plain; charset=UTF-8 On 15 January 2015 at 18:27, Sam Ruby wrote: > Good question. Please forgive the lengthy answer. > > Lengthy is fine. > Lets posit the existence of a W_URL parser. Given a string, it produces > an object. One of the operations that object performs is "stringification" > (an IDL term that I don't particularly care for which essentially means > serialization to a string form). > > - - - > > If you look at the sequence of operations: parse followed by > stringification, you get a string transformation. > > This can be an identity transform. If you want, try the following in > Firefox or Chrome's console: > > new URL('http://example.com/').href == 'http://example.com/' > > The result will be true. > > The result can be some transformation. For example: > > new URL('HTTP://EXAMPLE.COM/PATH').href == 'http://example.com/PATH' > > Finally, the result can be to give up. > > new URL('http://example.com:port/') > > Both Firefox and Chrome throw an exception. > > - - - > > Now if you take a look at that transformation, we can discuss the what > should be desirable characteristics of the set of outputs. > > The first characteristic that I would like to suggest is that the outputs > round trip, and by that I mean that if you feed that output back into the > transformation, you get the same result back. > > OK; you're saying that for any URL string S, new URL(new URL(S).href).href == new URL(S).href Your tests seem to imply that for any URL string S, there is one and only one correct value of (new URL(S).href); is that also the case? To put it another way, your tests imply a canonical form for a URI, and that seems much more useful. > The second characteristic is that it actually works. This isn't a > precisely specified criteria, but it means that if you attempt to use the > result it doesn't break anything. One example of this would be placing the > string 'http://ietf.org/' into the href attribute of an HTML element, > rendering it on the screen, and having somebody click on the link. If this > goes to the right place, then all is good. The definition of "works" for > data: W-URLs, and for javascript: W-URLs are different, but that's not an > obstacle at this level of discussion. > > I can readily appreciate the sentiment here; like many things, it's hard to specify. But what you're saying is that for any URL string S, where (new URL(S).href) does not produce an error, the result must be a semantically valid URL string? (i'm being delightfully wooly about "semantically valid"). > - - - > > At this point, I'm troubled. Despite the set of desirable characteristics > I have specified, I have a well defined set which is neither a superset of > I-URI's nor I-IRI's, nor a proper subset of either. > > An example of something that is not a conforming URL, but is both a valid > URI and a valid IRI: > > http://257.257.257.257/ > > OK... I don't think that's valid, but it's probably valid according to the ABNF only (ignoring the prose). I think specifying that in the formal syntax would be uncontentious - in fact, draft-ietf-iri-3987bis-13 already makes this change. Similarly, http://127.0.0.1:65536/ is also not valid, but because the concept of port is not tied to a specific transport protocol, and might not be restricted to a 16-bit range, that's a harder one to capture in pure ABNF - that is, the permissable values of port are arguably scheme specific. Both these are issues of what I called semantic validity above. Others probably exist. > Here is something that round-trips a URL parse/stringify transformation, > and actually works, despite being an invalid URI and invalid IRI: > > https://www.google.com/?q=[z] > > My gut feeling is that allowing this to be valid is a possible change, as I've said. I appreciate this is at odds with RFC 3986, but if URL parsers do generally ignore the error that's fine. > To further compound this, RFC 3986 claims that the following strings are > to be treated as equivalent (and perhaps even preferred as they are deemed > to be 'valid'): > > https://www.google.com/?q=%5Bz%5D > https://www.google.com/?q=%5bz%5d > > Indeed in many, and generally most, situations, those are considered > equivalent. But this is not necessarily so. To it's credit RFC 3986 does > describe a Comparison Ladder. Unfortunately it does so using terms like > "false positives" and "false negatives" when in fact, they aren't false at > all. > > I think that this would disappear, largely, with a canonical form. RFC 3986 currently says that pct-encoded should use upper case - that's a lower case "should" - and if we take this to be a canonical form, then the latter canonicalizes to the former, and we win. Of course, if [] is made legal in the query string it'd canonicalize to the previous example. Comparison of URIs then become a case of comparing the canonicalized versions of both. This is problematic in the case of ports - since http://www.google.com:80/ and http://www.google.com/ both refer to the same thing, but to have a single canonical form for both would require the parser to be aware of the default port for the scheme. But maybe unknown schemes cannot be canonicalized, or maybe we have two canonical forms. (Scheme-aware and scheme-agnostic; obviously you'd specify which you want and where). > - - - > > So much for a deep dive. Returning to the surface: I'd like to > simultaneously loosen up the definition of validity for I-URI's in some > places while tightening it up in others. This is a work in progress, so > which I can't say exactly where just yet in each case, I can say that now > would be a good time for interested parties to participate. > > ht >> > > - Sam Ruby > > [1] https://url.spec.whatwg.org/, as of 2015-01-15 >> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e013a01e68281a1050cb81b86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 5 January 2015 at 18:27, Sam Ruby <rubys@intertwingly.net> wrote:
Good question.=C2=A0 Please forgive the leng= thy answer.


Lengthy is fine.
=C2=A0
Lets posit the existence of a W_URL parser.=C2=A0 Given a string, it produc= es an object.=C2=A0 One of the operations that object performs is "str= ingification" (an IDL term that I don't particularly care for whic= h essentially means serialization to a string form).

=C2=A0- - -

If you look at the sequence of operations: parse followed by stringificatio= n, you get a string transformation.

This can be an identity transform.=C2=A0 If you want, try the following in = Firefox or Chrome's console:

=C2=A0 new URL('http://example.com/').href =3D=3D 'http://example.com/'

The result will be true.

The result can be some transformation.=C2=A0 For example:

=C2=A0 new URL('HTTP://EXAMPLE.COM/PATH').href =3D=3D 'http://example.com/PATH'

Finally, the result can be to give up.

=C2=A0 new URL('http://example.com:port/')

Both Firefox and Chrome throw an exception.

=C2=A0- - -

Now if you take a look at that transformation, we can discuss the what shou= ld be desirable characteristics of the set of outputs.

The first characteristic that I would like to suggest is that the outputs r= ound trip, and by that I mean that if you feed that output back into the tr= ansformation, you get the same result back.



<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> The second characteristic is that it actually works.=C2=A0 This isn't a= precisely specified criteria, but it means that if you attempt to use the = result it doesn't break anything.=C2=A0 One example of this would be pl= acing the string 'http:/= /ietf.org/' into the href attribute of an HTML <a> element, r= endering it on the screen, and having somebody click on the link.=C2=A0 If = this goes to the right place, then all is good.=C2=A0 The definition of &qu= ot;works" for data: W-URLs, and for javascript: W-URLs are different, = but that's not an obstacle at this level of discussion.


I can readily appreciate the sentiment= here; like many things, it's hard to specify. But what you're sayi= ng is that for any URL string S, where (new URL(S).href) does not produce a= n error, the result must be a semantically valid URL string? (i'm being= delightfully wooly about "semantically valid").
=C2=A0=
=C2=A0- - -

At this point, I'm troubled.=C2=A0 Despite the set of desirable charact= eristics I have specified, I have a well defined set which is neither a sup= erset of I-URI's nor I-IRI's, nor a proper subset of either.

An example of something that is not a conforming URL, but is both a valid U= RI and a valid IRI:

=C2=A0 http://257.257= .257.257/


OK... I don't think that's val= id, but it's probably valid according to the ABNF only (ignoring the pr= ose). I think specifying that in the formal syntax would be uncontentious -= in fact,=C2=A0draft-ietf-iri-3987bis-13 already makes this change.

Similarly, http://127= .0.0.1:65536/ is also not valid, but because the concept of port is not= tied to a specific transport protocol, and might not be restricted to a 16= -bit range, that's a harder one to capture in pure ABNF - that is, the = permissable values of port are arguably scheme specific.

Both these are issues of what I called semantic validity above. Othe= rs probably exist.
=C2=A0
Here is something that round-trips a URL parse/stringify transformation, an= d actually works, despite being an invalid URI and invalid IRI:

=C2=A0 https:= //www.google.com/?q=3D[z]


My gut feeling is that allowing this t= o be valid is a possible change, as I've said. I appreciate this is at = odds with RFC 3986, but if URL parsers do generally ignore the error that&#= 39;s fine.
=C2=A0
To further compound this, RFC 3986 claims that the following strings are to= be treated as equivalent (and perhaps even preferred as they are deemed to= be 'valid'):

=C2=A0 ht= tps://www.google.com/?q=3D%5Bz%5D
=C2=A0 ht= tps://www.google.com/?q=3D%5bz%5d

Indeed in many, and generally most, situations, those are considered equiva= lent.=C2=A0 But this is not necessarily so.=C2=A0 To it's credit RFC 39= 86 does describe a Comparison Ladder.=C2=A0 Unfortunately it does so using = terms like "false positives" and "false negatives" when= in fact, they aren't false at all.


I think that this would disappear, lar= gely, with a canonical form. RFC 3986 currently says that pct-encoded shoul= d use upper case - that's a lower case "should" - and if we t= ake this to be a canonical form, then the latter canonicalizes to the forme= r, and we win. Of course, if [] is made legal in the query string it'd = canonicalize to the previous example.

Comparison o= f URIs then become a case of comparing the canonicalized versions of both.<= /div>

This is problematic in the case of ports - since <= a href=3D"http://www.google.com:80/">http://www.google.com:80/ and http://www.google.com/ both refer to the= same thing, but to have a single canonical form for both would require the= parser to be aware of the default port for the scheme. But maybe unknown s= chemes cannot be canonicalized, or maybe we have two canonical forms. (Sche= me-aware and scheme-agnostic; obviously you'd specify which you want an= d where).
=C2=A0
=C2=A0- - -

So much for a deep dive.=C2=A0 Returning to the surface: I'd like to si= multaneously loosen up the definition of validity for I-URI's in some p= laces while tightening it up in others.=C2=A0 This is a work in progress, s= o which I can't say exactly where just yet in each case, I can say that= now would be a good time for interested parties to participate.

ht

- Sam Ruby

[1] https://url.= spec.whatwg.org/, as of 2015-01-15

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

--089e013a01e68281a1050cb81b86-- From nobody Thu Jan 15 14:55:24 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839E11A908D for ; Thu, 15 Jan 2015 14:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRhGvG_EZm2Q for ; Thu, 15 Jan 2015 14:55:08 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.225]) by ietfa.amsl.com (Postfix) with ESMTP id C80361A8998 for ; Thu, 15 Jan 2015 14:55:07 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:32175] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id BE/4B-28314-B4548B45; Thu, 15 Jan 2015 22:55:07 +0000 Received: from [192.168.1.115] (unknown [192.168.1.115]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id DAAEE1409A6; Thu, 15 Jan 2015 17:55:06 -0500 (EST) Message-ID: <54B8454A.7050001@intertwingly.net> Date: Thu, 15 Jan 2015 17:55:06 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Dave Cridland References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B806A2.8020803@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 22:55:15 -0000 First: thanks! This is exactly the discussion I've been hoping to have! More below. On 01/15/2015 05:09 PM, Dave Cridland wrote: > On 15 January 2015 at 18:27, Sam Ruby > wrote: > > Good question. Please forgive the lengthy answer. > > Lengthy is fine. > > Lets posit the existence of a W_URL parser. Given a string, it > produces an object. One of the operations that object performs is > "stringification" (an IDL term that I don't particularly care for > which essentially means serialization to a string form). > > - - - > > If you look at the sequence of operations: parse followed by > stringification, you get a string transformation. > > This can be an identity transform. If you want, try the following > in Firefox or Chrome's console: > > new URL('http://example.com/').__href > == 'http://example.com/' > > The result will be true. > > The result can be some transformation. For example: > > new URL('HTTP://EXAMPLE.COM/PATH')__.href > == 'http://example.com/PATH' > > Finally, the result can be to give up. > > new URL('http://example.com:port/'__) > > Both Firefox and Chrome throw an exception. > > - - - > > Now if you take a look at that transformation, we can discuss the > what should be desirable characteristics of the set of outputs. > > The first characteristic that I would like to suggest is that the > outputs round trip, and by that I mean that if you feed that output > back into the transformation, you get the same result back. > > > OK; you're saying that for any URL string S, new URL(new > URL(S).href).href == new URL(S).href Yes. > Your tests seem to imply that for any URL string S, there is one and > only one correct value of (new URL(S).href); is that also the case? That is indeed the current design point. I will share that there is some sentiment (not universally shared) to make parts of the file: scheme to be implementation defined. > To put it another way, your tests imply a canonical form for a URI, and > that seems much more useful. Indeed! I will note that I've intentionally shied away from using that term as some people already have ideas on what canonicalization means. In fact, until I started looking at this data, I too had different ideas. > The second characteristic is that it actually works. This isn't a > precisely specified criteria, but it means that if you attempt to > use the result it doesn't break anything. One example of this would > be placing the string 'http://ietf.org/' into the href attribute of > an HTML element, rendering it on the screen, and having somebody > click on the link. If this goes to the right place, then all is > good. The definition of "works" for data: W-URLs, and for > javascript: W-URLs are different, but that's not an obstacle at this > level of discussion. > > > I can readily appreciate the sentiment here; like many things, it's hard > to specify. But what you're saying is that for any URL string S, where > (new URL(S).href) does not produce an error, the result must be a > semantically valid URL string? (i'm being delightfully wooly about > "semantically valid"). That's indeed what I am trying to say. To get to that point, however requires wide review. If people can demonstrate that any given result is widely problematic (for some definition of "wide"), then it would make sense to adjust the parsing algorithm to avoid such values. An example to illustrate: non-ASCII host names are a problem. IDNA (including such things as punycode) is a strategy for converting Unicode host names to ASCII. > - - - > > At this point, I'm troubled. Despite the set of desirable > characteristics I have specified, I have a well defined set which is > neither a superset of I-URI's nor I-IRI's, nor a proper subset of > either. > > An example of something that is not a conforming URL, but is both a > valid URI and a valid IRI: > > http://257.257.257.257/ > > OK... I don't think that's valid, but it's probably valid according to > the ABNF only (ignoring the prose). I think specifying that in the > formal syntax would be uncontentious - in > fact, draft-ietf-iri-3987bis-13 already makes this change. Is is indeed valid (this was discussed recently on this very list). I would hope that it is uncontentious. > Similarly, http://127.0.0.1:65536/ is also not valid, but because the > concept of port is not tied to a specific transport protocol, and might > not be restricted to a 16-bit range, that's a harder one to capture in > pure ABNF - that is, the permissable values of port are arguably scheme > specific. I agree. I'm OK with not being able to express all of the conditions with pure ABNF. It is the round-tripping and other properties that matter to me. As an aside, my current draft considers the above valid, but there is an open bug on it. The problem isn't deciding that such is invalid, the problem is deciding how to canonicalize it. Looking just at four browsers, we have four different results: https://url.spec.whatwg.org/interop/test-results/c6c0953a53?select=current If you expand this to include non-browsers, most don't have a problem with such values: https://url.spec.whatwg.org/interop/test-results/c6c0953a53 > Both these are issues of what I called semantic validity above. Others > probably exist. Indeed. Here are a few examples that are worth discussing: https://url.spec.whatwg.org/interop/test-results/ > Here is something that round-trips a URL parse/stringify > transformation, and actually works, despite being an invalid URI and > invalid IRI: > > https://www.google.com/?q=[z] > > My gut feeling is that allowing this to be valid is a possible change, > as I've said. I appreciate this is at odds with RFC 3986, but if URL > parsers do generally ignore the error that's fine. Thanks! > To further compound this, RFC 3986 claims that the following strings > are to be treated as equivalent (and perhaps even preferred as they > are deemed to be 'valid'): > > https://www.google.com/?q=%__5Bz%5D > https://www.google.com/?q=%__5bz%5d > > Indeed in many, and generally most, situations, those are considered > equivalent. But this is not necessarily so. To it's credit RFC > 3986 does describe a Comparison Ladder. Unfortunately it does so > using terms like "false positives" and "false negatives" when in > fact, they aren't false at all. > > I think that this would disappear, largely, with a canonical form. RFC > 3986 currently says that pct-encoded should use upper case - that's a > lower case "should" - and if we take this to be a canonical form, then > the latter canonicalizes to the former, and we win. Of course, if [] is > made legal in the query string it'd canonicalize to the previous example. The sweet spot that parsers seem to be converging on: If the input isn't percent encoded and needs to be, replace the characters in question with the uppercase percent encoded form. If the input is already percent encoded, leave it as is, even if it includes lowercase characters. If I were designing things from scratch, I certainly wouldn't have proposed such a thing, but if that's what parsers do, then documenting that so that everybody can converge on a single and predictable behavior would be a big win. > Comparison of URIs then become a case of comparing the canonicalized > versions of both. Other than recognizing that there is history here and some processors compare URIs in different manners > This is problematic in the case of ports - since > http://www.google.com:80/ and http://www.google.com/ both refer to the > same thing, but to have a single canonical form for both would require > the parser to be aware of the default port for the scheme. But maybe > unknown schemes cannot be canonicalized, or maybe we have two canonical > forms. (Scheme-aware and scheme-agnostic; obviously you'd specify which > you want and where). The current draft does specify the default port for a precious few schemes, and requires the port-less string form when default ports are used. One strategy would be to adjust the registration process to not allow new schemes to be registered with default ports. Another would be to version the specification so that new schemes with default ports would require a revision of the parsing algorithm. I would hope that this would be a relatively rare event. Again, thanks for taking the time to review and comment on this! > - - - > > So much for a deep dive. Returning to the surface: I'd like to > simultaneously loosen up the definition of validity for I-URI's in > some places while tightening it up in others. This is a work in > progress, so which I can't say exactly where just yet in each case, > I can say that now would be a good time for interested parties to > participate. > > ht > > > - Sam Ruby > > [1] https://url.spec.whatwg.org/, as of 2015-01-15 > > > _________________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/__listinfo/apps-discuss > - Sam Ruby From nobody Thu Jan 15 15:31:12 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7711A909E for ; Thu, 15 Jan 2015 15:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OChw1FDjNs53 for ; Thu, 15 Jan 2015 15:31:08 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0622.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::622]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3639C1A9096 for ; Thu, 15 Jan 2015 15:31:04 -0800 (PST) Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) with Microsoft SMTP Server (TLS) id 15.1.53.17; Thu, 15 Jan 2015 23:30:40 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) by DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) with mapi id 15.01.0053.000; Thu, 15 Jan 2015 23:30:40 +0000 From: Larry Masinter To: Sam Ruby , "Murray S. Kucherawy" Thread-Topic: [apps-discuss] Scope of RFC3986 and successor - what is a URI? Thread-Index: AQHQMK/BbmNYRMhSwEGw8Ys6JgInPJzBF8kAgAAGVICAAAr/AIAAG5asgAAEooCAAAkQgIAAA94AgAA70ACAAB+YgIAAFYKQ Date: Thu, 15 Jan 2015 23:30:40 +0000 Message-ID: References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net> <54B7E32A.9090800@intertwingly.net> <54B82FD7.9060208@intertwingly.net> In-Reply-To: <54B82FD7.9060208@intertwingly.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:9:8380:992:ec21:132e:caaf:6bd0] authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DM2PR0201MB0960; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB0960; x-forefront-prvs: 0457F11EAF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(497574002)(199003)(101416001)(50986999)(54606007)(64706001)(54356999)(15975445007)(102836002)(2950100001)(68736005)(2900100001)(76176999)(93886004)(46102003)(19580405001)(19580395003)(76576001)(106116001)(54206007)(106356001)(62966003)(92566002)(77156002)(2656002)(87936001)(33656002)(40100003)(99286002)(86362001)(122556002)(74316001)(97736003)(105586002)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0960; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2015 23:30:40.3344 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB0960 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2015 23:31:10 -0000 KzEgQk9GIGF0IG5leHQgSUVURiwgd2hldGhlciBvciBub3QgaXQgbGVhZHMgdG8gYSB3b3JraW5n IGdyb3VwLiAgDQoNClByb3Bvc2VkIEFnZW5kYTogd2FsayB0aHJvdWdoIGRyYWZ0LXJ1YnktdXJs LXByb2JsZW0gKEkgdm9sdW50ZWVyKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgYmFzZWQgb24gdGhhdCwgZGlzY3VzcyBuZXh0IHN0ZXBzLg0KDQpJZiBhIHdvcmtpbmcgZ3Jv dXAgaXMgd2FudGVkLCBwcm9wb3NlZCBjaGFydGVyIG1pbGVzdG9uZToNCiANCiogZmluaXNoIGRy YWZ0LXJ1YnktdXJsLXByb2JsZW0gKHByb2JsZW0gc3RhdGVtZW50IGFncmVlZCBvciBjb250cm92 ZXJzaWVzIGlkZW50aWZpZWQsIHByb3Bvc2VkIHBsYW5zIGNvbmNyZXRlIG9yIGhhdmUgY29uY3Jl dGUgb3B0aW9ucyksIHB1Ymxpc2ggYXMgUkZDLg0KKiBUaGVuIHJlY2hhcnRlciBvciBjbG9zZSAo d2l0aGluIDQgbW9udGhzKQ0KDQpJZiB5b3UgYWdyZWUsIGl0IHdvdWxkIGhlbHAgZm9jdXMgdGhl IGRpc2N1c3Npb24gaWYgY29tbWVudHMgd2VyZSBjb3VjaGVkIGluIHRlcm1zIG9mIGNoYW5nZXMg dG8gZHJhZnQtcnVieS11cmwtcHJvYmxlbS4NCkZvciBleGFtcGxlLCBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtcnVieS11cmwtcHJvYmxlbS0wMSNzZWN0aW9uLTUuMiAgZG9lcyBu b3RlIHNvbWUga2luZHMgb2YgdGhpbmdzIGFuIHVwZGF0ZSB0byAzOTg2IG1pZ2h0IGFjY29tcGxp c2gsIGJ1dCBkb2Vzbid0IHN1Z2dlc3QgY2hhbmdpbmcgZnJhZ21lbnQgaWRlbnRpZmllciByZXBl cnRvaXJlLCBhcyBTYW0gc3VnZ2VzdGVkIGluIGVtYWlsLg0KDQpJZiB5b3Ugd2FudCBhIG1haWxp bmcgbGlzdCBvdGhlciB0aGFuIGFwcHN3ZywgZWl0aGVyIGEgbmV3IG9uZSBvciBhbiBvbGQgb25l OyBvZiB0aGUgZXhpc3RpbmcgbWFpbGluZyBsaXN0cywgSSBzdWdnZXN0IHVyaUB3My5vcmcgaXMg dGhlIGNsb3Nlc3QgaW4gc2NvcGUuDQoNCkknbSBpbiBmYXZvciBvZiBjaGFydGVyaW5nIGFuZCBt YW5hZ2luZyB0aGUgd29yayBpbiBJRVRGIGFuZCBub3QgaW4gVzNDIGJhc2VkIG9uIHdoZXJlIHRo ZSBzcGVjcyB3b3VsZCBnZXQgYWRlcXVhdGUgcmV2aWV3Lg0KKiBVUklzL1VSTHMsIGFsdGhvdWdo IGludmVudGVkIGZvciB0aGUgd2ViLCBhcmUgbm93IHdvdmVuIGludG8gbWFueSBvdGhlciBJRVRG IHByb3RvY29scyBhbmQgZGF0YSBzdHJ1Y3R1cmVzIHRoYW4gdGhlIHdlYiwgYW5kIHRob3NlIGFy ZSBtYWlubHkgb3V0IG9mIHNjb3BlIGZvciBXM0MvV0hBVFdHIHByaW9yaXRpZXMuDQoqIGl0IHNl ZW1zIGVhc2llciB0byBnZXQgYnJvYWRlciByZXZpZXcgaW4gSUVURi4gIEkgc2F5IHRoaXMgZGVz cGl0ZSB0aGUgcGFzdCBmYWlsdXJlIHRvIGdldCBXM0MvV0hBVFdHIHBhcnRpY2lwYXRpb24gaW4g dGhlIElSSSB3b3JraW5nIGdyb3VwLCBiZWNhdXNlIHdlIG5vdyBoYXZlIHJlYWwgZGF0YSBhYm91 dCBicm93c2VyIGJlaGF2aW9yICBhbmQgdGhlIG5ldyBwb3NzaWJpbGl0eSBvZiBnZXR0aW5nIGJy b3dzZXIgcGFydGljaXBhdGlvbiBpbiB0aGUgZGlzY3Vzc2lvbi4gDQoNCkNvbW1pdG1lbnRzIG9m IHBhcnRpY2lwYXRpb24gKGZyb20gVzNDIG1hbmFnZW1lbnQsIFVSTCBpbXBsZW1lbnRvcnMpIHdv dWxkIGhlbHAuDQoNCg0K From nobody Thu Jan 15 17:48:56 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AD71A90A9 for ; Thu, 15 Jan 2015 17:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHSLqWwj_g-c for ; Thu, 15 Jan 2015 17:48:51 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.229]) by ietfa.amsl.com (Postfix) with ESMTP id 8E04E1A8820 for ; Thu, 15 Jan 2015 17:48:51 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:47549] helo=rubix) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 18/72-31347-20E68B45; Fri, 16 Jan 2015 01:48:51 +0000 Received: from [192.168.1.115] (unknown [192.168.1.115]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 0E4741409A6; Thu, 15 Jan 2015 20:48:49 -0500 (EST) Message-ID: <54B86E01.5000607@intertwingly.net> Date: Thu, 15 Jan 2015 20:48:49 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Larry Masinter , "Murray S. Kucherawy" References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net> <54B7E32A.9090800@intertwingly.net> <54B82FD7.9060208@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 01:48:53 -0000 On 01/15/2015 06:30 PM, Larry Masinter wrote: > +1 BOF at next IETF, whether or not it leads to a working group. > > Proposed Agenda: walk through draft-ruby-url-problem (I volunteer) > based on that, discuss next steps. Thanks! > If a working group is wanted, proposed charter milestone: > > * finish draft-ruby-url-problem (problem statement agreed or controversies identified, proposed plans concrete or have concrete options), publish as RFC. > * Then recharter or close (within 4 months) > > If you agree, it would help focus the discussion if comments were couched in terms of changes to draft-ruby-url-problem. > For example, https://tools.ietf.org/html/draft-ruby-url-problem-01#section-5.2 does note some kinds of things an update to 3986 might accomplish, but doesn't suggest changing fragment identifier repertoire, as Sam suggested in email. I'll ensure that this document is updated before any BOF. > If you want a mailing list other than appswg, either a new one or an old one; of the existing mailing lists, I suggest uri@w3.org is the closest in scope. > > I'm in favor of chartering and managing the work in IETF and not in W3C based on where the specs would get adequate review. > * URIs/URLs, although invented for the web, are now woven into many other IETF protocols and data structures than the web, and those are mainly out of scope for W3C/WHATWG priorities. > * it seems easier to get broader review in IETF. I say this despite the past failure to get W3C/WHATWG participation in the IRI working group, because we now have real data about browser behavior and the new possibility of getting browser participation in the discussion. The following section doesn't seem like a good fit for the IETF: https://url.spec.whatwg.org/#api I'd like to understand more why the previous IRI efforts stalled before endorsing that part of the work being done at the IETF. I have no problem with the idea of a RFC 3986bis being done at the IETF. > Commitments of participation (from W3C management, URL implementors) would help. I don't think that W3C management will be an issue. - Sam Ruby From nobody Thu Jan 15 19:30:40 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CDD1A9143 for ; Thu, 15 Jan 2015 19:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4QhFr6XNvmM for ; Thu, 15 Jan 2015 19:30:37 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A99A51A9169 for ; Thu, 15 Jan 2015 19:30:37 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 885C4BBA06C; Thu, 15 Jan 2015 19:30:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=wOKVGYiFsmGvdI KPy22ST43ka1w=; b=H86ARa/fqkdJGRZZ7qZ0+Hh7ofAc1YLEnTFCaQxD0O6xGs /kF3aVRmP688EOI3nBMcEHnWITRnxERbHS/xL837Gzq2rbpDz7m/qxHuPnuJhng/ 3rJVxHIr/UtfRSGlMGN+WuOWwh90IQTz3CaDOmvNCriv+CyGuRVUIWkKejrpM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPA id 324E9BBA06A; Thu, 15 Jan 2015 19:30:37 -0800 (PST) Date: Thu, 15 Jan 2015 21:30:36 -0600 From: Nico Williams To: Sam Ruby Message-ID: <20150116033032.GD2350@localhost> References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54B7AEC2.9010109@intertwingly.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Graham Klyne , apps-discuss@ietf.org Subject: [apps-discuss] What does it mean? (Re: Scope of RFC3986 and successor - what is a URI?) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 03:30:39 -0000 On Thu, Jan 15, 2015 at 07:12:50AM -0500, Sam Ruby wrote: > I proposed that the set of characters allowed in a fragment be > changed to match the following: > > https://specs.webplatform.org/url/webspecs/develop/#url-code-points > > When I did so, people freaked out, piled on, and generally made > points unrelated to what was actually proposed. My takeaway: this > mailing list is not a receptive place for people who identify > specific problems and proposing specific updates. Forgive me if I'm > not exactly eager to do that again. This is a very long set of threads. Can we summarize the proposal? By now it's lost in a sea of posts. My first-order question is: Is the proposal that [some? all?] heretofore-US-ASCII-only protocol fields now begin accepting and carrying UTF-8 (or some other UTF)? *That* I could see causing a freak-out. I don't see a need for controversy if no breaking changes are proposed. If some proposed changes are breaking, we can discuss their impact and possibly accept them, but there will be controversy. A change that would break things on paper might not, of course, and can be considered even if it did, but it would be controversial even if it turned out that the change would not be breaking in actual deployments. I think that's a fair place to start. I want to know just how much I should care about this. If there's no breaking change, then maybe I (and probably others) don't care at all and can stop paying attention. (APIs and protocols are different (but related) things. RFC3986 does not specify an API. API changes are necessarily out of scope when discussing RFC3986, but it'd be nice to have abstract APIs that might help us think about URIs in general and to identify breaking changes in particular.) Nico -- From nobody Thu Jan 15 23:38:43 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB411AC3A0 for ; Thu, 15 Jan 2015 23:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHAtzzqSCNF5 for ; Thu, 15 Jan 2015 23:38:37 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0081.outbound.protection.outlook.com [207.46.100.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A504B1ABD3E for ; Thu, 15 Jan 2015 23:38:37 -0800 (PST) Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0959.namprd02.prod.outlook.com (25.160.216.27) with Microsoft SMTP Server (TLS) id 15.1.53.17; Fri, 16 Jan 2015 07:38:35 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) by DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) with mapi id 15.01.0053.000; Fri, 16 Jan 2015 07:38:36 +0000 From: Larry Masinter To: Sam Ruby Thread-Topic: [apps-discuss] What does it mean? (Re: Scope of RFC3986 and successor - what is a URI?) Thread-Index: AQHQMTzQ/HyNAM9N0UCNjmQgJ7bGfJzCKOlQ Date: Fri, 16 Jan 2015 07:38:36 +0000 Message-ID: References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> In-Reply-To: <20150116033032.GD2350@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:9:8380:992:ec21:132e:caaf:6bd0] authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DM2PR0201MB0959; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB0959; x-forefront-prvs: 04583CED1A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(51704005)(189002)(24454002)(54606007)(74316001)(2900100001)(64706001)(99286002)(50986999)(54356999)(76176999)(68736005)(62966003)(77156002)(97736003)(15975445007)(102836002)(33656002)(2950100001)(86362001)(19580405001)(105586002)(76576001)(46102003)(2656002)(54206007)(93886004)(19580395003)(92566002)(110136001)(106356001)(122556002)(40100003)(106116001)(101416001)(87936001)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0959; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2015 07:38:36.0710 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB0959 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] What does it mean? (Re: Scope of RFC3986 and successor - what is a URI?) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 07:38:40 -0000 T24gVGh1LCBKYW4gMTUsIDIwMTUgYXQgMDc6MTI6NTBBTSAtMDUwMCwgU2FtIFJ1Ynkgd3JvdGU6 DQo+IEkgcHJvcG9zZWQgdGhhdCB0aGUgc2V0IG9mIGNoYXJhY3RlcnMgYWxsb3dlZCBpbiBhIGZy YWdtZW50IGJlDQo+IGNoYW5nZWQgdG8gbWF0Y2ggdGhlIGZvbGxvd2luZzoNCj4gaHR0cHM6Ly9z cGVjcy53ZWJwbGF0Zm9ybS5vcmcvdXJsL3dlYnNwZWNzL2RldmVsb3AvI3VybC1jb2RlLXBvaW50 cw0KDQpNeSBvcGluaW9uOg0KDQpXaGF0IGNoYXJhY3RlcnMgYXJlIGFsbG93ZWQgaW4gJ2EgZnJh Z21lbnQnIGRlcGVuZHMgb24gdGhlIGNvbnRleHQuIEZyYWdtZW50IA0KT2YgYSAiVVJJIjogTXkg b3Bpbmlvbjogbm8sIG5vdCBhIGdvb2QgaWRlYSwgaXQgd291bGQgYnJlYWsgYXNjaWktb25seSBz bG90cyB0aGF0IG5vdyB0YWtlIFVSSSBvbmx5LiANCk9mIGFuICJJUkkiOiBXb3J0aCBkaXNjdXNz aW5nLCBsaWtlbHk7IG5lZWQgdG8gcmV2aWV3IGFnYWluc3QgMzk4NyBhbmQgdXBkYXRlIHdoZXJl IGV4cGVyaWVuY2UgZGljdGF0ZXMuDQogICAgICAgICAgICAgICAgIENlcnRhaW5seSBJUkkgZnJh Z21lbnRzIGNhbiBoYXZlIG5vbi1BU0NJSSBjaGFyYWN0ZXJzLCBpdCdzIGp1c3Qgc2Vjb25kICMg YW5kIDwgPiBmb3IgZXhhbXBsZS4NCk9mIGEgIlVSTCI6IERlcGVuZHMgb24gd2hhdCB5b3UgbWVh bjoNCi0gIElmIHlvdSBtZWFuIHRoZSB0aGluZyBJRVRGIG5vdyBjYWxscyAiSVJJIiB3YXMgbm93 IChhbHNvKSBjYWxsZWQgYSAiVVJMIiwgdGhlbiBzZWUgIklSSSIgYWJvdmUuDQotICAgSWYgeW91 IG1lYW4gYnkgIlVSTCIgc29tZSBwcmV2aW91cyBkZWZpbml0aW9uLCBsaWtlOg0KICAgKiAgICJh IFVSTCBpcyBhIFVSSSB0aGF0IGRvZXNuJ3Qgc3RhcnQgd2l0aCAndXJuOiciIG9yIChhbHRlcm5h dGl2ZWx5KQ0KICAgKiAgImEgVVJMICBpcyBhIFVSSSB0aGF0IGRvZXNuJ3QgYWN0IGxpa2UgYSBV Uk4iLg0KICAgIFRoZW4gc2VlICJVUkkiIGFib3ZlLg0KDQpJIHRoaW5rIHRoZSBub21lbmNsYXR1 cmUgaXNzdWUgaXMgdGhlIHByaW1hcnkgY2F1c2Ugb2YgcGVvcGxlIHRhbGtpbmcgcGFzdCBlYWNo IG90aGVyIG9yIGdldHRpbmcgc2FyY2FzdGljLg0KDQpPbmUgbWFqb3IgY2hhbmdlIEkgaGFkIGJl ZW4gdHJ5aW5nIHRvIG1ha2UgaW4gMzk4N2JpcyB3YXMgdG8gY2hhbmdlIHRoZSBwcm9jZXNzaW5n IG1vZGVsIHNvIHRoYXQgSVJJIC0+IFVSSSBtYXBwaW5nIGhhcHBlbmVkIGJ5IHBhcnNpbmcgZmly c3QsIGFuZCB0aGVuIChvbmx5IGlmIHJlYXNzZW1ibGluZyBpbnRvIGEgVVJJKSBkb2luZyBVVEYt OC0leHgtaGV4LWVuY29kaW5nIHNlY29uZCBvbiBlYWNoIG9mIHRoZSAoVW5pY29kZSkgcGFyc2Vk IGNvbXBvbmVudHMuIFdvdWxkIHRoaXMgcG9zc2libHkgYWxsb3cgSUROQSBmb3IgbWFpbHRvOm5v bmFzY2lpQG5vbmFzY2lpP3N1YmplY3Q9bm9uYXNjaWkgb3RoZXIgc2xvdHM/DQoNCj4gPiBXaGVu IEkgZGlkIHNvLCBwZW9wbGUgZnJlYWtlZCBvdXQsIHBpbGVkIG9uLCBhbmQgZ2VuZXJhbGx5IG1h ZGUNCj4gPiBwb2ludHMgdW5yZWxhdGVkIHRvIHdoYXQgd2FzIGFjdHVhbGx5IHByb3Bvc2VkLiAg DQoNClRoaXMgY2FuIGhhcHBlbiB3aGVuIHRoZSBzYW1lIHdvcmRzIGFyZSB1c2VkIHdpdGggZGlm ZmVyZW50IG1lYW5pbmdzLg0KDQo+ID4gTXkgdGFrZWF3YXk6IHRoaXMgbWFpbGluZyBsaXN0IGlz IG5vdCBhIHJlY2VwdGl2ZSBwbGFjZSBmb3IgcGVvcGxlIHdobyBpZGVudGlmeSBzcGVjaWZpYyBw cm9ibGVtcyBhbmQgcHJvcG9zaW5nIHNwZWNpZmljIHVwZGF0ZXMuICANCg0KWW91ciBwcm9ibGVt cyBhbmQgdXBkYXRlcyBtaWdodCAgbm90IGhhdmUgYmVlbiBhcyBzcGVjaWZpYyBhcyB5b3UgdGhv dWdodC4NCg== From nobody Fri Jan 16 03:12:45 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB731AC3E3 for ; Fri, 16 Jan 2015 03:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZSsAtJ5ZGTf for ; Fri, 16 Jan 2015 03:12:39 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.232]) by ietfa.amsl.com (Postfix) with ESMTP id 066641ACD6E for ; Fri, 16 Jan 2015 03:12:38 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:19126] helo=rubix) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id DD/B7-30941-622F8B45; Fri, 16 Jan 2015 11:12:38 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id DAD7A140E0D; Fri, 16 Jan 2015 06:12:37 -0500 (EST) Message-ID: <54B8F225.1060308@intertwingly.net> Date: Fri, 16 Jan 2015 06:12:37 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Nico Williams References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> In-Reply-To: <20150116033032.GD2350@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] What does it mean? (Re: Scope of RFC3986 and successor - what is a URI?) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 11:12:42 -0000 On 01/15/2015 10:30 PM, Nico Williams wrote: > On Thu, Jan 15, 2015 at 07:12:50AM -0500, Sam Ruby wrote: >> I proposed that the set of characters allowed in a fragment be >> changed to match the following: >> >> https://specs.webplatform.org/url/webspecs/develop/#url-code-points >> >> When I did so, people freaked out, piled on, and generally made >> points unrelated to what was actually proposed. My takeaway: this >> mailing list is not a receptive place for people who identify >> specific problems and proposing specific updates. Forgive me if I'm >> not exactly eager to do that again. > > This is a very long set of threads. > > Can we summarize the proposal? By now it's lost in a sea of posts. I'd like to see all values that can be returned by the following expression to be considered valid URIs for all values of x: new URL(x).href The definitions needed to evaluate the above expression can be found here: https://url.spec.whatwg.org/#api Alternately, both Firefox and Chrome ship the URL object, so you can try it yourself by going into the JavaScript console. > My first-order question is: > > Is the proposal that [some? all?] heretofore-US-ASCII-only protocol > fields now begin accepting and carrying UTF-8 (or some other UTF)? > > *That* I could see causing a freak-out. The above proposal does currently put utf-8 into the fragment protocol field. > I don't see a need for controversy if no breaking changes are proposed. > If some proposed changes are breaking, we can discuss their impact and > possibly accept them, but there will be controversy. > > A change that would break things on paper might not, of course, and can > be considered even if it did, but it would be controversial even if it > turned out that the change would not be breaking in actual deployments. Thank you, thank you, thank you for putting this so clearly! I do believe that "break things on paper" is necessary given my data that valid URIs are a merely a Platonic ideal. I do believe that "breaking in actual deployments" should be avoided. > I think that's a fair place to start. I want to know just how much I > should care about this. If there's no breaking change, then maybe I > (and probably others) don't care at all and can stop paying attention. A necessary outcome of this effort is that some things currently considered valid by RFC 3986 will no longer be considered such. And that some things not currently considered valid by RFC 3986 will become valid. > (APIs and protocols are different (but related) things. RFC3986 does > not specify an API. API changes are necessarily out of scope when > discussing RFC3986, but it'd be nice to have abstract APIs that might > help us think about URIs in general and to identify breaking changes in > particular.) I believe that both scope and venue should be on the table. There is a relationship between the API and the protocol. In particular, for HTTP, this API is in active use for constructing data that goes across the wire. If the definition of the API would have the effect of causing data to go across the wire to cause problems with actual deployments, then the API should change. Given that versions of this API are widely deployed today, I would think that should be rare. If the definition of the API would have the effect of causing data to go across the wire that does NOT cause problems with actual deployments, then that data should be considered valid. Even if this breaks things "on paper". Even if it is controversial. Aligning the definition of validity with reality will benefit future producers and consumers. In particular, it will free them from the necessity of reverse engineering each others implementations. > Nico - Sam Ruby From nobody Fri Jan 16 03:34:42 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D59E1ACD9F for ; Fri, 16 Jan 2015 03:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZggOA9vRTEu for ; Fri, 16 Jan 2015 03:34:38 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.230]) by ietfa.amsl.com (Postfix) with ESMTP id 892E91ACD98 for ; Fri, 16 Jan 2015 03:34:35 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:20745] helo=rubix) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id DC/05-30941-A47F8B45; Fri, 16 Jan 2015 11:34:35 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id EBA3B140E0D; Fri, 16 Jan 2015 06:34:34 -0500 (EST) Message-ID: <54B8F74A.70601@intertwingly.net> Date: Fri, 16 Jan 2015 06:34:34 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Larry Masinter References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] What does it mean? (Re: Scope of RFC3986 and successor - what is a URI?) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 11:34:41 -0000 On 01/16/2015 02:38 AM, Larry Masinter wrote: > On Thu, Jan 15, 2015 at 07:12:50AM -0500, Sam Ruby wrote: >> I proposed that the set of characters allowed in a fragment be >> changed to match the following: >> https://specs.webplatform.org/url/webspecs/develop/#url-code-points > > My opinion: > > What characters are allowed in 'a fragment' depends on the context. Fragment > Of a "URI": My opinion: no, not a good idea, it would break ascii-only slots that now take URI only. I would like to explore the possibility of the URL API being build on top of a RFC 3986bis definition. In particular, I'd like to see all potential results of the following expression be considered valid URIs, for all values of x: new URL(x).href In the process I'd like to be free to explore "breaking things on paper" as Niko so eloquently put it. Of course, breaking actual deployments should be avoided. But given that versions of the above are actually widely deployed, this should be rare. Of course, there are people who use HTTP URIs outside of the context of HTTP. It would be unfortunate if the definition of such -- including validity -- were context dependent. And, of course, there are plenty of non HTTP usages of URLs. I'd like the same constraint described above to apply there too. > Of an "IRI": Worth discussing, likely; need to review against 3987 and update where experience dictates. > Certainly IRI fragments can have non-ASCII characters, it's just second # and < > for example. I'd like to see the definition of IRI retired. > Of a "URL": Depends on what you mean: > - If you mean the thing IETF now calls "IRI" was now (also) called a "URL", then see "IRI" above. > - If you mean by "URL" some previous definition, like: > * "a URL is a URI that doesn't start with 'urn:'" or (alternatively) > * "a URL is a URI that doesn't act like a URN". > Then see "URI" above. None of the above. I mean what is defined by the following: https://url.spec.whatwg.org/ > I think the nomenclature issue is the primary cause of people talking past each other or getting sarcastic. I've seen sarcasm, strawmen, caricatures, being condescending, and other inappropriate behaviors in reaction to the very idea of breaking things on paper. None of this is helpful. > One major change I had been trying to make in 3987bis was to change the processing model so that IRI -> URI mapping happened by parsing first, and then (only if reassembling into a URI) doing UTF-8-%xx-hex-encoding second on each of the (Unicode) parsed components. Would this possibly allow IDNA for mailto:nonascii@nonascii?subject=nonascii other slots? IDNA (Internationalizing Domain Names in Applications) is for domains only. I'm not proposing applying this on anything other than a domain name. >>> When I did so, people freaked out, piled on, and generally made >>> points unrelated to what was actually proposed. > > This can happen when the same words are used with different meanings. None of these are an appropriate response. Period. >>> My takeaway: this mailing list is not a receptive place for people who identify specific problems and proposing specific updates. > > Your problems and updates might not have been as specific as you thought. Fair point. That's why I have now adopted the following as the way I to express what I propose ∀x: URI.valid(new URL(x).href) = true I'd like to explore what changes to the definitions of [IETF] URI and/or [WHATWG/W3C] URL would be necessary to make that statement true. - Sam Ruby From nobody Fri Jan 16 03:50:21 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1081ACD81 for ; Fri, 16 Jan 2015 03:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wf7gj6oc-ssv for ; Fri, 16 Jan 2015 03:50:15 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 6CED31ACD6E for ; Fri, 16 Jan 2015 03:50:15 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id t0GBo9pu029460; Fri, 16 Jan 2015 11:50:09 GMT 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 t0GBo8Jl021334; Fri, 16 Jan 2015 11:50:08 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t0GBo8bs018718; Fri, 16 Jan 2015 11:50:08 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id t0GBo7UP018714; Fri, 16 Jan 2015 11:50:07 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Larry Masinter References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 16 Jan 2015 11:50:07 +0000 In-Reply-To: (Larry Masinter's message of "Fri\, 16 Jan 2015 07\:38\:36 +0000") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] Terminology and scope of [UI]Rx-like objects (was Re: What does it mean? (Re: Scope of RFC3986 and successor - what is a URI?)) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 11:50:19 -0000 I'm worried we've got unnecessarily confused and/or antagonistic because we're not carefully distinguishing names and contexts of use. Context of use is crucial, if I understand the history and the requirements behind the IETF specifications correctly. 3986 defines a low-level protocol element (hereafer 'I_URI'), for use in protocols such as HTTP. I_URIs are restricted to ASCII, and have a relatively conservative syntax intended to make the first-order (scheme-independent) parsing of I_URIs easy. It is _not_ a specification designed primarily for human authoring or reading. In consequence, over time, a number of alternative attempts to specify more human-friendly presentation forms for I_URIs have arisen. IRIs can be seen as such a form, although 3987 [1] is less than completely clear about this. This aspect of 3987 is made explicit: "IRIs can serve as presentation elements for URI protocol elements. An example would be an address bar in a Web user agent." [2] But IRIs extend I_URIs in a relatively conservative way, focussed on (to put it informally) allowing a wider range of alphabets where I_URIs allowed only ASCII alphabetics. For this reason IRIs might reasonably be criticised as not really satisfying a requirement for congenial human use. In particular (see earlier part of this thread), 3987 did _not_ change the 'reserved' production of 3986, or add '[' or ']' to the 'iquery' production. Nor does it allow space characters or most punctuation characters. The first example I'm aware of, of a specification which actually addresses the presentation form question, is "Legacy Extended IRIs for XML resource identification" [3], which arose from the recognition that the XML specification [4], and subsequently the XML Schema specification [5], did _not_ constrain the contents of language elements used for identification of web resources to I_URI or IRI syntax. LEIRIs added space and a number of ASCII punctuation and UCS non-alphabetic ranges into the 'iunreserved' production. The WHATWG URL specification [6] is essentially targetted at the parallel problem for browsers and HTML -- what people type in the 'address' bar, or put in 'href' or 'src' attributes, has never been restricted in practice to I_URI syntax. The HTML 4.01 spec [7] already recommends error recovery behaviour for non-ASCII strings in href attributes. It is thus it seems to me entirely reasonable for the HTML5 specification (for which I'm happy to view [6] as a proposed revision/additional constituent) to define a high-level protocol element, call it W_URL, for use in browsers and HTML language elements. The key thing, it seems to me, is to recognise that as such the W_URL is not an alternative to, but rather a presentation form for, IRIs or I_URIs, with its own (obviously related) syntax, and interoperably- defined error recovery mechanisms. It _also_ seems entirely reasonable to me, from the perspective of the _low_-level protocols concerned, to be extremely cautious about any changes to I_URI syntax. I think the only changes needed are 1) For Sam Ruby to re-interpret the _functionality_ which needs to be specified wrt W_URLs as including the mapping _from_ W_URLs _to_ I_URIs (possibly via a mapping to IRIs, possibly not); 2) For the IETF to entertain minor revisions to 3986 or 3987 if that's required to make (1) easy to achieve. ht [1] http://tools.ietf.org/html/rfc3987 [2] http://tools.ietf.org/html/rfc3987#section-3 [3] http://www.w3.org/TR/leiri/ [4] http://www.w3.org/TR/xml/ [5] http://www.w3.org/TR/xmlschema11-1/ [6] https://url.spec.whatwg.org/ [7] http://www.w3.org/TR/html401/appendix/notes.html#non-ascii-chars -- 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 Fri Jan 16 03:54:34 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73B31ACDB9 for ; Fri, 16 Jan 2015 03:54:32 -0800 (PST) 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, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieru7CRTrqqR for ; Fri, 16 Jan 2015 03:54:30 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0745.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::745]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0082A1ACDBA for ; Fri, 16 Jan 2015 03:54:29 -0800 (PST) Received: from pc6 (81.151.167.59) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.1.59.20; Fri, 16 Jan 2015 11:54:06 +0000 Message-ID: <016401d03182$fbe765e0$4001a8c0@gateway.2wire.net> From: t.petch To: Sam Ruby , Dave Cridland References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com><54A94109.5010901@intertwingly.net><00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net><54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net><54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net><54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net><012001d02d91$6ec42300$4001a8c0@gateway.2wire.net><54B2781C.4040505@intertwingly.net><018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net><54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org><54B7AEC2.9010109@intertwingly.net><54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net><54B7E00D.9040509@intertwingly.net> <54B7ED13.8020709@intertwingly.net> Date: Fri, 16 Jan 2015 11:52:19 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB4PR03CA0010.eurprd03.prod.outlook.com (25.160.39.148) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:AMXPR07MB054; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:AMXPR07MB054; X-Forefront-PRVS: 04583CED1A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(189002)(377454003)(13464003)(51704005)(479174004)(199003)(101416001)(66066001)(62966003)(97736003)(61296003)(42186005)(46102003)(86362001)(106356001)(47776003)(105586002)(44716002)(64706001)(62236002)(92566002)(77096005)(50466002)(77156002)(33646002)(19580405001)(19580395003)(84392001)(93886004)(50986999)(40100003)(122386002)(76176999)(81686999)(81816999)(50226001)(68736005)(1556002)(87976001)(23756003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB054; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB054; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jan 2015 11:54:06.5702 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB054 Archived-At: Cc: Graham Klyne , apps-discuss@ietf.org Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 11:54:32 -0000 ----- Original Message ----- From: "Sam Ruby" To: "Dave Cridland" Cc: "Graham Klyne" ; Sent: Thursday, January 15, 2015 4:38 PM > On 01/15/2015 11:16 AM, Dave Cridland wrote: > > > > Can you point out where in the IRI specification it says that '[' is > > a valid character to include in a query? > > > > Julian has agreed[1] that "If an example of a problem I'm facing is > > that escaping square brackets in query/search strings causes > > problems, I'm not likely to find the solution to that problem in IRIs." > > > > *sigh* > > > > One argument at a time. I've already stated that I do not have any > > problem in principle with changing the rules on reserved characters in > > queries in this respect; moreover I'd be fine with "[]" in a number of > > places. It makes the specification slightly more complex, but I can live > > with that. > > So discussing how to change RFC 3986 to better match what is commonly > deployed is indeed a possibility. Sam, A possibility that the IETF at large discussed extensively in 2013 and rejected. RFC6874 records the consensus of the IETF, that the rules on the use of the percent character should not be relaxed, while acknowledging that this behaviour was prevalent in a number of browsers. So the IETF has gone there and said no in the recent past (for at least one case). That RFC also clearly flags the issue raised here of the difference between what is valid in a URI and what is valid in a browser's input dialogue box. Tom Petch From nobody Fri Jan 16 04:01:05 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973F21ACD65 for ; Fri, 16 Jan 2015 04:01:02 -0800 (PST) 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, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4774-678yLe9 for ; Fri, 16 Jan 2015 04:01:00 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0779.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::779]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21A3C1ACCFD for ; Fri, 16 Jan 2015 04:00:59 -0800 (PST) Received: from pc6 (81.151.167.59) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.1.59.20; Fri, 16 Jan 2015 12:00:36 +0000 Message-ID: <019101d03183$e4708300$4001a8c0@gateway.2wire.net> From: t.petch To: "Murray S. Kucherawy" , Sam Ruby References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net> <54B7E32A.9090800@intertwingly.net> Date: Fri, 16 Jan 2015 11:59:18 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB4PR03CA0024.eurprd03.prod.outlook.com (25.160.39.162) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:AMXPR07MB054; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:AMXPR07MB054; X-Forefront-PRVS: 04583CED1A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(377454003)(199003)(51444003)(24454002)(189002)(76176999)(15975445007)(40100003)(122386002)(81816999)(50226001)(81686999)(84392001)(19580405001)(19580395003)(50986999)(93886004)(1556002)(87976001)(68736005)(42186005)(61296003)(46102003)(86362001)(23676002)(101416001)(97736003)(62966003)(66066001)(77156002)(77096005)(92566002)(50466002)(33646002)(105586002)(106356001)(47776003)(62236002)(44716002)(64706001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB054; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB054; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jan 2015 12:00:36.7886 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB054 Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 12:01:02 -0000 ----- Original Message ----- From: "Murray S. Kucherawy" To: "Sam Ruby" Cc: Sent: Thursday, January 15, 2015 7:30 PM > On Thu, Jan 15, 2015 at 7:56 AM, Sam Ruby wrote: > > > I was told (perhaps bad advice?) that the first step would be to publish a > > problem statement, which I have done: > > > > https://tools.ietf.org/id/draft-ruby-url-problem-01.txt > > > > It's not bad advice. Drafts are roughly free. :-) > > I'd like to see some future revision of that document be accepted and > > published as an RFC. > > > > And that the next step would be a BOF: > > > > http://www.ietf.org/meeting/important-dates-2015.html > > > > Based on what I see, and discussions I have held, I'd like to proceed as > > outlined here: > > > > If you're looking at doing a BoF, I think that aligns with what I was going > to suggest: > > Given the current number of participants and especially the more passionate > ones, I'm wondering if this shouldn't have a dedicated tightly-focused > working group to house this work separately from apps-discuss (which is the > home of both APPSAWG and the APP area general traffic). Have you thought > of writing up a charter to define the work? Murray, I am pleasantlysurprised that none of this discussion has spilled over onto uri@w3.org which the IETF website describes as "This mailing list is used to discuss updates to the URI standards and processes." I am glad it has not since I find the administration of apps-discuss much better, but if you wanted to offload the ietf list, then that would be another alternative. Tom Petch > Such a working group could include your problem statement draft as its > first deliverable. > > I'm also curious to hear, and probably see in such a charter, why this work > belongs in the IETF and not the W3C. I'm not making an argument for > either, just don't have the history to understand that part of it. > > -MSK > ------------------------------------------------------------------------ -------- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Fri Jan 16 04:08:45 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6761ACD2F for ; Fri, 16 Jan 2015 04:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WS461mipi6uc for ; Fri, 16 Jan 2015 04:08:38 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id C0BF71ACD2E for ; Fri, 16 Jan 2015 04:08:37 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id t0GC8VW0011908; Fri, 16 Jan 2015 12:08:31 GMT 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 t0GC8Uu9022509; Fri, 16 Jan 2015 12:08:30 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t0GC8U8E019106; Fri, 16 Jan 2015 12:08:30 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id t0GC8UE5019102; Fri, 16 Jan 2015 12:08:30 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Sam Ruby References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <54B8F74A.70601@intertwingly.net> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 16 Jan 2015 12:08:30 +0000 In-Reply-To: <54B8F74A.70601@intertwingly.net> (Sam Ruby's message of "Fri\, 16 Jan 2015 06\:34\:34 -0500") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Cc: "apps-discuss@ietf.org" , Larry Masinter Subject: Re: [apps-discuss] What does it mean? (Re: Scope of RFC3986 and successor - what is a URI?) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 12:08:41 -0000 Sam Ruby writes: > I would like to explore the possibility of the URL API being build on > top of a RFC 3986bis definition. In particular, I'd like to see all > potential results of the following expression be considered valid > URIs, for all values of x: > > new URL(x).href > > In the process I'd like to be free to explore "breaking things on > paper" as Niko so eloquently put it. Of course, breaking actual > deployments should be avoided. But given that versions of the above > are actually widely deployed, this should be rare. [I read this after sending my recent post titled "Terminology and scope...", which will appear after it in this thread] I _think_ there's an implication here that I at least had not been aware of in your previous references to "new URL(x).href". Is it in fact the case that the value of this expression (also I think what you've been calling the 'stringification' of a W_URL), _is_ exactly, byte for byte, what is put on the wire in HTTP requests by browsers? 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] From nobody Fri Jan 16 04:54:18 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B611ACDCF for ; Fri, 16 Jan 2015 04:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfgTwZSZ4cJ2 for ; Fri, 16 Jan 2015 04:54:14 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.231]) by ietfa.amsl.com (Postfix) with ESMTP id 059AF1ACDC8 for ; Fri, 16 Jan 2015 04:54:13 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:29819] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 01/F0-03864-5F909B45; Fri, 16 Jan 2015 12:54:13 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 14097140E0D; Fri, 16 Jan 2015 07:54:13 -0500 (EST) Message-ID: <54B909F4.4020908@intertwingly.net> Date: Fri, 16 Jan 2015 07:54:12 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Henry S. Thompson" References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <54B8F74A.70601@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: Cc: "apps-discuss@ietf.org" , Larry Masinter Subject: Re: [apps-discuss] What does it mean? (Re: Scope of RFC3986 and successor - what is a URI?) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 12:54:16 -0000 On 01/16/2015 07:08 AM, Henry S. Thompson wrote: > Sam Ruby writes: > >> I would like to explore the possibility of the URL API being build on >> top of a RFC 3986bis definition. In particular, I'd like to see all >> potential results of the following expression be considered valid >> URIs, for all values of x: >> >> new URL(x).href >> >> In the process I'd like to be free to explore "breaking things on >> paper" as Niko so eloquently put it. Of course, breaking actual >> deployments should be avoided. But given that versions of the above >> are actually widely deployed, this should be rare. > > [I read this after sending my recent post titled "Terminology and > scope...", which will appear after it in this thread] In the hopes of tying together the threads, I'll make some brief responses to that email here: I question whether RFC 3986 succeeded in the goal of making "first-order ... parsing of I_URIs easy". I see many different, and incompatible, implementations. The sentence ("_not_ .. designed primarily for human") is not made clear by RFC 3986. The WHATWG URL specification is not limited to browsers. It defines a syntax that is fit for human production and consumption that is intended to be consistently parsed by a variety of parsers in a variety of contexts. Every modern programming language has a URI or URL parse mechanism. Minor is in the eye of the beholder. What I am gathering is that changing RFC 3986 -- even in ways that only break things "on paper" -- is controversial. I welcome everybody to participate in the discussion as to what W_URLs map to. I welcome discussion as to whether that mapping produces valid I_URIs. As to whether the changes necessary to the definition of I_URIs turn out to be 'minor' or the end result being that W_URLs map to something that is neither a proper superset or a proper subset of valid I_URIs is only something we will know after those discussions take place. > I _think_ there's an implication here that I at least had not been > aware of in your previous references to "new URL(x).href". > > Is it in fact the case that the value of this expression (also I think > what you've been calling the 'stringification' of a W_URL), _is_ > exactly, byte for byte, what is put on the wire in HTTP requests by > browsers? That is my understanding. To put it another way: if it is not, that would be considered a bug. Note that stringification produces a string of Unicode code points. As all of those code points -- with the notable exception of fragments -- are a proper subset of US ASCII graphic characters, the mapping of such to bytes is straightforward. At a minimum, the WHATWG/W3C specifications should be updated to make this clear. > ht - Sam Ruby From nobody Fri Jan 16 05:05:40 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514DE1ACCE1 for ; Fri, 16 Jan 2015 05:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.026 X-Spam-Level: X-Spam-Status: No, score=-1.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmJzIuyFi6GW for ; Fri, 16 Jan 2015 05:05:27 -0800 (PST) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7A1F1ACD1B for ; Fri, 16 Jan 2015 05:05:18 -0800 (PST) Received: by mail-qa0-f53.google.com with SMTP id n4so15300174qaq.12 for ; Fri, 16 Jan 2015 05:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=L9WSfGSqh5vFdbexHYWxZTN4F+fdTCMM2LjtLR9adHo=; b=VZpwV5raejQPPIZ0jyPD6ct3/iX8f25rGD9Y0wAiqP+e6Z2buBMXdoQI7k4WE38Tl7 2IOr8i8hcRLJL8HKrxdV4e9iqInUjTJAbOT1TpdqZ654JqQxB2M/0+HW82C8gtXRGBKG BGjcslnkK7/EKgeYMXDHVXmE9ncRQZ6BsEzhlbvLskdFg/ACbnoL0l0ks6YBUIOExTlA yl3tX8asY4ImxHbN/w4q96c6NpClUbC/bVS6oIaPyejaC5fFfG8h3suFc96bPfCvBtYC nkQuk3eY9fHnopnsArBwd+ulA0lfhklep85yIRiiQx1W1xtjGkmF7OE3M1CeeqqEZUVF A2YQ== MIME-Version: 1.0 X-Received: by 10.140.27.199 with SMTP id 65mr14386942qgx.24.1421413513384; Fri, 16 Jan 2015 05:05:13 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Fri, 16 Jan 2015 05:05:13 -0800 (PST) In-Reply-To: <54B8454A.7050001@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B806A2.8020803@intertwingly.net> <54B8454A.7050001@intertwingly.net> Date: Fri, 16 Jan 2015 23:05:13 +1000 X-Google-Sender-Auth: DYCE_-1xCRcvy9g-H2dstJnlcbQ Message-ID: From: Matthew Kerwin To: Sam Ruby Content-Type: multipart/alternative; boundary=001a11c156948b5add050cc49fec Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 13:05:35 -0000 --001a11c156948b5add050cc49fec Content-Type: text/plain; charset=UTF-8 Latching on to some details: On 16 January 2015 at 08:55, Sam Ruby wrote: > >> An example of something that is not a conforming URL, but is both a >> valid URI and a valid IRI: >> >> http://257.257.257.257/ >> >> OK... I don't think that's valid, but it's probably valid according to >> the ABNF only (ignoring the prose). I think specifying that in the >> formal syntax would be uncontentious - in >> fact, draft-ietf-iri-3987bis-13 already makes this change. >> > > Is is indeed valid (this was discussed recently on this very list). I > would hope that it is uncontentious. > > I know it's slightly aside, but do you have a pointer to that discussion? Just scanning Appendix A of RFC 3986, it appears we would parse the authority as a reg-name, except that Section 3.2.2 then says: ] A registered name intended for lookup in the DNS uses the syntax ] defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123]. and RFC 1123 goes on to say: ] ... a valid host name can never ] have the dotted-decimal form #.#.#.#, since at least the ] highest-level component label will be alphabetic. I may be a bit over my head here. Maybe that's something that could do with clarification. >> This is problematic in the case of ports - since >> http://www.google.com:80/ and http://www.google.com/ both refer to the >> same thing, but to have a single canonical form for both would require >> the parser to be aware of the default port for the scheme. But maybe >> unknown schemes cannot be canonicalized, or maybe we have two canonical >> forms. (Scheme-aware and scheme-agnostic; obviously you'd specify which >> you want and where). >> > > The current draft does specify the default port for a precious few > schemes, and requires the port-less string form when default ports are used. > > One strategy would be to adjust the registration process to not allow new > schemes to be registered with default ports. Another would be to version > the specification so that new schemes with default ports would require a > revision of the parsing algorithm. I would hope that this would be a > relatively rare event. > > I think this is heading to a place it doesn't need to go. At what point does something need to compare canonical forms of URIs with schemes it doesn't recognise? I can definitely see a lot of value in a generic library that parses any URI-type string into general 3986-defined parts (say), that can be further analysed by scheme-aware machinery -- so generic parsing is useful, but generic (or universal) canonicalisation is an unnecessary complication. Cheers -- Matthew Kerwin http://matthew.kerwin.net.au/ --001a11c156948b5add050cc49fec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Latching on to some details:

On 16 January 201= 5 at 08:55, Sam Ruby <rubys@intertwingly.net> wrote:

=C2=A0 =C2=A0 An example of something that is not a conforming URL, but is = both a
=C2=A0 =C2=A0 valid URI and a valid IRI:

=C2=A0 =C2=A0 http://= 257.257.257.257/

OK... I don't think that's valid, but it's probably valid accor= ding to
the ABNF only (ignoring the prose). I think specifying that in the
formal syntax would be uncontentious - in
fact, draft-ietf-iri-3987bis-13 already makes this change.

 Is is indeed valid (this was discussed recently on this very list).=C2=A0 I= would hope that it is uncontentious.


I know it's slight= ly aside, but do you have a pointer to that discussion? Just scanning Appen= dix A of RFC 3986, it appears we would parse the authority as a reg-name, e= xcept that Section 3.2.2 then says:

] A registered name intended for lookup in the = DNS uses the syntax
] defined in Section 3.5 of [RFC103= 4] and Section 2.1 of [RFC1123].

and RFC 1123 goes on to say:

] have the dotted-d= ecimal form #.#.#.#, since at least the
] highest-level= component label will be alphabetic.

I may be a bit o= ver my head here. Maybe that's something that could do with clarificati= on.
This is problematic in the case of ports - since
http://www.google.c= om:80/ and http://= www.google.com/ both refer to the
same thing, but to have a single canonical form for both would require
the parser to be aware of the default port for the scheme. But maybe
unknown schemes cannot be canonicalized, or maybe we have two canonical
forms. (Scheme-aware and scheme-agnostic; obviously you'd specify which=
you want and where).

 The current draft does specify the default port for a precious few schemes,= and requires the port-less string form when default ports are used.

One strategy would be to adjust the registration process to not allow new s= chemes to be registered with default ports.=C2=A0 Another would be to versi= on the specification so that new schemes with default ports would require a= revision of the parsing algorithm.=C2=A0 I would hope that this would be a= relatively rare event.


I think this is heading to a plac= e it doesn't need to go. At what point does something need to compare c= anonical forms of URIs with schemes it doesn't recognise? I can definit= ely see a lot of value in a generic library that parses any URI-type string= into general 3986-defined parts (say), that can be further analysed by sch= eme-aware machinery -- so generic parsing is useful, but generic (or univer= sal) canonicalisation is an unnecessary complication.


Cheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.= net.au/
--001a11c156948b5add050cc49fec-- From nobody Fri Jan 16 05:30:59 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B0E1ACD40 for ; Fri, 16 Jan 2015 05:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wD7g-eKruDpf for ; Fri, 16 Jan 2015 05:30:56 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.226]) by ietfa.amsl.com (Postfix) with ESMTP id 21FC61AC398 for ; Fri, 16 Jan 2015 05:30:56 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:34402] helo=rubix) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 8B/CB-25206-E8219B45; Fri, 16 Jan 2015 13:30:55 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 1EA76140C67; Fri, 16 Jan 2015 08:30:54 -0500 (EST) Message-ID: <54B9128D.8010805@intertwingly.net> Date: Fri, 16 Jan 2015 08:30:53 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B806A2.8020803@intertwingly.net> <54B8454A.7050001@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 13:30:58 -0000 On 01/16/2015 08:05 AM, Matthew Kerwin wrote: > Latching on to some details: > > On 16 January 2015 at 08:55, Sam Ruby > wrote: > > An example of something that is not a conforming URL, but > is both a > valid URI and a valid IRI: > > http://257.257.257.257/ > > OK... I don't think that's valid, but it's probably valid > according to > the ABNF only (ignoring the prose). I think specifying that in the > formal syntax would be uncontentious - in > fact, draft-ietf-iri-3987bis-13 already makes this change. > > Is is indeed valid (this was discussed recently on this very list). > I would hope that it is uncontentious. Correction: it was on a different list. > I know it's slightly aside, but do you have a pointer to that > discussion? Just scanning Appendix A of RFC 3986, it appears we would > parse the authority as a reg-name, except that Section 3.2.2 then says: > > ] A registered name intended for lookup in the DNS uses the syntax > ] defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123]. > > and RFC 1123 goes on to say: > > ] ... a valid host name can never > ] have the dotted-decimal form #.#.#.#, since at least the > ] highest-level component label will be alphabetic. > > I may be a bit over my head here. Maybe that's something that could do > with clarification. Here's where my statement that URIs like the above were valid was pointed out to be incorrect: https://lists.w3.org/Archives/Public/public-ietf-w3c/2014Dec/0075.html - Sam Ruby From nobody Fri Jan 16 05:37:22 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A311ACDCF for ; Fri, 16 Jan 2015 05:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.079 X-Spam-Level: X-Spam-Status: No, score=-101.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bytXPh94Yhnv for ; Fri, 16 Jan 2015 05:37:16 -0800 (PST) Received: from ftp.catinthebox.net (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC7E1ACD84 for ; Fri, 16 Jan 2015 05:37:15 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2237; t=1421415425; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=XF4WFY5Tjl6y8TTOjA3t0+/csow=; b=oh7Y48KUJGaR6my2iWKI DmmZkpSSV1VQHLDa6zRe06STsV1eslZnIPii3/t7xVdEaAAuQqFsx3rbPXnMT48M 7zFoBpb3vr0jCj6Rxae/Q1GSEg9LEIpkgUlvKBTz94SEHOZY1FFytYrPAWZ5+3So MPa4T2QiE4dvYaH3Wt/SfZk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Fri, 16 Jan 2015 08:37:05 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3715461747.28944.3096; Fri, 16 Jan 2015 08:37:04 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2237; t=1421415344; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=P3u5ci0 SgHnREeDH0mPgsbwQC5AllVA6iLJs7pRrYYs=; b=Kiy0wYh9jTK5tztQObVeH+B 269goRffWEbgV7A/aanIuCODguJzdngPgS7TAZEeMNL+A7pvSyT9f5aQhZvU+pRS yG2+DAbqGBp8sPFtQc+GX7gPAGAYtEcGMKDCyzK4PIwcW/N4dxjXDKMLFQ07d9/C tZRdBm3A7LUqcnoKdk60= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Fri, 16 Jan 2015 08:35:44 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2307814049.9.6100; Fri, 16 Jan 2015 08:35:43 -0500 Message-ID: <54B91402.8010003@isdg.net> Date: Fri, 16 Jan 2015 08:37:06 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Sam Ruby , "Murray S. Kucherawy" References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net> <54B7E32A.9090800@intertwingly.net> In-Reply-To: <54B7E32A.9090800@intertwingly.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 13:37:18 -0000 I have not read deeply into all this, and I don't wish to go off-base with this, but as a small developer shop, I rely on a working standards understanding between all organizations. It makes technical and cost engineering common sense to extract the commonality of all the various "standards" methods. The IETF is a "common mans" group so its important that it recognizes the need and works on it, if possible. I support such work. Thanks -- HLS On 1/15/2015 10:56 AM, Sam Ruby wrote: > On 01/15/2015 10:42 AM, Murray S. Kucherawy wrote: >> >> Second, I don't know what the right answer is. I just know that >> real people have sincerely attempted to follow RFC 3866 and >> encountered real problems with doing so. >> >> I'd personally like to see RFC 3986 changed to address problems >> like >> this one, and for the W3C specification of API behavior to build >> upon this changed definition. >> >> I see a lot of chatter from multiple participants about what oughta >> happen. Has anyone put pen to paper yet to propose an update or >> replacement document that we can really look at? > > I was told (perhaps bad advice?) that the first step would be to > publish a problem statement, which I have done: > > https://tools.ietf.org/id/draft-ruby-url-problem-01.txt > > I'd like to see some future revision of that document be accepted and > published as an RFC. > > And that the next step would be a BOF: > > http://www.ietf.org/meeting/important-dates-2015.html > > Based on what I see, and discussions I have held, I'd like to proceed > as outlined here: > > > https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Nov/0000.html > > > What that means in practice is reconciling the "authoring advice" and > "railroad diagrams" as they appear here: > > https://specs.webplatform.org/url/webspecs/develop/#url-writing > https://specs.webplatform.org/url/webspecs/develop/#rule-url > > With the collected ABNF for URI: > > https://tools.ietf.org/html/rfc3986#appendix-A > >> -MSK > > - Sam Ruby > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > From nobody Fri Jan 16 05:57:46 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4CB1ACCFE for ; Fri, 16 Jan 2015 05:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.347 X-Spam-Level: X-Spam-Status: No, score=0.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, J_CHICKENPOX_19=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fThtMcYcmyhZ for ; Fri, 16 Jan 2015 05:57:40 -0800 (PST) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24BA71ACCFC for ; Fri, 16 Jan 2015 05:57:40 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id w8so14678729qac.13 for ; Fri, 16 Jan 2015 05:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SfqcL4wI4zO3VXDvAQKvcvnucm+EV0lXfj0bkc4MgdM=; b=SJBRjwhK4JMAkQyQ6KffKAwOhcYFyk3jyJK7xI2Sr/GPxDAxs14LKqNBtt9c3YrIBb fyW3vdpdgzFRY2UHhHOaZceyaWzD9Hou5n65xISJi+805FjsoLjTrXHZDot23MvBIEdA xqvPeGvqFC42mSFPYGMUwMxDSegm6DE53pUwU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SfqcL4wI4zO3VXDvAQKvcvnucm+EV0lXfj0bkc4MgdM=; b=BHGxhTaAem1sM1aCXLUKQhVGlvT9E8+RcrIyGvBs7LbifvZXuuTHTYsH5zXiMiA3SY TYcTsx3sRV5sME6ColrUfWg5Jb4mK6emljbc8H4GP84XPxgTZOV9zaS0J/tS9B5mFoeT zWlwyFwzpW1S8MKFHnFJ1O7m0MVZF5yfTIPCahSZcE8ndpxZfGXU5MnTlMroJtbWJU7B GVrgjAH5FZBG0bk5C7R/5oPeriU1ZSrQBBBf9rydOkJm5ZibCNbxJNyth0LojeqNn6BP oGlVJf3mtT8jPhjdVuHrj9aoq6Sxh4jD5jBN1EYwthp9Ho2GskZ+9hFPBDEFjkxGLMY3 BA/A== X-Gm-Message-State: ALoCoQm8FROeCzqDcIM6b2w+qks3CUI91Kkg2K4H6kT4+zS+Dxoqwi3UeVexgis3lVapaF5gE1/N MIME-Version: 1.0 X-Received: by 10.140.32.38 with SMTP id g35mr9181423qgg.54.1421416659257; Fri, 16 Jan 2015 05:57:39 -0800 (PST) Received: by 10.140.196.197 with HTTP; Fri, 16 Jan 2015 05:57:39 -0800 (PST) In-Reply-To: <54B909F4.4020908@intertwingly.net> References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <54B8F74A.70601@intertwingly.net> <54B909F4.4020908@intertwingly.net> Date: Fri, 16 Jan 2015 13:57:39 +0000 Message-ID: From: Dave Cridland To: Sam Ruby Content-Type: multipart/alternative; boundary=001a1139bcda0da1b6050cc55bc4 Archived-At: Cc: "apps-discuss@ietf.org" , Larry Masinter Subject: Re: [apps-discuss] What does it mean? (Re: Scope of RFC3986 and successor - what is a URI?) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 13:57:43 -0000 --001a1139bcda0da1b6050cc55bc4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A couple of points. I shall use the terms "URI" and "IRI" as defined in the IETF specs, and W_URL to mean the W3C/WHATWG/etc thing. On 16 January 2015 at 12:54, Sam Ruby wrote: > The WHATWG URL specification is not limited to browsers. It defines a > syntax that is fit for human production and consumption that is intended = to > be consistently parsed by a variety of parsers in a variety of contexts. > Every modern programming language has a URI or URL parse mechanism. > > Yes, but it is only concerned with parsers. The IETF is mostly concerned with protocols. Taking the example of LDAP, this relies on schemas where a URI is transported in a IA5String, which is ASCII-only (loosely, it's actually 7-bit ASCII supersets). Allowing non-ASCII breaks this, no matter how we wave magic wands about parsers - the parser simply never gets to see the URI, because the BER decoder (or whatever) throws an error. > Minor is in the eye of the beholder. What I am gathering is that changin= g > RFC 3986 -- even in ways that only break things "on paper" -- is > controversial. > > I suspect that there are at least two different change types possible. A) One is to change reserved "ASCII codepoints" within particular components of an IRI. I think this is pretty reasonable to explore, and is the kind of thing that your work with examining the behaviour of parsers is excellent for. The output of your work essentially informs us on the actual levels of risk involved, and allows us to consider "running code", which, with something as widespread in deployment as this is tremendously important. B) The other is to consider changes to the range of codepoints allowed in a URI (or IRI) as a whole. For a URI, this is highly controversial, and I don't believe it is possible. That said, we clearly do have the IRI specifications (and their bis drafts), and if there is interest from the W3C I think we could find the energy to complete that work. Changing the range within an IRI would, I suspect, be similarly controversial. Even if every parser in the world copes fine, it doesn't matter. Examples of (A) include the "[]" in query strings, "#" in fragments, and so on. These I'm personally open to in principle. (B) includes things like allowing non-ASCII in URI fragments (as opposed to IRI fragments). It would also include allowing spaces, line feeds, and so on. > I welcome everybody to participate in the discussion as to what W_URLs ma= p > to. > > I welcome discussion as to whether that mapping produces valid I_URIs. > > As to whether the changes necessary to the definition of I_URIs turn out > to be 'minor' or the end result being that W_URLs map to something that i= s > neither a proper superset or a proper subset of valid I_URIs is only > something we will know after those discussions take place. > > I _think_ there's an implication here that I at least had not been >> aware of in your previous references to "new URL(x).href". >> >> Is it in fact the case that the value of this expression (also I think >> what you've been calling the 'stringification' of a W_URL), _is_ >> exactly, byte for byte, what is put on the wire in HTTP requests by >> browsers? >> > > That is my understanding. To put it another way: if it is not, that woul= d > be considered a bug. > > Note that stringification produces a string of Unicode code points. As > all of those code points -- with the notable exception of fragments -- ar= e > a proper subset of US ASCII graphic characters, the mapping of such to > bytes is straightforward. > > At a minimum, the WHATWG/W3C specifications should be updated to make thi= s > clear. > How would you feel about the possibility of having an API that looked somewhat like this: Given: u =3D new URL(S) # Accepts strictly valid, and certain invalid, IRIs. u.href # "cleaned" valid IRI string, with any syntax cleaned according to rules. u.canonical # "canonical" IRI string. u.toASCII() # "cleaned" URI string, for use in HTTP, LDAP, etc. So with S as http://caf=C3=A9.im:80/t=C5=B7/%2e u.href =3D> http://caf=C3=A9.im:80/t=C5=B7/ . (although variants allowed) u.canonical =3D> http://caf=C3=A9.im/ty u.toASCII() =3D> http://xn--caf-dma.im/t%C5%B7 How hard would it be to persuade parser implementors to do this? Dave. --001a1139bcda0da1b6050cc55bc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A couple of points. I shall use= the terms "URI" and "IRI" as defined in the IETF specs= , and W_URL to mean the W3C/WHATWG/etc thing.

On 16 January 2015 at 12:54, Sam Ruby <rubys@intertwingly.net> wrote:
The WHATWG URL specification is not limited to browsers.=C2=A0 It d= efines a syntax that is fit for human production and consumption that is in= tended to be consistently parsed by a variety of parsers in a variety of co= ntexts.=C2=A0 Every modern programming language has a URI or URL parse mech= anism.


Yes, but it is only concerned with par= sers.

The IETF is mostly concerned with protocols.=

Taking the example of LDAP, this relies on schema= s where a URI is transported in a IA5String, which is ASCII-only (loosely, = it's actually 7-bit ASCII supersets).

Allowing= non-ASCII breaks this, no matter how we wave magic wands about parsers - t= he parser simply never gets to see the URI, because the BER decoder (or wha= tever) throws an error.
=C2=A0
I welcome everybody to participate in the discussion as to what W_URLs map = to.

I welcome discussion as to whether that mapping produces valid I_URIs.

As to whether the changes necessary to the definition of I_URIs turn out to= be 'minor' or the end result being that W_URLs map to something th= at is neither a proper superset or a proper subset of valid I_URIs is only = something we will know after those discussions take place.=

I _think_ there's an implication here that I at least had not been
aware of in your previous references to "new URL(x).href".

Is it in fact the case that the value of this expression (also I think
what you've been calling the 'stringification' of a W_URL), _is= _
exactly, byte for byte, what is put on the wire in HTTP requests by
browsers?

 That is my understanding.=C2=A0 To put it another way: if it is not, that w= ould be considered a bug.

Note that stringification produces a string of Unicode code points.=C2=A0 A= s all of those code points -- with the notable exception of fragments -- ar= e a proper subset of US ASCII graphic characters, the mapping of such to by= tes is straightforward.

At a minimum, the WHATWG/W3C specifications should be updated to make this = clear.

How would you feel about the pos= sibility of having an API that looked somewhat like this:

Given:

u =3D new URL(S) # Accepts strictly= valid, and certain invalid, IRIs.

u.href # =C2=A0= "cleaned" valid IRI string, with any syntax cleaned according to = rules.

u.canonical # "canonical" IRI str= ing.

u.toASCII() # "cleaned" URI string,= for use in HTTP, LDAP, etc.


u.href =3D> http://caf=C3=A9.im:80/t=C5=B7/. (although variants al= lowed)
u.canonical =3D> h= ttp://caf=C3=A9.im/ty

How hard would it be to persuade parser implementors to do this?

Dave.
--001a1139bcda0da1b6050cc55bc4-- From nobody Fri Jan 16 06:49:58 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBBA1ACD84 for ; Fri, 16 Jan 2015 06:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFxu9QEzfClf for ; Fri, 16 Jan 2015 06:49:53 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 EFDC11A6F2D for ; Fri, 16 Jan 2015 06:49:52 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AE25222E26C for ; Fri, 16 Jan 2015 09:49:49 -0500 (EST) Message-ID: <54B924B0.40105@seantek.com> Date: Fri, 16 Jan 2015 06:48:16 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020001050704060001000407" Archived-At: Subject: Re: [apps-discuss] Terminology and scope of [UI]Rx-like objects (was Re: What does it mean? (Re: Scope of RFC3986 and successor - what is a URI?)) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 14:49:56 -0000 This is a multi-part message in MIME format. --------------020001050704060001000407 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 1/16/2015 3:50 AM, Henry S. Thompson wrote: > I'm worried we've got unnecessarily confused and/or antagonistic > because we're not carefully distinguishing names and contexts of use. > > Context of use is crucial, if I understand the history and the > requirements behind the IETF specifications correctly. > > 3986 defines a low-level protocol element (hereafer 'I_URI'), for use > in protocols such as HTTP. I_URIs are restricted to ASCII, and have a > relatively conservative syntax intended to make the first-order > (scheme-independent) parsing of I_URIs easy. It is _not_ a > specification designed primarily for human authoring or reading. > > In consequence, over time, a number of alternative attempts to specify > more human-friendly presentation forms for I_URIs have arisen. IRIs > can be seen as such a form, although 3987 [1] is less than completely > clear about this. This aspect of 3987 is made explicit: > > "IRIs can serve as presentation elements for URI protocol elements. > An example would be an address bar in a Web user agent." [2] I just wanted to add 2=C2=A2. It is a feature of RFC 3986 that RFC 3986 plainly describes what URIs=20 are. Many IETF standards (and many standards in general) make normative=20 statements about what *generators* (senders) vs. *parsers* (receivers)=20 SHOULD or MUST do, where the parsing activity tends to be more lax than=20 the generating activity (Postel's Law). RFC 3986 does not do this. It=20 does not phrase things more strictly on the output side and less=20 strictly on the input side; furthermore, it doesn't even reference RFC 21= 19. Perhaps this is the source of some of the frustration on this list:=20 since RFC 3986 doesn't really say what happens when non-URI (e.g.,=20 non-ASCII, excess [ ] # ) characters are encountered; it doesn't provide = much guidance and thus becomes an area where implementations diverge if=20 they want to accept them rather than throw a parsing error. However it=20 is probably more accurate to say that implementations had long diverged=20 prior to RFC 3986, so RFC 3986 described what it could describe, rather=20 than prescribed what would not be followed anyway. The authors of RFC 3986 (who are on this list) can probably provide=20 insight into the matter. I dispute the characterization that "It is _not_ a specification=20 designed primarily for human authoring or reading." First of all I find RFC 3986 reasonably readable as far as standards go. = Second of all, human authoring and reading has *always* been a design=20 goal of URIs, ever since Tim Berners-Lee's original 1992 paper on UDI=20 (Universal Document Identifiers on the Network). The issue is that UDIs (URIs) were originally designed in a pre-Unicode=20 era, and notably are the most compatible in the modern English range=20 (i.e., US-ASCII). So, it is more appropriate to say that *English*=20 authoring and reading was a design goal, at the expense of other language= s. Thus in HTML 4.01: http://foo.org/H=C3=A5kon may be much more "readable" than http://foo.org/H%C3%A5kon but, to an average English speaker (who has no idea how to say "=C3=A5" i= n an=20 unambiguous way), saying or otherwise replicating http://foo.org/H=C3=A5kon will be very difficult if not impossible. But: http://foo.org/H%C3%A5kon is merely tedious; it's not impossible. And as for saying: "http://zh.wikipedia.org /wiki/=E5=B7=B4=E6=B3=B0=E5=8B=92=E7=B1=B3=C2=B7= =E6=B3=A2=E5=B2=A1=E9=81=94" =2E..for an English speaker? Fo'geddaboutit!!! Sean --------------020001050704060001000407 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 1/16/2015 3:50 AM, Henry S. Thompson wrote:
I'm worried we've got unnecessarily confused and/or antagonistic
because we're not carefully distinguishing names and contexts of use.

Context of use is crucial, if I understand the history and the
requirements behind the IETF specifications correctly.

3986 defines a low-level protocol element (hereafer 'I_URI'), for use
in protocols such as HTTP.  I_URIs are restricted to ASCII, and have a
relatively conservative syntax intended to make the first-order
(scheme-independent) parsing of I_URIs easy.  It is _not_ a
specification designed primarily for human authoring or reading.

In consequence, over time, a number of alternative attempts to specify
more human-friendly presentation forms for I_URIs have arisen.  IRIs
can be seen as such a form, although 3987 [1] is less than completely
clear about this.  This aspect of 3987 is made explicit:

  "IRIs can serve as presentation elements for URI protocol elements.
   An example would be an address bar in a Web user agent." [2]

I just wanted to add 2¢.

It is a feature of RFC 3986 that RFC 3986 plainly describes what URIs are. Many IETF standards (and many standards in general) make normative statements about what generators (senders) vs. parsers (receivers) SHOULD or MUST do, where the parsing activity tends to be more lax than the generating activity (Postel's Law). RFC 3986 does not do this. It does not phrase things more strictly on the output side and less strictly on the input side; furthermore, it doesn't even reference RFC 2119.

Perhaps this is the source of some of the frustration on this list: since RFC 3986 doesn't really say what happens when non-URI (e.g., non-ASCII, excess [ ] # ) characters are encountered; it doesn't provide much guidance and thus becomes an area where implementations diverge if they want to accept them rather than throw a parsing error. However it is probably more accurate to say that implementations had long diverged prior to RFC 3986, so RFC 3986 described what it could describe, rather than prescribed what would not be followed anyway.

The authors of RFC 3986 (who are on this list) can probably provide insight into the matter.

I dispute the characterization that "It is _not_ a specification designed primarily for human authoring or reading."

First of all I find RFC 3986 reasonably readable as far as standards go. Second of all, human authoring and reading has always been a design goal of URIs, ever since Tim Berners-Lee's original 1992 paper on UDI (Universal Document Identifiers on the Network).

The issue is that UDIs (URIs) were originally designed in a pre-Unicode era, and notably are the most compatible in the modern English range (i.e., US-ASCII). So, it is more appropriate to say that English authoring and reading was a design goal, at the expense of other languages.

Thus in HTML 4.01:
http://foo.org/Håkon
may be much more "readable" than
http://foo.org/H%C3%A5kon
but, to an average English speaker (who has no idea how to say "å" in an unambiguous way), saying or otherwise replicating
http://foo.org/Håkon
will be very difficult if not impossible. But:
http://foo.org/H%C3%A5kon
is merely tedious; it's not impossible.

And as for saying:
"http://zh.wikipedia.org /wiki/巴泰勒米·波岡達"
...for an English speaker? Fo'geddaboutit!!!

Sean
--------------020001050704060001000407-- From nobody Fri Jan 16 07:14:03 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BED51ACD1E for ; Fri, 16 Jan 2015 07:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQJGDPuGZbtO for ; Fri, 16 Jan 2015 07:13:56 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id EC5741A924C for ; Fri, 16 Jan 2015 07:13:55 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id t0GFDrDx005575; Fri, 16 Jan 2015 15:13:53 GMT 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 t0GFDsvA006841; Fri, 16 Jan 2015 15:13:54 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t0GFDssw014261; Fri, 16 Jan 2015 15:13:54 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id t0GFDrcA014257; Fri, 16 Jan 2015 15:13:53 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Sean Leonard References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <54B924B0.40105@seantek.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 16 Jan 2015 15:13:53 +0000 In-Reply-To: <54B924B0.40105@seantek.com> (Sean Leonard's message of "Fri\, 16 Jan 2015 06\:48\:16 -0800") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Terminology and scope of [UI]Rx-like objects X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 15:14:00 -0000 Sean Leonard writes: > I dispute the characterization that "It is _not_ a specification > designed primarily for human authoring or reading." > > First of all I find RFC 3986 reasonably readable as far as standards > go. Oops :-). Of course, I didn't mean that the _standard_ wasn't meant for human readers, but that the I_URIs it was _defining_ were not primarily so intended. > Second of all, human authoring and reading has *always* been a > design goal of URIs, ever since Tim Berners-Lee's original 1992 paper > on UDI (Universal Document Identifiers on the Network). The distinction between higher- (human-facing) contexts and lower-level (network-traversing) protocols wasn't there in the beginning for XXIs, that's for sure. > The issue is that UDIs (URIs) were originally designed in a > pre-Unicode era, and notably are the most compatible in the modern > English range (i.e., US-ASCII). So, it is more appropriate to say that > *English* authoring and reading was a design goal, at the expense of > other languages. It has become increasingly necessary to take the distinction I'm concerned with seriously as time has gone by, not just because of the advent of UCS, but because of the expanded requirements of the human-facing context of use. I'm thinking here particularly of the status of the space character. 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] From nobody Fri Jan 16 07:43:31 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177DB1ACE17 for ; Fri, 16 Jan 2015 07:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.425 X-Spam-Level: X-Spam-Status: No, score=0.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTTP_ESCAPED_HOST=1.125, J_CHICKENPOX_14=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBOkcFyVDAw8 for ; Fri, 16 Jan 2015 07:43:28 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.229]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF8F1ACDC7 for ; Fri, 16 Jan 2015 07:43:28 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:50252] helo=rubix) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id C7/C1-25206-F9139B45; Fri, 16 Jan 2015 15:43:27 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id A6C05140B5F; Fri, 16 Jan 2015 10:43:27 -0500 (EST) Message-ID: <54B9319F.8020900@intertwingly.net> Date: Fri, 16 Jan 2015 10:43:27 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Dave Cridland References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <54B8F74A.70601@intertwingly.net> <54B909F4.4020908@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] What does it mean? (Re: Scope of RFC3986 and successor - what is a URI?) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 15:43:30 -0000 On 01/16/2015 08:57 AM, Dave Cridland wrote: > > Taking the example of LDAP, this relies on schemas where a URI is > transported in a IA5String, which is ASCII-only (loosely, it's actually > 7-bit ASCII supersets). > > Allowing non-ASCII breaks this, no matter how we wave magic wands about > parsers - the parser simply never gets to see the URI, because the BER > decoder (or whatever) throws an error. You and I have different ideas of "magic wands". I will also note that I personally dislike this style of discourse. Whatever they are called (URI, IRI, URL), as commonly practiced they may contain fragments and those fragments may contain bytes with the high order bit on. The exists specs that make claims that such values aren't valid. There exists software components (e.g. parses) that purport to convert URIs, IRIs, or URLs into spec compliant strings. As a general rule, they do things differently. In particular, most leave fragments alone. Even when they contain characters with a high order bit on. People who read such specs and the high level descriptions of said software components may indeed be mislead into designing schema choosing the wrong type of string[1], and that choice will cause runtime failures to occur. Given the above, and using your term ("magic wand"), it is my belief that the attempt to invoke "magic" occurs in the existing specification, and that the choice to do so does a disservice to the readers. Note: it would be presumptuous of me to assume that my perception of where the "magic wand" occurs in this scenario is shared with you. Please permit me the same courtesy. > That said, we clearly do have the > IRI specifications (and their bis drafts), and if there is interest from > the W3C I think we could find the energy to complete that work. Finding the energy to complete the IRI work would indeed be a game changer. At the moment, I'm skeptical, but suffice it to say that I would be very interested if that came to pass. Until that time, my intent I view with skepticism any and all use of the term IRI. > How would you feel about the possibility of having an API that looked > somewhat like this: > > Given: > > u = new URL(S) # Accepts strictly valid, and certain invalid, IRIs. > > u.href # "cleaned" valid IRI string, with any syntax cleaned according > to rules. > > u.canonical # "canonical" IRI string. > > u.toASCII() # "cleaned" URI string, for use in HTTP, LDAP, etc. > > So with S as http://café.im:80/tŷ/%2e > > u.href => http://café.im:80/tŷ/ . > (although variants allowed) The current (and widely deployed) definition of href would produce exactly what you define as toASCII below. And, in fact, is used for HTTP. > u.canonical => http://café.im/ty The use case for this would need to be provided. > u.toASCII() => http://xn--caf-dma.im/t%C5%B7 Again, this result is indistinguishable from .href. > How hard would it be to persuade parser implementors to do this? The canonical case concerns me most, as it is both a lot of work and there doesn't seem to be agreement as to what canonicalization means. See: http://intertwingly.net/blog/2004/07/31/URI-Equivalence Those results were produced over a decade ago. I reran those tests recently, and saw zero change. :-( > Dave. - Sam Ruby [1] http://www.zytrax.com/books/ldap/apa/types.html#strings From nobody Fri Jan 16 08:11:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF711ACDDC for ; Fri, 16 Jan 2015 08:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.016 X-Spam-Level: X-Spam-Status: No, score=-1.016 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_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3A6bYSGNSAn3 for ; Fri, 16 Jan 2015 08:11:13 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7F81ACE71 for ; Fri, 16 Jan 2015 08:11:09 -0800 (PST) Received: by mail-qg0-f41.google.com with SMTP id e89so16949616qgf.0 for ; Fri, 16 Jan 2015 08:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:from:to:cc:subject:importance:date :in-reply-to:references:content-type; bh=93OOdxSHVnQQqyJVztrBq49KOsaszCSWgTCT7XJc4n0=; b=TEDX35MFA2sclr6iKNiW9BJiPwJpPKVZJasevqK9YcodnYClwYalCgAjr2uMTF8m5x KXMZJl0m8cKtsAIVIENlbvJ+B2+lIA1KsguiUzMmlVYeUFmVniIZAmZxgOgD8cPOQoZ4 7nd16q97Xj+0f04EaJJHAOIR/qPwLC775NHEC39avvhOZh6zCA+gsCvErnbDbhndd+ED qDJYuDmyK4Wg95yhjfl0iMG7XBpGLXxG0S0/xIXxAHkQpY5DSwO5uF5VDG8xznJuchUk PVs7e7lkEvJNbbdjafri+Kl+WVdTaU3AdZJVo6XdRYwPKoeyeu08g2yTOtb5Ow8+6mEv VFLQ== X-Received: by 10.229.249.137 with SMTP id mk9mr26396638qcb.4.1421424668218; Fri, 16 Jan 2015 08:11:08 -0800 (PST) Received: from Pecan (bas11-montreal02-1128535737.dsl.bell.ca. [67.68.22.185]) by mx.google.com with ESMTPSA id r12sm4487707qax.38.2015.01.16.08.11.06 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 16 Jan 2015 08:11:07 -0800 (PST) Message-ID: <54b9381b.8ca1e00a.243f.ffffcae4@mx.google.com> MIME-Version: 1.0 From: To: =?utf-8?Q?Dave_Cridland?= , =?utf-8?Q?Sam_Ruby?= Importance: Normal Date: Fri, 16 Jan 2015 16:05:44 +0000 In-Reply-To: References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A557E1.6050502@intertwingly.net> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B806A2.8020803@intertwingly.net>, Content-Type: multipart/alternative; boundary="_53EBFE67-6DDA-44A9-9EE8-447F0D5F1BD5_" Archived-At: Cc: =?utf-8?Q?IETF_Apps_Discuss?= Subject: Re: [apps-discuss] =?utf-8?q?Scope_of_RFC3986_and_successor_-_what_is?= =?utf-8?q?_a_URI=3F?= X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 16:11:16 -0000 --_53EBFE67-6DDA-44A9-9EE8-447F0D5F1BD5_ Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" Pj5TYW0gUnVieSB3cm90ZToNCg0KPj4NCj4+QW4gZXhhbXBsZSBvZiBzb21ldGhpbmcgdGhhdCBp cyBub3QgYSBjb25mb3JtaW5nIFVSTCwgYnV0IGlzIGJvdGggYSB2YWxpZCBVUkkgYW5kIGEgdmFs aWQgSVJJOg0KPj4NCj4+ICBodHRwOi8vMjU3LjI1Ny4yNTcuMjU3Lw0KPg0KDQoNCj5EYXZlIENy aWRsYW5kIHdyb3RlOg0KDQoNCj5PSy4uLiBJIGRvbid0IHRoaW5rIHRoYXQncyB2YWxpZCwgYnV0 IGl0J3MgcHJvYmFibHkgdmFsaWQgYWNjb3JkaW5nIHRvIHRoZSBBQk5GIG9ubHkgKGlnbm9yaW5n IHRoZSBwcm9zZSkuIEkgdGhpbmsgPnNwZWNpZnlpbmcgdGhhdCBpbiB0aGUgZm9ybWFsIHN5bnRh eCB3b3VsZCBiZSB1bmNvbnRlbnRpb3VzIC0gaW4gZmFjdCwgZHJhZnQtaWV0Zi1pcmktMzk4N2Jp cy0xMyBhbHJlYWR5IG1ha2VzID50aGlzIGNoYW5nZS4NCg0KDQpJdCBpcyBub3QgZXZlbiB2YWxp ZCBiYXNlZCBvbiB0aGUgQUJORiwgZHVlIHRvIGEgZmFpcmx5IGNyZWF0aXZlIGRlZmluaXRpb24g b2YgZGVjLW9jdGV0Lg0KDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzOTg2I3Nl Y3Rpb24tMy4yLjINCg0KDQpEYXJyZWwNCg0KDQoNCg0KDQoNCkZyb206IERhdmUgQ3JpZGxhbmQN ClNlbnQ6IOKAjlRodXJzZGF54oCOLCDigI5KYW51YXJ54oCOIOKAjjE14oCOLCDigI4yMDE1IOKA jjXigI464oCOMDnigI4g4oCOUE0NClRvOiBTYW0gUnVieQ0KQ2M6IElFVEYgQXBwcyBEaXNjdXNz DQoNCg0KDQoNCg0KDQoNCk9uIDE1IEphbnVhcnkgMjAxNSBhdCAxODoyNywgU2FtIFJ1YnkgPHJ1 YnlzQGludGVydHdpbmdseS5uZXQ+IHdyb3RlOg0KDQpHb29kIHF1ZXN0aW9uLiAgUGxlYXNlIGZv cmdpdmUgdGhlIGxlbmd0aHkgYW5zd2VyLg0KDQoNCg0KDQoNCg0KTGVuZ3RoeSBpcyBmaW5lLg0K DQogDQoNCkxldHMgcG9zaXQgdGhlIGV4aXN0ZW5jZSBvZiBhIFdfVVJMIHBhcnNlci4gIEdpdmVu IGEgc3RyaW5nLCBpdCBwcm9kdWNlcyBhbiBvYmplY3QuICBPbmUgb2YgdGhlIG9wZXJhdGlvbnMg dGhhdCBvYmplY3QgcGVyZm9ybXMgaXMgInN0cmluZ2lmaWNhdGlvbiIgKGFuIElETCB0ZXJtIHRo YXQgSSBkb24ndCBwYXJ0aWN1bGFybHkgY2FyZSBmb3Igd2hpY2ggZXNzZW50aWFsbHkgbWVhbnMg c2VyaWFsaXphdGlvbiB0byBhIHN0cmluZyBmb3JtKS4NCg0KIC0gLSAtDQoNCklmIHlvdSBsb29r IGF0IHRoZSBzZXF1ZW5jZSBvZiBvcGVyYXRpb25zOiBwYXJzZSBmb2xsb3dlZCBieSBzdHJpbmdp ZmljYXRpb24sIHlvdSBnZXQgYSBzdHJpbmcgdHJhbnNmb3JtYXRpb24uDQoNClRoaXMgY2FuIGJl IGFuIGlkZW50aXR5IHRyYW5zZm9ybS4gIElmIHlvdSB3YW50LCB0cnkgdGhlIGZvbGxvd2luZyBp biBGaXJlZm94IG9yIENocm9tZSdzIGNvbnNvbGU6DQoNCiAgbmV3IFVSTCgnaHR0cDovL2V4YW1w bGUuY29tLycpLmhyZWYgPT0gJ2h0dHA6Ly9leGFtcGxlLmNvbS8nDQoNClRoZSByZXN1bHQgd2ls bCBiZSB0cnVlLg0KDQpUaGUgcmVzdWx0IGNhbiBiZSBzb21lIHRyYW5zZm9ybWF0aW9uLiAgRm9y IGV4YW1wbGU6DQoNCiAgbmV3IFVSTCgnSFRUUDovL0VYQU1QTEUuQ09NL1BBVEgnKS5ocmVmID09 ICdodHRwOi8vZXhhbXBsZS5jb20vUEFUSCcNCg0KRmluYWxseSwgdGhlIHJlc3VsdCBjYW4gYmUg dG8gZ2l2ZSB1cC4NCg0KICBuZXcgVVJMKCdodHRwOi8vZXhhbXBsZS5jb206cG9ydC8nKQ0KDQpC b3RoIEZpcmVmb3ggYW5kIENocm9tZSB0aHJvdyBhbiBleGNlcHRpb24uDQoNCiAtIC0gLQ0KDQpO b3cgaWYgeW91IHRha2UgYSBsb29rIGF0IHRoYXQgdHJhbnNmb3JtYXRpb24sIHdlIGNhbiBkaXNj dXNzIHRoZSB3aGF0IHNob3VsZCBiZSBkZXNpcmFibGUgY2hhcmFjdGVyaXN0aWNzIG9mIHRoZSBz ZXQgb2Ygb3V0cHV0cy4NCg0KVGhlIGZpcnN0IGNoYXJhY3RlcmlzdGljIHRoYXQgSSB3b3VsZCBs aWtlIHRvIHN1Z2dlc3QgaXMgdGhhdCB0aGUgb3V0cHV0cyByb3VuZCB0cmlwLCBhbmQgYnkgdGhh dCBJIG1lYW4gdGhhdCBpZiB5b3UgZmVlZCB0aGF0IG91dHB1dCBiYWNrIGludG8gdGhlIHRyYW5z Zm9ybWF0aW9uLCB5b3UgZ2V0IHRoZSBzYW1lIHJlc3VsdCBiYWNrLg0KDQoNCg0KDQoNCg0KT0s7 IHlvdSdyZSBzYXlpbmcgdGhhdCBmb3IgYW55IFVSTCBzdHJpbmcgUywgbmV3IFVSTChuZXcgVVJM KFMpLmhyZWYpLmhyZWYgPT0gbmV3IFVSTChTKS5ocmVmDQoNCg0KDQoNCllvdXIgdGVzdHMgc2Vl bSB0byBpbXBseSB0aGF0IGZvciBhbnkgVVJMIHN0cmluZyBTLCB0aGVyZSBpcyBvbmUgYW5kIG9u bHkgb25lIGNvcnJlY3QgdmFsdWUgb2YgKG5ldyBVUkwoUykuaHJlZik7IGlzIHRoYXQgYWxzbyB0 aGUgY2FzZT8NCg0KDQoNCg0KVG8gcHV0IGl0IGFub3RoZXIgd2F5LCB5b3VyIHRlc3RzIGltcGx5 IGEgY2Fub25pY2FsIGZvcm0gZm9yIGEgVVJJLCBhbmQgdGhhdCBzZWVtcyBtdWNoIG1vcmUgdXNl ZnVsLg0KDQogDQoNClRoZSBzZWNvbmQgY2hhcmFjdGVyaXN0aWMgaXMgdGhhdCBpdCBhY3R1YWxs eSB3b3Jrcy4gIFRoaXMgaXNuJ3QgYSBwcmVjaXNlbHkgc3BlY2lmaWVkIGNyaXRlcmlhLCBidXQg aXQgbWVhbnMgdGhhdCBpZiB5b3UgYXR0ZW1wdCB0byB1c2UgdGhlIHJlc3VsdCBpdCBkb2Vzbid0 IGJyZWFrIGFueXRoaW5nLiAgT25lIGV4YW1wbGUgb2YgdGhpcyB3b3VsZCBiZSBwbGFjaW5nIHRo ZSBzdHJpbmcgJ2h0dHA6Ly9pZXRmLm9yZy8nIGludG8gdGhlIGhyZWYgYXR0cmlidXRlIG9mIGFu IEhUTUwgPGE+IGVsZW1lbnQsIHJlbmRlcmluZyBpdCBvbiB0aGUgc2NyZWVuLCBhbmQgaGF2aW5n IHNvbWVib2R5IGNsaWNrIG9uIHRoZSBsaW5rLiAgSWYgdGhpcyBnb2VzIHRvIHRoZSByaWdodCBw bGFjZSwgdGhlbiBhbGwgaXMgZ29vZC4gIFRoZSBkZWZpbml0aW9uIG9mICJ3b3JrcyIgZm9yIGRh dGE6IFctVVJMcywgYW5kIGZvciBqYXZhc2NyaXB0OiBXLVVSTHMgYXJlIGRpZmZlcmVudCwgYnV0 IHRoYXQncyBub3QgYW4gb2JzdGFjbGUgYXQgdGhpcyBsZXZlbCBvZiBkaXNjdXNzaW9uLg0KDQoN Cg0KDQoNCg0KSSBjYW4gcmVhZGlseSBhcHByZWNpYXRlIHRoZSBzZW50aW1lbnQgaGVyZTsgbGlr ZSBtYW55IHRoaW5ncywgaXQncyBoYXJkIHRvIHNwZWNpZnkuIEJ1dCB3aGF0IHlvdSdyZSBzYXlp bmcgaXMgdGhhdCBmb3IgYW55IFVSTCBzdHJpbmcgUywgd2hlcmUgKG5ldyBVUkwoUykuaHJlZikg ZG9lcyBub3QgcHJvZHVjZSBhbiBlcnJvciwgdGhlIHJlc3VsdCBtdXN0IGJlIGEgc2VtYW50aWNh bGx5IHZhbGlkIFVSTCBzdHJpbmc/IChpJ20gYmVpbmcgZGVsaWdodGZ1bGx5IHdvb2x5IGFib3V0 ICJzZW1hbnRpY2FsbHkgdmFsaWQiKS4NCg0KIA0KDQogLSAtIC0NCg0KQXQgdGhpcyBwb2ludCwg SSdtIHRyb3VibGVkLiAgRGVzcGl0ZSB0aGUgc2V0IG9mIGRlc2lyYWJsZSBjaGFyYWN0ZXJpc3Rp Y3MgSSBoYXZlIHNwZWNpZmllZCwgSSBoYXZlIGEgd2VsbCBkZWZpbmVkIHNldCB3aGljaCBpcyBu ZWl0aGVyIGEgc3VwZXJzZXQgb2YgSS1VUkkncyBub3IgSS1JUkkncywgbm9yIGEgcHJvcGVyIHN1 YnNldCBvZiBlaXRoZXIuDQoNCkFuIGV4YW1wbGUgb2Ygc29tZXRoaW5nIHRoYXQgaXMgbm90IGEg Y29uZm9ybWluZyBVUkwsIGJ1dCBpcyBib3RoIGEgdmFsaWQgVVJJIGFuZCBhIHZhbGlkIElSSToN Cg0KICBodHRwOi8vMjU3LjI1Ny4yNTcuMjU3Lw0KDQoNCg0KDQoNCg0KT0suLi4gSSBkb24ndCB0 aGluayB0aGF0J3MgdmFsaWQsIGJ1dCBpdCdzIHByb2JhYmx5IHZhbGlkIGFjY29yZGluZyB0byB0 aGUgQUJORiBvbmx5IChpZ25vcmluZyB0aGUgcHJvc2UpLiBJIHRoaW5rIHNwZWNpZnlpbmcgdGhh dCBpbiB0aGUgZm9ybWFsIHN5bnRheCB3b3VsZCBiZSB1bmNvbnRlbnRpb3VzIC0gaW4gZmFjdCwg ZHJhZnQtaWV0Zi1pcmktMzk4N2Jpcy0xMyBhbHJlYWR5IG1ha2VzIHRoaXMgY2hhbmdlLg0KDQoN Cg0KDQpTaW1pbGFybHksIGh0dHA6Ly8xMjcuMC4wLjE6NjU1MzYvIGlzIGFsc28gbm90IHZhbGlk LCBidXQgYmVjYXVzZSB0aGUgY29uY2VwdCBvZiBwb3J0IGlzIG5vdCB0aWVkIHRvIGEgc3BlY2lm aWMgdHJhbnNwb3J0IHByb3RvY29sLCBhbmQgbWlnaHQgbm90IGJlIHJlc3RyaWN0ZWQgdG8gYSAx Ni1iaXQgcmFuZ2UsIHRoYXQncyBhIGhhcmRlciBvbmUgdG8gY2FwdHVyZSBpbiBwdXJlIEFCTkYg LSB0aGF0IGlzLCB0aGUgcGVybWlzc2FibGUgdmFsdWVzIG9mIHBvcnQgYXJlIGFyZ3VhYmx5IHNj aGVtZSBzcGVjaWZpYy4NCg0KDQoNCg0KQm90aCB0aGVzZSBhcmUgaXNzdWVzIG9mIHdoYXQgSSBj YWxsZWQgc2VtYW50aWMgdmFsaWRpdHkgYWJvdmUuIE90aGVycyBwcm9iYWJseSBleGlzdC4NCg0K IA0KDQpIZXJlIGlzIHNvbWV0aGluZyB0aGF0IHJvdW5kLXRyaXBzIGEgVVJMIHBhcnNlL3N0cmlu Z2lmeSB0cmFuc2Zvcm1hdGlvbiwgYW5kIGFjdHVhbGx5IHdvcmtzLCBkZXNwaXRlIGJlaW5nIGFu IGludmFsaWQgVVJJIGFuZCBpbnZhbGlkIElSSToNCg0KICBodHRwczovL3d3dy5nb29nbGUuY29t Lz9xPVt6XQ0KDQoNCg0KDQoNCg0KTXkgZ3V0IGZlZWxpbmcgaXMgdGhhdCBhbGxvd2luZyB0aGlz IHRvIGJlIHZhbGlkIGlzIGEgcG9zc2libGUgY2hhbmdlLCBhcyBJJ3ZlIHNhaWQuIEkgYXBwcmVj aWF0ZSB0aGlzIGlzIGF0IG9kZHMgd2l0aCBSRkMgMzk4NiwgYnV0IGlmIFVSTCBwYXJzZXJzIGRv IGdlbmVyYWxseSBpZ25vcmUgdGhlIGVycm9yIHRoYXQncyBmaW5lLg0KDQogDQoNClRvIGZ1cnRo ZXIgY29tcG91bmQgdGhpcywgUkZDIDM5ODYgY2xhaW1zIHRoYXQgdGhlIGZvbGxvd2luZyBzdHJp bmdzIGFyZSB0byBiZSB0cmVhdGVkIGFzIGVxdWl2YWxlbnQgKGFuZCBwZXJoYXBzIGV2ZW4gcHJl ZmVycmVkIGFzIHRoZXkgYXJlIGRlZW1lZCB0byBiZSAndmFsaWQnKToNCg0KICBodHRwczovL3d3 dy5nb29nbGUuY29tLz9xPSU1QnolNUQNCiAgaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8/cT0lNWJ6 JTVkDQoNCkluZGVlZCBpbiBtYW55LCBhbmQgZ2VuZXJhbGx5IG1vc3QsIHNpdHVhdGlvbnMsIHRo b3NlIGFyZSBjb25zaWRlcmVkIGVxdWl2YWxlbnQuICBCdXQgdGhpcyBpcyBub3QgbmVjZXNzYXJp bHkgc28uICBUbyBpdCdzIGNyZWRpdCBSRkMgMzk4NiBkb2VzIGRlc2NyaWJlIGEgQ29tcGFyaXNv biBMYWRkZXIuICBVbmZvcnR1bmF0ZWx5IGl0IGRvZXMgc28gdXNpbmcgdGVybXMgbGlrZSAiZmFs c2UgcG9zaXRpdmVzIiBhbmQgImZhbHNlIG5lZ2F0aXZlcyIgd2hlbiBpbiBmYWN0LCB0aGV5IGFy ZW4ndCBmYWxzZSBhdCBhbGwuDQoNCg0KDQoNCg0KDQpJIHRoaW5rIHRoYXQgdGhpcyB3b3VsZCBk aXNhcHBlYXIsIGxhcmdlbHksIHdpdGggYSBjYW5vbmljYWwgZm9ybS4gUkZDIDM5ODYgY3VycmVu dGx5IHNheXMgdGhhdCBwY3QtZW5jb2RlZCBzaG91bGQgdXNlIHVwcGVyIGNhc2UgLSB0aGF0J3Mg YSBsb3dlciBjYXNlICJzaG91bGQiIC0gYW5kIGlmIHdlIHRha2UgdGhpcyB0byBiZSBhIGNhbm9u aWNhbCBmb3JtLCB0aGVuIHRoZSBsYXR0ZXIgY2Fub25pY2FsaXplcyB0byB0aGUgZm9ybWVyLCBh bmQgd2Ugd2luLiBPZiBjb3Vyc2UsIGlmIFtdIGlzIG1hZGUgbGVnYWwgaW4gdGhlIHF1ZXJ5IHN0 cmluZyBpdCdkIGNhbm9uaWNhbGl6ZSB0byB0aGUgcHJldmlvdXMgZXhhbXBsZS4NCg0KDQoNCg0K Q29tcGFyaXNvbiBvZiBVUklzIHRoZW4gYmVjb21lIGEgY2FzZSBvZiBjb21wYXJpbmcgdGhlIGNh bm9uaWNhbGl6ZWQgdmVyc2lvbnMgb2YgYm90aC4NCg0KDQoNCg0KVGhpcyBpcyBwcm9ibGVtYXRp YyBpbiB0aGUgY2FzZSBvZiBwb3J0cyAtIHNpbmNlIGh0dHA6Ly93d3cuZ29vZ2xlLmNvbTo4MC8g YW5kIGh0dHA6Ly93d3cuZ29vZ2xlLmNvbS8gYm90aCByZWZlciB0byB0aGUgc2FtZSB0aGluZywg YnV0IHRvIGhhdmUgYSBzaW5nbGUgY2Fub25pY2FsIGZvcm0gZm9yIGJvdGggd291bGQgcmVxdWly ZSB0aGUgcGFyc2VyIHRvIGJlIGF3YXJlIG9mIHRoZSBkZWZhdWx0IHBvcnQgZm9yIHRoZSBzY2hl bWUuIEJ1dCBtYXliZSB1bmtub3duIHNjaGVtZXMgY2Fubm90IGJlIGNhbm9uaWNhbGl6ZWQsIG9y IG1heWJlIHdlIGhhdmUgdHdvIGNhbm9uaWNhbCBmb3Jtcy4gKFNjaGVtZS1hd2FyZSBhbmQgc2No ZW1lLWFnbm9zdGljOyBvYnZpb3VzbHkgeW91J2Qgc3BlY2lmeSB3aGljaCB5b3Ugd2FudCBhbmQg d2hlcmUpLg0KDQogDQoNCiAtIC0gLQ0KDQpTbyBtdWNoIGZvciBhIGRlZXAgZGl2ZS4gIFJldHVy bmluZyB0byB0aGUgc3VyZmFjZTogSSdkIGxpa2UgdG8gc2ltdWx0YW5lb3VzbHkgbG9vc2VuIHVw IHRoZSBkZWZpbml0aW9uIG9mIHZhbGlkaXR5IGZvciBJLVVSSSdzIGluIHNvbWUgcGxhY2VzIHdo aWxlIHRpZ2h0ZW5pbmcgaXQgdXAgaW4gb3RoZXJzLiAgVGhpcyBpcyBhIHdvcmsgaW4gcHJvZ3Jl c3MsIHNvIHdoaWNoIEkgY2FuJ3Qgc2F5IGV4YWN0bHkgd2hlcmUganVzdCB5ZXQgaW4gZWFjaCBj YXNlLCBJIGNhbiBzYXkgdGhhdCBub3cgd291bGQgYmUgYSBnb29kIHRpbWUgZm9yIGludGVyZXN0 ZWQgcGFydGllcyB0byBwYXJ0aWNpcGF0ZS4NCg0KDQpodA0KDQoNCi0gU2FtIFJ1YnkNCg0KDQpb MV0gaHR0cHM6Ly91cmwuc3BlYy53aGF0d2cub3JnLywgYXMgb2YgMjAxNS0wMS0xNQ0KDQoNCg0K DQogX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmFwcHMt ZGlzY3VzcyBtYWlsaW5nIGxpc3QNCmFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3M= --_53EBFE67-6DDA-44A9-9EE8-447F0D5F1BD5_ Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" CjxodG1sPgo8aGVhZD4KPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJXaW5kb3dzIE1h aWwgMTcuNS45NjAwLjIwNjg5Ij4KPHN0eWxlIGRhdGEtZXh0ZXJuYWxzdHlsZT0idHJ1ZSI+PCEt LQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFy YWdyYXBoIHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdodDowaW47Cm1hcmdpbi1ib3R0b206 MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbCB7Cm1hcmdpbjowaW47Cm1hcmdpbi1ib3R0 b206LjAwMDFwdDsKfQpwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIGxpLk1zb0xpc3RQYXJh Z3JhcGhDeFNwRmlyc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCAKcC5Nc29MaXN0 UGFyYWdyYXBoQ3hTcE1pZGRsZSwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIGRpdi5N c29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgCnAuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBs aS5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3Qg ewptYXJnaW4tdG9wOjBpbjsKbWFyZ2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTowaW47Cm1h cmdpbi1sZWZ0Oi41aW47Cm1hcmdpbi1ib3R0b206LjAwMDFwdDsKbGluZS1oZWlnaHQ6MTE1JTsK fQotLT48L3N0eWxlPjwvaGVhZD4KPGJvZHkgZGlyPSJsdHIiPgo8ZGl2IGRhdGEtZXh0ZXJuYWxz dHlsZT0iZmFsc2UiIGRpcj0ibHRyIiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDYWxpYnJpJywgJ1Nl Z29lIFVJJywgJ01laXJ5bycsICdNaWNyb3NvZnQgWWFIZWkgVUknLCAnTWljcm9zb2Z0IEpoZW5n SGVpIFVJJywgJ01hbGd1biBHb3RoaWMnLCAnc2Fucy1zZXJpZic7Zm9udC1zaXplOjEycHQ7Ij48 ZGl2PiZndDsmZ3Q7U2FtIFJ1Ynkgd3JvdGU6PC9kaXY+PGRpdj4mZ3Q7Jmd0Ozxicj4KJmd0OyZn dDtBbiBleGFtcGxlIG9mIHNvbWV0aGluZyB0aGF0IGlzIG5vdCBhIGNvbmZvcm1pbmcgVVJMLCBi dXQgaXMgYm90aCBhIHZhbGlkIFVSSSBhbmQgYSB2YWxpZCBJUkk6PGJyPgomZ3Q7Jmd0Ozxicj4K Jmd0OyZndDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovLzI1Ny4yNTcuMjU3LjI1Ny8iIHRhcmdldD0i X3BhcmVudCI+aHR0cDovLzI1Ny4yNTcuMjU3LjI1Ny88L2E+PGJyPgomZ3Q7PGJyPjwvZGl2Pjxk aXY+Jmd0O0RhdmUgQ3JpZGxhbmQgd3JvdGU6PGJyPjwvZGl2PjxkaXY+Jmd0O09LLi4uIEkgZG9u J3QgdGhpbmsgdGhhdCdzIHZhbGlkLCBidXQgaXQncyBwcm9iYWJseSB2YWxpZCBhY2NvcmRpbmcg dG8gdGhlIEFCTkYgb25seSAoaWdub3JpbmcgdGhlIHByb3NlKS4gSSB0aGluayAmZ3Q7c3BlY2lm eWluZyB0aGF0IGluIHRoZSBmb3JtYWwgc3ludGF4IHdvdWxkIGJlIHVuY29udGVudGlvdXMgLSBp biBmYWN0LCZuYnNwO2RyYWZ0LWlldGYtaXJpLTM5ODdiaXMtMTMgYWxyZWFkeSBtYWtlcyAmZ3Q7 dGhpcyBjaGFuZ2UuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JdCBpcyBub3QgZXZlbiB2YWxp ZCBiYXNlZCBvbiB0aGUgQUJORiwgZHVlIHRvIGEgZmFpcmx5IGNyZWF0aXZlIGRlZmluaXRpb24g b2YgZGVjLW9jdGV0LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzM5ODYjc2VjdGlvbi0zLjIuMiIgdGFyZ2V0PSJfcGFyZW50 Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzk4NiNzZWN0aW9uLTMuMi4yPC9hPjwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+RGFycmVsPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdiBzdHlsZT0icGFkZGluZy10b3A6IDVweDsgYm9yZGVyLXRvcC1jb2xvcjog cmdiKDIyOSwgMjI5LCAyMjkpOyBib3JkZXItdG9wLXdpZHRoOiAxcHg7IGJvcmRlci10b3Atc3R5 bGU6IHNvbGlkOyI+PGRpdj48Zm9udCBmYWNlPSIgJ0NhbGlicmknLCAnU2Vnb2UgVUknLCAnTWVp cnlvJywgJ01pY3Jvc29mdCBZYUhlaSBVSScsICdNaWNyb3NvZnQgSmhlbmdIZWkgVUknLCAnTWFs Z3VuIEdvdGhpYycsICdzYW5zLXNlcmlmJyIgc3R5bGU9J2xpbmUtaGVpZ2h0OiAxNXB0OyBsZXR0 ZXItc3BhY2luZzogMC4wMmVtOyBmb250LWZhbWlseTogIkNhbGlicmkiLCAiU2Vnb2UgVUkiLCAi TWVpcnlvIiwgIk1pY3Jvc29mdCBZYUhlaSBVSSIsICJNaWNyb3NvZnQgSmhlbmdIZWkgVUkiLCAi TWFsZ3VuIEdvdGhpYyIsICJzYW5zLXNlcmlmIjsgZm9udC1zaXplOiAxMnB0Oyc+PGI+RnJvbTo8 L2I+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmRhdmVAY3JpZGxhbmQubmV0IiB0YXJnZXQ9Il9wYXJl bnQiPkRhdmUgQ3JpZGxhbmQ8L2E+PGJyPjxiPlNlbnQ6PC9iPiZuYnNwO+KAjlRodXJzZGF54oCO LCDigI5KYW51YXJ54oCOIOKAjjE14oCOLCDigI4yMDE1IOKAjjXigI464oCOMDnigI4g4oCOUE08 YnI+PGI+VG86PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpydWJ5c0BpbnRlcnR3aW5nbHkubmV0 IiB0YXJnZXQ9Il9wYXJlbnQiPlNhbSBSdWJ5PC9hPjxicj48Yj5DYzo8L2I+Jm5ic3A7PGEgaHJl Zj0ibWFpbHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9yZyIgdGFyZ2V0PSJfcGFyZW50Ij5JRVRGIEFw cHMgRGlzY3VzczwvYT48L2ZvbnQ+PC9kaXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBkaXI9 IiI+PGRpdiBkaXI9Imx0ciI+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj5PbiAxNSBKYW51YXJ5IDIwMTUgYXQgMTg6MjcsIFNhbSBSdWJ5IDxzcGFuIGRp cj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnJ1YnlzQGludGVydHdpbmdseS5uZXQiIHRhcmdl dD0iX3BhcmVudCI+cnVieXNAaW50ZXJ0d2luZ2x5Lm5ldDwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8 YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4 IDBweCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0 LCAyMDQsIDIwNCk7IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBz b2xpZDsiPkdvb2QgcXVlc3Rpb24uJm5ic3A7IFBsZWFzZSBmb3JnaXZlIHRoZSBsZW5ndGh5IGFu c3dlci48YnI+Cjxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5MZW5ndGh5IGlz IGZpbmUuPC9kaXY+PGRpdj4mbmJzcDs8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsg Ym9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgYm9yZGVyLWxlZnQtd2lkdGg6 IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyI+CkxldHMgcG9zaXQgdGhlIGV4aXN0ZW5j ZSBvZiBhIFdfVVJMIHBhcnNlci4mbmJzcDsgR2l2ZW4gYSBzdHJpbmcsIGl0IHByb2R1Y2VzIGFu IG9iamVjdC4mbmJzcDsgT25lIG9mIHRoZSBvcGVyYXRpb25zIHRoYXQgb2JqZWN0IHBlcmZvcm1z IGlzICJzdHJpbmdpZmljYXRpb24iIChhbiBJREwgdGVybSB0aGF0IEkgZG9uJ3QgcGFydGljdWxh cmx5IGNhcmUgZm9yIHdoaWNoIGVzc2VudGlhbGx5IG1lYW5zIHNlcmlhbGl6YXRpb24gdG8gYSBz dHJpbmcgZm9ybSkuPGJyPgo8YnI+CiZuYnNwOy0gLSAtPGJyPgo8YnI+CklmIHlvdSBsb29rIGF0 IHRoZSBzZXF1ZW5jZSBvZiBvcGVyYXRpb25zOiBwYXJzZSBmb2xsb3dlZCBieSBzdHJpbmdpZmlj YXRpb24sIHlvdSBnZXQgYSBzdHJpbmcgdHJhbnNmb3JtYXRpb24uPGJyPgo8YnI+ClRoaXMgY2Fu IGJlIGFuIGlkZW50aXR5IHRyYW5zZm9ybS4mbmJzcDsgSWYgeW91IHdhbnQsIHRyeSB0aGUgZm9s bG93aW5nIGluIEZpcmVmb3ggb3IgQ2hyb21lJ3MgY29uc29sZTo8YnI+Cjxicj4KJm5ic3A7IG5l dyBVUkwoJzxhIGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNvbS8lMjclMjkuaHJlZiIgdGFyZ2V0PSJf cGFyZW50Ij5odHRwOi8vZXhhbXBsZS5jb20vJykuPHU+PC91PmhyZWY8L2E+ID09ICc8YSBocmVm PSJodHRwOi8vZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9wYXJlbnQiPmh0dHA6Ly9leGFtcGxlLmNv bS88L2E+Jzxicj4KPGJyPgpUaGUgcmVzdWx0IHdpbGwgYmUgdHJ1ZS48YnI+Cjxicj4KVGhlIHJl c3VsdCBjYW4gYmUgc29tZSB0cmFuc2Zvcm1hdGlvbi4mbmJzcDsgRm9yIGV4YW1wbGU6PGJyPgo8 YnI+CiZuYnNwOyBuZXcgVVJMKCc8YSBocmVmPSJIVFRQOi8vRVhBTVBMRS5DT00vUEFUSCUyNyUy OS5ocmVmIiB0YXJnZXQ9Il9wYXJlbnQiPkhUVFA6Ly9FWEFNUExFLkNPTS9QQVRIJyk8dT48L3U+ LmhyZWY8L2E+ID09ICc8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20vUEFUSCIgdGFyZ2V0PSJf cGFyZW50Ij5odHRwOi8vZXhhbXBsZS5jb20vUEFUSDwvYT4nPGJyPgo8YnI+CkZpbmFsbHksIHRo ZSByZXN1bHQgY2FuIGJlIHRvIGdpdmUgdXAuPGJyPgo8YnI+CiZuYnNwOyBuZXcgVVJMKCdodHRw Oi8vZXhhbXBsZS5jb206cG9ydC8nPHU+PC91Pik8YnI+Cjxicj4KQm90aCBGaXJlZm94IGFuZCBD aHJvbWUgdGhyb3cgYW4gZXhjZXB0aW9uLjxicj4KPGJyPgombmJzcDstIC0gLTxicj4KPGJyPgpO b3cgaWYgeW91IHRha2UgYSBsb29rIGF0IHRoYXQgdHJhbnNmb3JtYXRpb24sIHdlIGNhbiBkaXNj dXNzIHRoZSB3aGF0IHNob3VsZCBiZSBkZXNpcmFibGUgY2hhcmFjdGVyaXN0aWNzIG9mIHRoZSBz ZXQgb2Ygb3V0cHV0cy48YnI+Cjxicj4KVGhlIGZpcnN0IGNoYXJhY3RlcmlzdGljIHRoYXQgSSB3 b3VsZCBsaWtlIHRvIHN1Z2dlc3QgaXMgdGhhdCB0aGUgb3V0cHV0cyByb3VuZCB0cmlwLCBhbmQg YnkgdGhhdCBJIG1lYW4gdGhhdCBpZiB5b3UgZmVlZCB0aGF0IG91dHB1dCBiYWNrIGludG8gdGhl IHRyYW5zZm9ybWF0aW9uLCB5b3UgZ2V0IHRoZSBzYW1lIHJlc3VsdCBiYWNrLjxicj4KPGJyPjwv YmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2Pk9LOyB5b3UncmUgc2F5aW5nIHRoYXQgZm9y IGFueSBVUkwgc3RyaW5nIFMsIG5ldyBVUkwobmV3IFVSTChTKS5ocmVmKS5ocmVmID09IG5ldyBV UkwoUykuaHJlZjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+WW91ciB0ZXN0cyBzZWVtIHRvIGlt cGx5IHRoYXQgZm9yIGFueSBVUkwgc3RyaW5nIFMsIHRoZXJlIGlzIG9uZSBhbmQgb25seSBvbmUg Y29ycmVjdCB2YWx1ZSBvZiAobmV3IFVSTChTKS5ocmVmKTsgaXMgdGhhdCBhbHNvIHRoZSBjYXNl PzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VG8gcHV0IGl0IGFub3RoZXIgd2F5LCB5b3VyIHRl c3RzIGltcGx5IGEgY2Fub25pY2FsIGZvcm0gZm9yIGEgVVJJLCBhbmQgdGhhdCBzZWVtcyBtdWNo IG1vcmUgdXNlZnVsLjwvZGl2PjxkaXY+Jm5ic3A7PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCAwLjhleDsgcGFkZGluZy1sZWZ0 OiAxZXg7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IGJvcmRlci1sZWZ0 LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsiPgpUaGUgc2Vjb25kIGNoYXJh Y3RlcmlzdGljIGlzIHRoYXQgaXQgYWN0dWFsbHkgd29ya3MuJm5ic3A7IFRoaXMgaXNuJ3QgYSBw cmVjaXNlbHkgc3BlY2lmaWVkIGNyaXRlcmlhLCBidXQgaXQgbWVhbnMgdGhhdCBpZiB5b3UgYXR0 ZW1wdCB0byB1c2UgdGhlIHJlc3VsdCBpdCBkb2Vzbid0IGJyZWFrIGFueXRoaW5nLiZuYnNwOyBP bmUgZXhhbXBsZSBvZiB0aGlzIHdvdWxkIGJlIHBsYWNpbmcgdGhlIHN0cmluZyAnPGEgaHJlZj0i aHR0cDovL2lldGYub3JnLyIgdGFyZ2V0PSJfcGFyZW50Ij5odHRwOi8vaWV0Zi5vcmcvPC9hPicg aW50byB0aGUgaHJlZiBhdHRyaWJ1dGUgb2YgYW4gSFRNTCAmbHQ7YSZndDsgZWxlbWVudCwgcmVu ZGVyaW5nIGl0IG9uIHRoZSBzY3JlZW4sIGFuZCBoYXZpbmcgc29tZWJvZHkgY2xpY2sgb24gdGhl IGxpbmsuJm5ic3A7IElmIHRoaXMgZ29lcyB0byB0aGUgcmlnaHQgcGxhY2UsIHRoZW4gYWxsIGlz IGdvb2QuJm5ic3A7IFRoZSBkZWZpbml0aW9uIG9mICJ3b3JrcyIgZm9yIGRhdGE6IFctVVJMcywg YW5kIGZvciBqYXZhc2NyaXB0OiBXLVVSTHMgYXJlIGRpZmZlcmVudCwgYnV0IHRoYXQncyBub3Qg YW4gb2JzdGFjbGUgYXQgdGhpcyBsZXZlbCBvZiBkaXNjdXNzaW9uLjxicj4KPGJyPjwvYmxvY2tx dW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PkkgY2FuIHJlYWRpbHkgYXBwcmVjaWF0ZSB0aGUgc2Vu dGltZW50IGhlcmU7IGxpa2UgbWFueSB0aGluZ3MsIGl0J3MgaGFyZCB0byBzcGVjaWZ5LiBCdXQg d2hhdCB5b3UncmUgc2F5aW5nIGlzIHRoYXQgZm9yIGFueSBVUkwgc3RyaW5nIFMsIHdoZXJlIChu ZXcgVVJMKFMpLmhyZWYpIGRvZXMgbm90IHByb2R1Y2UgYW4gZXJyb3IsIHRoZSByZXN1bHQgbXVz dCBiZSBhIHNlbWFudGljYWxseSB2YWxpZCBVUkwgc3RyaW5nPyAoaSdtIGJlaW5nIGRlbGlnaHRm dWxseSB3b29seSBhYm91dCAic2VtYW50aWNhbGx5IHZhbGlkIikuPC9kaXY+PGRpdj4mbmJzcDs8 L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBweCAw cHggMHB4IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigy MDQsIDIwNCwgMjA0KTsgYm9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6 IHNvbGlkOyI+CiZuYnNwOy0gLSAtPGJyPgo8YnI+CkF0IHRoaXMgcG9pbnQsIEknbSB0cm91Ymxl ZC4mbmJzcDsgRGVzcGl0ZSB0aGUgc2V0IG9mIGRlc2lyYWJsZSBjaGFyYWN0ZXJpc3RpY3MgSSBo YXZlIHNwZWNpZmllZCwgSSBoYXZlIGEgd2VsbCBkZWZpbmVkIHNldCB3aGljaCBpcyBuZWl0aGVy IGEgc3VwZXJzZXQgb2YgSS1VUkkncyBub3IgSS1JUkkncywgbm9yIGEgcHJvcGVyIHN1YnNldCBv ZiBlaXRoZXIuPGJyPgo8YnI+CkFuIGV4YW1wbGUgb2Ygc29tZXRoaW5nIHRoYXQgaXMgbm90IGEg Y29uZm9ybWluZyBVUkwsIGJ1dCBpcyBib3RoIGEgdmFsaWQgVVJJIGFuZCBhIHZhbGlkIElSSTo8 YnI+Cjxicj4KJm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly8yNTcuMjU3LjI1Ny4yNTcvIiB0YXJnZXQ9 Il9wYXJlbnQiPmh0dHA6Ly8yNTcuMjU3LjI1Ny4yNTcvPC9hPjxicj4KPGJyPjwvYmxvY2txdW90 ZT48ZGl2Pjxicj48L2Rpdj48ZGl2Pk9LLi4uIEkgZG9uJ3QgdGhpbmsgdGhhdCdzIHZhbGlkLCBi dXQgaXQncyBwcm9iYWJseSB2YWxpZCBhY2NvcmRpbmcgdG8gdGhlIEFCTkYgb25seSAoaWdub3Jp bmcgdGhlIHByb3NlKS4gSSB0aGluayBzcGVjaWZ5aW5nIHRoYXQgaW4gdGhlIGZvcm1hbCBzeW50 YXggd291bGQgYmUgdW5jb250ZW50aW91cyAtIGluIGZhY3QsJm5ic3A7ZHJhZnQtaWV0Zi1pcmkt Mzk4N2Jpcy0xMyBhbHJlYWR5IG1ha2VzIHRoaXMgY2hhbmdlLjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+U2ltaWxhcmx5LCBodHRwOi8vMTI3LjAuMC4xOjY1NTM2LyBpcyBhbHNvIG5vdCB2YWxp ZCwgYnV0IGJlY2F1c2UgdGhlIGNvbmNlcHQgb2YgcG9ydCBpcyBub3QgdGllZCB0byBhIHNwZWNp ZmljIHRyYW5zcG9ydCBwcm90b2NvbCwgYW5kIG1pZ2h0IG5vdCBiZSByZXN0cmljdGVkIHRvIGEg MTYtYml0IHJhbmdlLCB0aGF0J3MgYSBoYXJkZXIgb25lIHRvIGNhcHR1cmUgaW4gcHVyZSBBQk5G IC0gdGhhdCBpcywgdGhlIHBlcm1pc3NhYmxlIHZhbHVlcyBvZiBwb3J0IGFyZSBhcmd1YWJseSBz Y2hlbWUgc3BlY2lmaWMuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Cb3RoIHRoZXNlIGFyZSBp c3N1ZXMgb2Ygd2hhdCBJIGNhbGxlZCBzZW1hbnRpYyB2YWxpZGl0eSBhYm92ZS4gT3RoZXJzIHBy b2JhYmx5IGV4aXN0LjwvZGl2PjxkaXY+Jm5ic3A7PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCAwLjhleDsgcGFkZGluZy1sZWZ0 OiAxZXg7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IGJvcmRlci1sZWZ0 LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsiPgpIZXJlIGlzIHNvbWV0aGlu ZyB0aGF0IHJvdW5kLXRyaXBzIGEgVVJMIHBhcnNlL3N0cmluZ2lmeSB0cmFuc2Zvcm1hdGlvbiwg YW5kIGFjdHVhbGx5IHdvcmtzLCBkZXNwaXRlIGJlaW5nIGFuIGludmFsaWQgVVJJIGFuZCBpbnZh bGlkIElSSTo8YnI+Cjxicj4KJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmdvb2dsZS5jb20v P3E9JTVieiU1ZCIgdGFyZ2V0PSJfcGFyZW50Ij5odHRwczovL3d3dy5nb29nbGUuY29tLz9xPVt6 XTwvYT48YnI+Cjxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5NeSBndXQgZmVl bGluZyBpcyB0aGF0IGFsbG93aW5nIHRoaXMgdG8gYmUgdmFsaWQgaXMgYSBwb3NzaWJsZSBjaGFu Z2UsIGFzIEkndmUgc2FpZC4gSSBhcHByZWNpYXRlIHRoaXMgaXMgYXQgb2RkcyB3aXRoIFJGQyAz OTg2LCBidXQgaWYgVVJMIHBhcnNlcnMgZG8gZ2VuZXJhbGx5IGlnbm9yZSB0aGUgZXJyb3IgdGhh dCdzIGZpbmUuPC9kaXY+PGRpdj4mbmJzcDs8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFl eDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgYm9yZGVyLWxlZnQtd2lk dGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyI+ClRvIGZ1cnRoZXIgY29tcG91bmQg dGhpcywgUkZDIDM5ODYgY2xhaW1zIHRoYXQgdGhlIGZvbGxvd2luZyBzdHJpbmdzIGFyZSB0byBi ZSB0cmVhdGVkIGFzIGVxdWl2YWxlbnQgKGFuZCBwZXJoYXBzIGV2ZW4gcHJlZmVycmVkIGFzIHRo ZXkgYXJlIGRlZW1lZCB0byBiZSAndmFsaWQnKTo8YnI+Cjxicj4KJm5ic3A7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3Lmdvb2dsZS5jb20vP3E9JTVieiU1ZCIgdGFyZ2V0PSJfcGFyZW50Ij5odHRwczov L3d3dy5nb29nbGUuY29tLz9xPSU8dT48L3U+NUJ6JTVEPC9hPjxicj4KJm5ic3A7IDxhIGhyZWY9 Imh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vP3E9JTVieiU1ZCIgdGFyZ2V0PSJfcGFyZW50Ij5odHRw czovL3d3dy5nb29nbGUuY29tLz9xPSU8dT48L3U+NWJ6JTVkPC9hPjxicj4KPGJyPgpJbmRlZWQg aW4gbWFueSwgYW5kIGdlbmVyYWxseSBtb3N0LCBzaXR1YXRpb25zLCB0aG9zZSBhcmUgY29uc2lk ZXJlZCBlcXVpdmFsZW50LiZuYnNwOyBCdXQgdGhpcyBpcyBub3QgbmVjZXNzYXJpbHkgc28uJm5i c3A7IFRvIGl0J3MgY3JlZGl0IFJGQyAzOTg2IGRvZXMgZGVzY3JpYmUgYSBDb21wYXJpc29uIExh ZGRlci4mbmJzcDsgVW5mb3J0dW5hdGVseSBpdCBkb2VzIHNvIHVzaW5nIHRlcm1zIGxpa2UgImZh bHNlIHBvc2l0aXZlcyIgYW5kICJmYWxzZSBuZWdhdGl2ZXMiIHdoZW4gaW4gZmFjdCwgdGhleSBh cmVuJ3QgZmFsc2UgYXQgYWxsLjxicj4KPGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48 ZGl2PkkgdGhpbmsgdGhhdCB0aGlzIHdvdWxkIGRpc2FwcGVhciwgbGFyZ2VseSwgd2l0aCBhIGNh bm9uaWNhbCBmb3JtLiBSRkMgMzk4NiBjdXJyZW50bHkgc2F5cyB0aGF0IHBjdC1lbmNvZGVkIHNo b3VsZCB1c2UgdXBwZXIgY2FzZSAtIHRoYXQncyBhIGxvd2VyIGNhc2UgInNob3VsZCIgLSBhbmQg aWYgd2UgdGFrZSB0aGlzIHRvIGJlIGEgY2Fub25pY2FsIGZvcm0sIHRoZW4gdGhlIGxhdHRlciBj YW5vbmljYWxpemVzIHRvIHRoZSBmb3JtZXIsIGFuZCB3ZSB3aW4uIE9mIGNvdXJzZSwgaWYgW10g aXMgbWFkZSBsZWdhbCBpbiB0aGUgcXVlcnkgc3RyaW5nIGl0J2QgY2Fub25pY2FsaXplIHRvIHRo ZSBwcmV2aW91cyBleGFtcGxlLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Q29tcGFyaXNvbiBv ZiBVUklzIHRoZW4gYmVjb21lIGEgY2FzZSBvZiBjb21wYXJpbmcgdGhlIGNhbm9uaWNhbGl6ZWQg dmVyc2lvbnMgb2YgYm90aC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoaXMgaXMgcHJvYmxl bWF0aWMgaW4gdGhlIGNhc2Ugb2YgcG9ydHMgLSBzaW5jZSA8YSBocmVmPSJodHRwOi8vd3d3Lmdv b2dsZS5jb206ODAvIiB0YXJnZXQ9Il9wYXJlbnQiPmh0dHA6Ly93d3cuZ29vZ2xlLmNvbTo4MC88 L2E+IGFuZCA8YSBocmVmPSJodHRwOi8vd3d3Lmdvb2dsZS5jb20vIiB0YXJnZXQ9Il9wYXJlbnQi Pmh0dHA6Ly93d3cuZ29vZ2xlLmNvbS88L2E+IGJvdGggcmVmZXIgdG8gdGhlIHNhbWUgdGhpbmcs IGJ1dCB0byBoYXZlIGEgc2luZ2xlIGNhbm9uaWNhbCBmb3JtIGZvciBib3RoIHdvdWxkIHJlcXVp cmUgdGhlIHBhcnNlciB0byBiZSBhd2FyZSBvZiB0aGUgZGVmYXVsdCBwb3J0IGZvciB0aGUgc2No ZW1lLiBCdXQgbWF5YmUgdW5rbm93biBzY2hlbWVzIGNhbm5vdCBiZSBjYW5vbmljYWxpemVkLCBv ciBtYXliZSB3ZSBoYXZlIHR3byBjYW5vbmljYWwgZm9ybXMuIChTY2hlbWUtYXdhcmUgYW5kIHNj aGVtZS1hZ25vc3RpYzsgb2J2aW91c2x5IHlvdSdkIHNwZWNpZnkgd2hpY2ggeW91IHdhbnQgYW5k IHdoZXJlKS48L2Rpdj48ZGl2PiZuYnNwOzwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4 OyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQpOyBib3JkZXItbGVmdC13aWR0 aDogMXB4OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7Ij4KJm5ic3A7LSAtIC08YnI+Cjxicj4K U28gbXVjaCBmb3IgYSBkZWVwIGRpdmUuJm5ic3A7IFJldHVybmluZyB0byB0aGUgc3VyZmFjZTog SSdkIGxpa2UgdG8gc2ltdWx0YW5lb3VzbHkgbG9vc2VuIHVwIHRoZSBkZWZpbml0aW9uIG9mIHZh bGlkaXR5IGZvciBJLVVSSSdzIGluIHNvbWUgcGxhY2VzIHdoaWxlIHRpZ2h0ZW5pbmcgaXQgdXAg aW4gb3RoZXJzLiZuYnNwOyBUaGlzIGlzIGEgd29yayBpbiBwcm9ncmVzcywgc28gd2hpY2ggSSBj YW4ndCBzYXkgZXhhY3RseSB3aGVyZSBqdXN0IHlldCBpbiBlYWNoIGNhc2UsIEkgY2FuIHNheSB0 aGF0IG5vdyB3b3VsZCBiZSBhIGdvb2QgdGltZSBmb3IgaW50ZXJlc3RlZCBwYXJ0aWVzIHRvIHBh cnRpY2lwYXRlLjxicj4KPGJyPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsgYm9yZGVyLWxl ZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgYm9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9y ZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyI+Cmh0PHNwYW4+PGZvbnQgY29sb3I9IiM4ODg4ODgiPjxi cj4KPC9mb250Pjwvc3Bhbj48L2Jsb2NrcXVvdGU+PHNwYW4+PGZvbnQgY29sb3I9IiM4ODg4ODgi Pgo8YnI+Ci0gU2FtIFJ1Ynk8L2ZvbnQ+PC9zcGFuPjxzcGFuPjxicj4KPGJyPgo8YmxvY2txdW90 ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBw YWRkaW5nLWxlZnQ6IDFleDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsg Ym9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyI+ClsxXSA8 YSBocmVmPSJodHRwczovL3VybC5zcGVjLndoYXR3Zy5vcmcvIiB0YXJnZXQ9Il9wYXJlbnQiPmh0 dHBzOi8vdXJsLnNwZWMud2hhdHdnLm9yZy88L2E+LCBhcyBvZiAyMDE1LTAxLTE1PGJyPgo8L2Js b2NrcXVvdGU+Cjxicj48L3NwYW4+PGRpdj48ZGl2PgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX188dT48L3U+X19fX19fX19fX19fX19fX188YnI+CmFwcHMtZGlzY3VzcyBtYWlsaW5nIGxp c3Q8YnI+CjxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmciIHRhcmdldD0iX3Bh cmVudCI+YXBwcy1kaXNjdXNzQGlldGYub3JnPC9hPjxicj4KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MiIHRhcmdldD0iX3BhcmVudCI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88dT48L3U+bGlzdGluZm8vYXBwcy1kaXNjdXNz PC9hPjxicj4KPC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj48L2Rpdj4K PC9kaXY+PC9kaXY+CjwvYm9keT4KPC9odG1sPgo= --_53EBFE67-6DDA-44A9-9EE8-447F0D5F1BD5_-- From nobody Fri Jan 16 08:23:16 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CD71ACE9F for ; Fri, 16 Jan 2015 08:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_nzCcT7hs28 for ; Fri, 16 Jan 2015 08:23:12 -0800 (PST) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) (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 A37C01ACE97 for ; Fri, 16 Jan 2015 08:23:12 -0800 (PST) Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t0GGN8Fg019488 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Jan 2015 17:23:08 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id t0GGN7Xo019480; Fri, 16 Jan 2015 17:23:07 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Fri, 16 Jan 2015 17:23:07 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: darrel.miller@gmail.com In-Reply-To: <54b9381b.8ca1e00a.243f.ffffcae4@mx.google.com> Message-ID: References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B806A2.8020803@intertwingly.net>, <54b9381b.8ca1e00a.243f.ffffcae4@mx.google.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1129329158-1260164941-1421425388=:20283" Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 16:23:14 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1129329158-1260164941-1421425388=:20283 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 16 Jan 2015, darrel.miller@gmail.com wrote: > Here is something that round-trips a URL parse/stringify transformation, and > actually works, despite being an invalid URI and invalid IRI: > > https://www.google.com/?q=[z] > > My gut feeling is that allowing this to be valid is a possible change, as > I've said. I appreciate this is at odds with RFC 3986, but if URL parsers do > generally ignore the error that's fine. ̈́ $ curl 'https://www.google.com/?q=[z]' curl: (3) [globbing] bad range in column 32 This isn't strictly the URI parser saying this, but since we know that [] are not legal in a URI we (curl developers) could use them for additional functionality... Just suggesting that changing this will make some things break. -- / daniel.haxx.se --1129329158-1260164941-1421425388=:20283-- From nobody Fri Jan 16 08:30:49 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D971ACDDC for ; Fri, 16 Jan 2015 08:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZN1vSSlLkNQn for ; Fri, 16 Jan 2015 08:30:45 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.230]) by ietfa.amsl.com (Postfix) with ESMTP id B284B1ACDCE for ; Fri, 16 Jan 2015 08:30:45 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:62399] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 37/1C-03864-4BC39B45; Fri, 16 Jan 2015 16:30:45 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id B6DC5140D45; Fri, 16 Jan 2015 11:30:44 -0500 (EST) Message-ID: <54B93CB4.7060805@intertwingly.net> Date: Fri, 16 Jan 2015 11:30:44 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: darrel.miller@gmail.com, Dave Cridland References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B806A2.8020803@intertwingly.net>, <54b9381b.8ca1e00a.243f.ffffcae4@mx.google.com> In-Reply-To: <54b9381b.8ca1e00a.243f.ffffcae4@mx.google.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 16:30:48 -0000 On 01/16/2015 11:05 AM, darrel.miller@gmail.com wrote: > >>Sam Ruby wrote: > >> > >>An example of something that is not a conforming URL, but is both a > valid URI and a valid IRI: > >> > >> http://257.257.257.257/ > > > >Dave Cridland wrote: > >OK... I don't think that's valid, but it's probably valid according to > the ABNF only (ignoring the prose). I think >specifying that in the > formal syntax would be uncontentious - in > fact, draft-ietf-iri-3987bis-13 already makes >this change. > > It is not even valid based on the ABNF, due to a fairly creative > definition of dec-octet. > > https://tools.ietf.org/html/rfc3986#section-3.2.2 It is not a valid IP-literal, but it is a valid reg-name (at least according to the ABNF): host = IP-literal / IPv4address / reg-name reg-name = *( unreserved / pct-encoded / sub-delims ) See also: https://lists.w3.org/Archives/Public/public-ietf-w3c/2014Dec/0075.html > Darrel - Sam Ruby > *From:* Dave Cridland > *Sent:* ‎Thursday‎, ‎January‎ ‎15‎, ‎2015 ‎5‎:‎09‎ ‎PM > *To:* Sam Ruby > *Cc:* IETF Apps Discuss > > On 15 January 2015 at 18:27, Sam Ruby > wrote: > > Good question. Please forgive the lengthy answer. > > > Lengthy is fine. > > Lets posit the existence of a W_URL parser. Given a string, it > produces an object. One of the operations that object performs is > "stringification" (an IDL term that I don't particularly care for > which essentially means serialization to a string form). > > - - - > > If you look at the sequence of operations: parse followed by > stringification, you get a string transformation. > > This can be an identity transform. If you want, try the following > in Firefox or Chrome's console: > > new URL('http://example.com/').__href > == 'http://example.com/' > > The result will be true. > > The result can be some transformation. For example: > > new URL('HTTP://EXAMPLE.COM/PATH')__.href > == 'http://example.com/PATH' > > Finally, the result can be to give up. > > new URL('http://example.com:port/'__) > > Both Firefox and Chrome throw an exception. > > - - - > > Now if you take a look at that transformation, we can discuss the > what should be desirable characteristics of the set of outputs. > > The first characteristic that I would like to suggest is that the > outputs round trip, and by that I mean that if you feed that output > back into the transformation, you get the same result back. > > > OK; you're saying that for any URL string S, new URL(new > URL(S).href).href == new URL(S).href > > Your tests seem to imply that for any URL string S, there is one and > only one correct value of (new URL(S).href); is that also the case? > > To put it another way, your tests imply a canonical form for a URI, and > that seems much more useful. > > The second characteristic is that it actually works. This isn't a > precisely specified criteria, but it means that if you attempt to > use the result it doesn't break anything. One example of this would > be placing the string 'http://ietf.org/' into the href attribute of > an HTML element, rendering it on the screen, and having somebody > click on the link. If this goes to the right place, then all is > good. The definition of "works" for data: W-URLs, and for > javascript: W-URLs are different, but that's not an obstacle at this > level of discussion. > > > I can readily appreciate the sentiment here; like many things, it's hard > to specify. But what you're saying is that for any URL string S, where > (new URL(S).href) does not produce an error, the result must be a > semantically valid URL string? (i'm being delightfully wooly about > "semantically valid"). > > - - - > > At this point, I'm troubled. Despite the set of desirable > characteristics I have specified, I have a well defined set which is > neither a superset of I-URI's nor I-IRI's, nor a proper subset of > either. > > An example of something that is not a conforming URL, but is both a > valid URI and a valid IRI: > > http://257.257.257.257/ > > > OK... I don't think that's valid, but it's probably valid according to > the ABNF only (ignoring the prose). I think specifying that in the > formal syntax would be uncontentious - in > fact, draft-ietf-iri-3987bis-13 already makes this change. > > Similarly, http://127.0.0.1:65536/ is also not valid, but because the > concept of port is not tied to a specific transport protocol, and might > not be restricted to a 16-bit range, that's a harder one to capture in > pure ABNF - that is, the permissable values of port are arguably scheme > specific. > > Both these are issues of what I called semantic validity above. Others > probably exist. > > Here is something that round-trips a URL parse/stringify > transformation, and actually works, despite being an invalid URI and > invalid IRI: > > https://www.google.com/?q=[z] > > > My gut feeling is that allowing this to be valid is a possible change, > as I've said. I appreciate this is at odds with RFC 3986, but if URL > parsers do generally ignore the error that's fine. > > To further compound this, RFC 3986 claims that the following strings > are to be treated as equivalent (and perhaps even preferred as they > are deemed to be 'valid'): > > https://www.google.com/?q=%__5Bz%5D > https://www.google.com/?q=%__5bz%5d > > Indeed in many, and generally most, situations, those are considered > equivalent. But this is not necessarily so. To it's credit RFC > 3986 does describe a Comparison Ladder. Unfortunately it does so > using terms like "false positives" and "false negatives" when in > fact, they aren't false at all. > > > I think that this would disappear, largely, with a canonical form. RFC > 3986 currently says that pct-encoded should use upper case - that's a > lower case "should" - and if we take this to be a canonical form, then > the latter canonicalizes to the former, and we win. Of course, if [] is > made legal in the query string it'd canonicalize to the previous example. > > Comparison of URIs then become a case of comparing the canonicalized > versions of both. > > This is problematic in the case of ports - since > http://www.google.com:80/ and http://www.google.com/ both refer to the > same thing, but to have a single canonical form for both would require > the parser to be aware of the default port for the scheme. But maybe > unknown schemes cannot be canonicalized, or maybe we have two canonical > forms. (Scheme-aware and scheme-agnostic; obviously you'd specify which > you want and where). > > - - - > > So much for a deep dive. Returning to the surface: I'd like to > simultaneously loosen up the definition of validity for I-URI's in > some places while tightening it up in others. This is a work in > progress, so which I can't say exactly where just yet in each case, > I can say that now would be a good time for interested parties to > participate. > > ht > > > - Sam Ruby > > [1] https://url.spec.whatwg.org/, as of 2015-01-15 > > > _________________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/__listinfo/apps-discuss > > > From nobody Fri Jan 16 08:32:11 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2F81ACEBF for ; Fri, 16 Jan 2015 08:32:10 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rvv8jthOtPz for ; Fri, 16 Jan 2015 08:32:09 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 F384B1ACEBC for ; Fri, 16 Jan 2015 08:32:08 -0800 (PST) Received: from [192.168.123.151] (unknown [23.241.1.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E4F3222E260; Fri, 16 Jan 2015 11:32:06 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: Date: Fri, 16 Jan 2015 08:32:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <98A81DE7-1845-46EC-A3EB-F00438863ECB@seantek.com> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B806A2.8020803@intertwingly.net>, <54b9381b.8ca1e00a.243f.ffffcae4@mx.google.com> To: Daniel Stenberg X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 16:32:10 -0000 On Jan 16, 2015, at 8:23 AM, Daniel Stenberg wrote: > On Fri, 16 Jan 2015, darrel.miller@gmail.com wrote: >=20 >> Here is something that round-trips a URL parse/stringify = transformation, and actually works, despite being an invalid URI and = invalid IRI: >>=20 >> https://www.google.com/?q=3D[z] >>=20 >> My gut feeling is that allowing this to be valid is a possible = change, as I've said. I appreciate this is at odds with RFC 3986, but if = URL parsers do generally ignore the error that's fine. > =CD=84 > $ curl 'https://www.google.com/?q=3D[z]' > curl: (3) [globbing] bad range in column 32 >=20 > This isn't strictly the URI parser saying this, but since we know that = [] are not legal in a URI we (curl developers) could use them for = additional functionality... >=20 > Just suggesting that changing this will make some things break. Yes that is an excellent point. In my own software I use some of those = properties of URIs. Since certain characters like { } [ ] < > are not = part of URIs, they can be used to develop new functionality (e.g., URI = regexps). For example [z] can mean =E2=80=9Cescape the z variable string = in UTF-8=E2=80=9D vs {z} =E2=80=9Cescape the z variable octet array = as-is=E2=80=9D, or other variations. And of course { }, < >, and the = like can be used to delineate an URI in other contexts, such as in plain = text . Sean= From nobody Fri Jan 16 08:41:18 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178851ACEB6 for ; Fri, 16 Jan 2015 08:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyERtb9tPKAp for ; Fri, 16 Jan 2015 08:41:15 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.230]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA5B1ACEAD for ; Fri, 16 Jan 2015 08:41:15 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:63675] helo=rubix) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id EA/71-25206-A2F39B45; Fri, 16 Jan 2015 16:41:14 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id C4DA5140D45 for ; Fri, 16 Jan 2015 11:41:14 -0500 (EST) Message-ID: <54B93F2A.5070900@intertwingly.net> Date: Fri, 16 Jan 2015 11:41:14 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B806A2.8020803@intertwingly.net>, <54b9381b.8ca1e00a.243f.ffffcae4@mx.google.com> <98A81DE7-1845-46EC-A3EB-F00438863ECB@seantek.com> In-Reply-To: <98A81DE7-1845-46EC-A3EB-F00438863ECB@seantek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 16:41:17 -0000 On 01/16/2015 11:32 AM, Sean Leonard wrote: > > On Jan 16, 2015, at 8:23 AM, Daniel Stenberg wrote: > >> On Fri, 16 Jan 2015, darrel.miller@gmail.com wrote: >> >>> Here is something that round-trips a URL parse/stringify transformation, and actually works, despite being an invalid URI and invalid IRI: >>> >>> https://www.google.com/?q=[z] >>> >>> My gut feeling is that allowing this to be valid is a possible change, as I've said. I appreciate this is at odds with RFC 3986, but if URL parsers do generally ignore the error that's fine. >> ̈́ >> $ curl 'https://www.google.com/?q=[z]' >> curl: (3) [globbing] bad range in column 32 >> >> This isn't strictly the URI parser saying this, but since we know that [] are not legal in a URI we (curl developers) could use them for additional functionality... >> >> Just suggesting that changing this will make some things break. > > Yes that is an excellent point. In my own software I use some of those properties of URIs. Since certain characters like { } [ ] < > are not part of URIs, they can be used to develop new functionality (e.g., URI regexps). For example [z] can mean “escape the z variable string in UTF-8” vs {z} “escape the z variable octet array as-is”, or other variations. And of course { }, < >, and the like can be used to delineate an URI in other contexts, such as in plain text . This is indeed valuable input. Another example where this is done: https://tools.ietf.org/html/rfc6570 One way to look at this is that there are tools that layer additional functionality on top of URIs. As to what the breakage it, that is less clear to me. There are existing parsers that don't percent encode square brackets when they occur at some point after a question mark is encountered in the input. Perhaps those parsers lose the ability to claim that they are "RFC 3986 compliant". > Sean > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss - Sam Ruby From nobody Fri Jan 16 08:45:31 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911D81ACED8 for ; Fri, 16 Jan 2015 08:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 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, J_CHICKENPOX_37=0.6, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr9xVq28dQ_A for ; Fri, 16 Jan 2015 08:45:28 -0800 (PST) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EA1A1ACEC5 for ; Fri, 16 Jan 2015 08:45:28 -0800 (PST) Received: by mail-qc0-f169.google.com with SMTP id w7so17769992qcr.0 for ; Fri, 16 Jan 2015 08:45:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:from:to:cc:subject:importance:date :in-reply-to:references:content-type; bh=Tl5SjDCunMV5ld0k8AapivLKEnTx1tIenGtbSbKG2Lk=; b=C2eaa/Ov1QopRVjSjS1ivz5e+I6CXZOFXgzqY2twH7h39ay6Gbedg+eNTgHEIBZUGX 0bIHSuqqaV9bjV+7no8IbDHF4xIAQlTPCQC44D1Y4z2FWaW5P67BeVdPZC6BG0UnmAD0 euUtHOuiEwfLoO1cIxbVXxWEAxhxDBvZ4WtLMW3zIOhDLfc+/EXwKz+XkwiJ3NDshyZb TQF1gIkK4AxISSvPVcgi8F/uN3ri0b0AueXbiskiI8i2sYXF/QDgLOQwkcvq5+7C9yPi hcs9cXZT/Gw0FF30avfd4CUe8ZbhSBrWYEhNI0ea4XrnikiW8EQkpUgMflNdiUrf/88M yMag== X-Received: by 10.140.42.105 with SMTP id b96mr25280079qga.47.1421426727286; Fri, 16 Jan 2015 08:45:27 -0800 (PST) Received: from Pecan (bas11-montreal02-1128535737.dsl.bell.ca. [67.68.22.185]) by mx.google.com with ESMTPSA id n18sm4577376qae.27.2015.01.16.08.45.26 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 16 Jan 2015 08:45:26 -0800 (PST) Message-ID: <54b94026.5229e00a.77ab.ffffd0d7@mx.google.com> MIME-Version: 1.0 From: To: =?utf-8?Q?Sam_Ruby?= Importance: Normal Date: Fri, 16 Jan 2015 16:42:19 +0000 In-Reply-To: <54B93CB4.7060805@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54A94109.5010901@intertwingly.net> <00cf01d02cc7$d5dba4c0$4001a8c0@gateway.2wire.net> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B806A2.8020803@intertwingly.net>, <54b9381b.8ca1e00a.243f.ffffcae4@mx.google.com>, <54B93CB4.7060805@intertwingly.net> Content-Type: multipart/alternative; boundary="_40FAAB99-D6C7-4FC0-8FAE-86175723A9C3_" Archived-At: Cc: =?utf-8?Q?IETF_Apps_Discuss?= Subject: Re: [apps-discuss] =?utf-8?q?Scope_of_RFC3986_and_successor_-_what_is?= =?utf-8?q?_a_URI=3F?= X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 16:45:29 -0000 --_40FAAB99-D6C7-4FC0-8FAE-86175723A9C3_ Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" DQo+T24gMDEvMTYvMjAxNSAxMTowNSBBTSwgZGFycmVsLm1pbGxlckBnbWFpbC5jb20gd3JvdGU6 DQo+PiAgPj5TYW0gUnVieSB3cm90ZToNCj4+ICA+Pg0KPj4gID4+QW4gZXhhbXBsZSBvZiBzb21l dGhpbmcgdGhhdCBpcyBub3QgYSBjb25mb3JtaW5nIFVSTCwgYnV0IGlzIGJvdGggYQ0KPj4gdmFs aWQgVVJJIGFuZCBhIHZhbGlkIElSSToNCj4+ICA+Pg0KPj4gID4+IGh0dHA6Ly8yNTcuMjU3LjI1 Ny4yNTcvDQo+PiAgPg0KPj4gID5EYXZlIENyaWRsYW5kIHdyb3RlOg0KPj4gID5PSy4uLiBJIGRv bid0IHRoaW5rIHRoYXQncyB2YWxpZCwgYnV0IGl0J3MgcHJvYmFibHkgdmFsaWQgYWNjb3JkaW5n IHRvDQo+PiB0aGUgQUJORiBvbmx5IChpZ25vcmluZyB0aGUgcHJvc2UpLiBJIHRoaW5rID5zcGVj aWZ5aW5nIHRoYXQgaW4gdGhlDQo+PiBmb3JtYWwgc3ludGF4IHdvdWxkIGJlIHVuY29udGVudGlv dXMgLSBpbg0KPj4gZmFjdCwgZHJhZnQtaWV0Zi1pcmktMzk4N2Jpcy0xMyBhbHJlYWR5IG1ha2Vz ID50aGlzIGNoYW5nZS4NCj4+DQo+PiBJdCBpcyBub3QgZXZlbiB2YWxpZCBiYXNlZCBvbiB0aGUg QUJORiwgZHVlIHRvIGEgZmFpcmx5IGNyZWF0aXZlDQo+PiBkZWZpbml0aW9uIG9mIGRlYy1vY3Rl dC4NCj4+DQo+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzk4NiNzZWN0aW9uLTMu Mi4yDQo+DQo+IEl0IGlzIG5vdCBhIHZhbGlkIElQLWxpdGVyYWwsIGJ1dCBpdCBpcyBhIHZhbGlk IHJlZy1uYW1lIChhdCBsZWFzdCANCj4gYWNjb3JkaW5nIHRvIHRoZSBBQk5GKToNCj4NCj4gICAg ICBob3N0ICAgICAgICA9IElQLWxpdGVyYWwgLyBJUHY0YWRkcmVzcyAvIHJlZy1uYW1lDQo+ICAg ICByZWctbmFtZSAgICA9ICooIHVucmVzZXJ2ZWQgLyBwY3QtZW5jb2RlZCAvIHN1Yi1kZWxpbXMg KQ0KPg0KPiBTZWUgYWxzbzoNCj4NCj4gIGh0dHBzOi8vbGlzdHMudzMub3JnL0FyY2hpdmVzL1B1 YmxpYy9wdWJsaWMtaWV0Zi13M2MvMjAxNERlYy8wMDc1Lmh0bWwNCg0KDQoNClRoYXQgaXMgdW5m b3J0dW5hdGUuICBUaGFua3MgZm9yIHBvaW50aW5nIHRoYXQgb3V0LCBJIHdhcyBub3QgYXdhcmUg b2YgdGhhdCBwb3RlbnRpYWwgZm9yIGFtYmlndWl0eS4NCg0KDQpEYXJyZWw= --_40FAAB99-D6C7-4FC0-8FAE-86175723A9C3_ Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" CjxodG1sPgo8aGVhZD4KPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJXaW5kb3dzIE1h aWwgMTcuNS45NjAwLjIwNjg5Ij4KPHN0eWxlIHR5cGU9InRleHQvY3NzIj48IS0taHRtbCB7IGZv bnQtZmFtaWx5OiAiQ29sb3IgRW1vamkiLCAiQ2FsaWJyaSIsICJTZWdvZSBVSSIsICJNZWlyeW8i LCAiTWljcm9zb2Z0IFlhSGVpIFVJIiwgIk1pY3Jvc29mdCBKaGVuZ0hlaSBVSSIsICJNYWxndW4g R290aGljIiwgInNhbnMtc2VyaWYiOyB9LS0+PC9zdHlsZT48c3R5bGUgZGF0YS1leHRlcm5hbHN0 eWxlPSJ0cnVlIj48IS0tCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGggewptYXJnaW4tdG9wOjBpbjsKbWFyZ2luLXJpZ2h0OjBpbjsK bWFyZ2luLWJvdHRvbTowaW47Cm1hcmdpbi1sZWZ0Oi41aW47Cm1hcmdpbi1ib3R0b206LjAwMDFw dDsKfQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsIHsKbWFyZ2luOjBp bjsKbWFyZ2luLWJvdHRvbTouMDAwMXB0Owp9CnAuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCwg bGkuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmly c3QsIApwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hT cE1pZGRsZSwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCAKcC5Nc29MaXN0UGFyYWdy YXBoQ3hTcExhc3QsIGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGhDeFNwTGFzdCB7Cm1hcmdpbi10b3A6MGluOwptYXJnaW4tcmlnaHQ6MGluOwptYXJnaW4t Ym90dG9tOjBpbjsKbWFyZ2luLWxlZnQ6LjVpbjsKbWFyZ2luLWJvdHRvbTouMDAwMXB0OwpsaW5l LWhlaWdodDoxMTUlOwp9Ci0tPjwvc3R5bGU+PC9oZWFkPgo8Ym9keSBkaXI9Imx0ciI+CjxkaXYg ZGF0YS1leHRlcm5hbHN0eWxlPSJmYWxzZSIgZGlyPSJsdHIiIHN0eWxlPSJmb250LWZhbWlseTog J0NhbGlicmknLCAnU2Vnb2UgVUknLCAnTWVpcnlvJywgJ01pY3Jvc29mdCBZYUhlaSBVSScsICdN aWNyb3NvZnQgSmhlbmdIZWkgVUknLCAnTWFsZ3VuIEdvdGhpYycsICdzYW5zLXNlcmlmJztmb250 LXNpemU6MTJwdDsiPjxkaXYgc3R5bGU9InBhZGRpbmctdG9wOiA1cHg7IGJvcmRlci10b3AtY29s b3I6IHJnYigyMjksIDIyOSwgMjI5KTsgYm9yZGVyLXRvcC13aWR0aDogMXB4OyBib3JkZXItdG9w LXN0eWxlOiBzb2xpZDsiPjxkaXY+Jmd0O09uIDAxLzE2LzIwMTUgMTE6MDUgQU0sIGRhcnJlbC5t aWxsZXJAZ21haWwuY29tIHdyb3RlOjxicj4mZ3Q7Jmd0OyZuYnNwOyAmZ3Q7Jmd0O1NhbSBSdWJ5 IHdyb3RlOjxicj4mZ3Q7Jmd0OyZuYnNwOyAmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZuYnNwOyAmZ3Q7 Jmd0O0FuIGV4YW1wbGUgb2Ygc29tZXRoaW5nIHRoYXQgaXMgbm90IGEgY29uZm9ybWluZyBVUkws IGJ1dCBpcyBib3RoIGE8YnI+Jmd0OyZndDsgdmFsaWQgVVJJIGFuZCBhIHZhbGlkIElSSTo8YnI+ Jmd0OyZndDsmbmJzcDsgJmd0OyZndDs8YnI+Jmd0OyZndDsmbmJzcDsgJmd0OyZndDsgaHR0cDov LzI1Ny4yNTcuMjU3LjI1Ny88YnI+Jmd0OyZndDsmbmJzcDsgJmd0Ozxicj4mZ3Q7Jmd0OyZuYnNw OyAmZ3Q7RGF2ZSBDcmlkbGFuZCB3cm90ZTo8YnI+Jmd0OyZndDsmbmJzcDsgJmd0O09LLi4uIEkg ZG9uJ3QgdGhpbmsgdGhhdCdzIHZhbGlkLCBidXQgaXQncyBwcm9iYWJseSB2YWxpZCBhY2NvcmRp bmcgdG88YnI+Jmd0OyZndDsgdGhlIEFCTkYgb25seSAoaWdub3JpbmcgdGhlIHByb3NlKS4gSSB0 aGluayAmZ3Q7c3BlY2lmeWluZyB0aGF0IGluIHRoZTxicj4mZ3Q7Jmd0OyBmb3JtYWwgc3ludGF4 IHdvdWxkIGJlIHVuY29udGVudGlvdXMgLSBpbjxicj4mZ3Q7Jmd0OyBmYWN0LCBkcmFmdC1pZXRm LWlyaS0zOTg3YmlzLTEzIGFscmVhZHkgbWFrZXMgJmd0O3RoaXMgY2hhbmdlLjxicj4mZ3Q7Jmd0 Ozxicj4mZ3Q7Jmd0OyBJdCBpcyBub3QgZXZlbiB2YWxpZCBiYXNlZCBvbiB0aGUgQUJORiwgZHVl IHRvIGEgZmFpcmx5IGNyZWF0aXZlPGJyPiZndDsmZ3Q7IGRlZmluaXRpb24gb2YgZGVjLW9jdGV0 Ljxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj Mzk4NiNzZWN0aW9uLTMuMi4yPGJyPiZndDs8YnI+Jmd0OyBJdCBpcyBub3QgYSB2YWxpZCBJUC1s aXRlcmFsLCBidXQgaXQgaXMgYSB2YWxpZCByZWctbmFtZSAoYXQgbGVhc3QgPGJyPiZndDsgYWNj b3JkaW5nIHRvIHRoZSBBQk5GKTo8YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGhvc3QmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg PSBJUC1saXRlcmFsIC8gSVB2NGFkZHJlc3MgLyByZWctbmFtZTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHJlZy1uYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7ID0gKiggdW5yZXNlcnZlZCAv IHBjdC1lbmNvZGVkIC8gc3ViLWRlbGltcyApPGJyPiZndDs8YnI+Jmd0OyBTZWUgYWxzbzo8YnI+ Jmd0Ozxicj4mZ3Q7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vbGlzdHMudzMub3JnL0FyY2hpdmVz L1B1YmxpYy9wdWJsaWMtaWV0Zi13M2MvMjAxNERlYy8wMDc1Lmh0bWwiPmh0dHBzOi8vbGlzdHMu dzMub3JnL0FyY2hpdmVzL1B1YmxpYy9wdWJsaWMtaWV0Zi13M2MvMjAxNERlYy8wMDc1Lmh0bWw8 L2E+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhhdCBpcyB1bmZvcnR1bmF0ZS4mbmJz cDsgVGhhbmtzIGZvciBwb2ludGluZyB0aGF0IG91dCwgSSB3YXMgbm90IGF3YXJlIG9mIHRoYXQg cG90ZW50aWFsIGZvciBhbWJpZ3VpdHkuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5EYXJyZWw8 YnI+PGJyPjwvZGl2PjwvZGl2PjwvZGl2Pgo8L2JvZHk+CjwvaHRtbD4K --_40FAAB99-D6C7-4FC0-8FAE-86175723A9C3_-- From nobody Fri Jan 16 08:57:42 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927CB1AD06B for ; Fri, 16 Jan 2015 08:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKovV1VXEY07 for ; Fri, 16 Jan 2015 08:57:36 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 3CE521ACE44 for ; Fri, 16 Jan 2015 08:57:36 -0800 (PST) Received: from [192.168.1.194] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LinyL-1Xbk3s2fjJ-00d2P7; Fri, 16 Jan 2015 17:57:33 +0100 Message-ID: <54B942F6.5020007@gmx.de> Date: Fri, 16 Jan 2015 17:57:26 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Sean Leonard , Daniel Stenberg References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B806A2.8020803@intertwingly.net>, <54b9381b.8ca1e00a.243f.ffffcae4@mx.google.com> <98A81DE7-1845-46EC-A3EB-F00438863ECB@seantek.com> In-Reply-To: <98A81DE7-1845-46EC-A3EB-F00438863ECB@seantek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:fx2Xhax85SRSZcr2uHLcsAvV2IE2ykj9fXZCcjjvQBwTafe7IfK qkWs2Vy1d5GwNkXDGjXh3JxxnaFV2z0H1YIJhXQtducZL3ABwIg2gF6rxINm/NWvpOVPtOm oBiDnq2w3oUc7u12TgkUBkLzYeMSM9z+Lorjeh/mcrv1VfG3PYSvZOUItrm1XLWGRHJZYHX GXPzkpy7V3c6Sqk7Tqbdg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 16:57:38 -0000 On 2015-01-16 17:32, Sean Leonard wrote: > > On Jan 16, 2015, at 8:23 AM, Daniel Stenberg wrote: > >> On Fri, 16 Jan 2015, darrel.miller@gmail.com wrote: >> >>> Here is something that round-trips a URL parse/stringify transformation, and actually works, despite being an invalid URI and invalid IRI: >>> >>> https://www.google.com/?q=[z] >>> >>> My gut feeling is that allowing this to be valid is a possible change, as I've said. I appreciate this is at odds with RFC 3986, but if URL parsers do generally ignore the error that's fine. >> ̈́ >> $ curl 'https://www.google.com/?q=[z]' >> curl: (3) [globbing] bad range in column 32 >> >> This isn't strictly the URI parser saying this, but since we know that [] are not legal in a URI we (curl developers) could use them for additional functionality... >> >> Just suggesting that changing this will make some things break. > > Yes that is an excellent point. In my own software I use some of those properties of URIs. Since certain characters like { } [ ] < > are not part of URIs, they can be used to develop new functionality (e.g., URI regexps). For example [z] can mean “escape the z variable string in UTF-8” vs {z} “escape the z variable octet array as-is”, or other variations. And of course { }, < >, and the like can be used to delineate an URI in other contexts, such as in plain text . "{" and "}" are used in URI templates. Re square brackets, see for example: Best regards, Julian From nobody Fri Jan 16 09:08:44 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CB21AD0B8 for ; Fri, 16 Jan 2015 09:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RR8iTDtL1gW for ; Fri, 16 Jan 2015 09:08:41 -0800 (PST) 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 1E4E71ACF55 for ; Fri, 16 Jan 2015 09:08:41 -0800 (PST) Received: from [192.168.1.194] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MZkv0-1YT9Za2xMU-00LVje; Fri, 16 Jan 2015 18:08:36 +0100 Message-ID: <54B9458D.9070403@gmx.de> Date: Fri, 16 Jan 2015 18:08:29 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Henry S. Thompson" , Sean Leonard References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <54B924B0.40105@seantek.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:SoPC7s48Tm6XnjtV7Z5RCaJmuypOTKEgscMgiDrc+jIX0vv02Oz DxgvHTMfSpAEUEFpGnVOmme6VP3yGIRku+eIVWQ0xT8sd5KpvNwYysMoOnKpoFY7e9Cp918 7KFsZ+4bCDGQ7cNpK1MSIVYb6rWh+6jFsdXmzwEim0VgYfLSDjrUrQxZXL/uX8mAg0+Vnjy D6NGa2IRaC5ZUlIJ4E5qg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Terminology and scope of [UI]Rx-like objects X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 17:08:43 -0000 On 2015-01-16 16:13, Henry S. Thompson wrote: > ... > It has become increasingly necessary to take the distinction I'm > concerned with seriously as time has gone by, not just because of the > advent of UCS, but because of the expanded requirements of the > human-facing context of use. I'm thinking here particularly of the > status of the space character. > ... When RFC 3987 was written, adding SP to the set of allowed characters was considered. However, it's in conflict with cases where formats need a white-space separated list of identifiers, or use whitespace as delimiters around identifiers, and that's why RFC 3987 stayed consistent with 3986. Best regards, Julian From nobody Fri Jan 16 09:34:24 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6551AD291 for ; Fri, 16 Jan 2015 09:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, J_CHICKENPOX_14=0.6, J_CHICKENPOX_19=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 472hJOXVkaw9 for ; Fri, 16 Jan 2015 09:34:15 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F9D21AD28D for ; Fri, 16 Jan 2015 09:34:15 -0800 (PST) Received: by mail-oi0-f51.google.com with SMTP id h136so18381595oig.10 for ; Fri, 16 Jan 2015 09:34:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cdm2nd47DnkZevyTaD5ErPKby3+e7BGDlAGHUjdzZDA=; b=hAAaIt3BQUC8W7nPSKNXXT5Qn8MYywt8Du2dqGcAesjkx5/ODE7G3QeaOnGECpMkRA b83Iq2XKzgTXtge3U1TchZGw7vF2HHiIlWUoVEeX20skqOvt3KXWE6KhATVoZZFuapzh EUXNAbfKGQsJde/G80UytKIcVewVyzMD4sJzc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cdm2nd47DnkZevyTaD5ErPKby3+e7BGDlAGHUjdzZDA=; b=XBfYnWhnK+vTpotwza6fkSi5XIr6b9zZZgKV8KcgbqV3NFmNC/0QucZyDq5EAceg07 OJaeIk6aUj06ttGQNj/ptRg1mkqRFeyZOzYhHUMP2FaoqDR1OWMizIg+DJR3rcbXSi72 224DLimJhAnwUk2w5n/i/Yk1zWw9wBl+posaZUgaYMmEduy34ao0Bi8XCN9v+9UozEyt DvTL23vjP0UTY9oAn7Qlot01KfDHWqjAS0b1olobgpgRquGCsx6DHKrTKhfi2SgQlPJ6 COE/6kHDFWkh2u2IFzm5elOAKOBynOZAvoD2fmXGQ9i3XMoqLQpOfLwhxIXBpnmJBIOr r6Qg== X-Gm-Message-State: ALoCoQlgTH2JoTWCyG4zPMxtvWIiMI8dyfQrh/KYE9B9rrHLibBMVh4Kg0VDwxu33hvQW2R/HhGT MIME-Version: 1.0 X-Received: by 10.182.44.132 with SMTP id e4mr10343826obm.86.1421429654607; Fri, 16 Jan 2015 09:34:14 -0800 (PST) Received: by 10.60.84.171 with HTTP; Fri, 16 Jan 2015 09:34:14 -0800 (PST) In-Reply-To: <54B9319F.8020900@intertwingly.net> References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <54B8F74A.70601@intertwingly.net> <54B909F4.4020908@intertwingly.net> <54B9319F.8020900@intertwingly.net> Date: Fri, 16 Jan 2015 17:34:14 +0000 Message-ID: From: Dave Cridland To: Sam Ruby Content-Type: multipart/alternative; boundary=001a11c2f49aa2effb050cc8614f Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] What does it mean? (Re: Scope of RFC3986 and successor - what is a URI?) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jan 2015 17:34:21 -0000 --001a11c2f49aa2effb050cc8614f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 16 January 2015 at 15:43, Sam Ruby wrote: > On 01/16/2015 08:57 AM, Dave Cridland wrote: > >> >> Taking the example of LDAP, this relies on schemas where a URI is >> transported in a IA5String, which is ASCII-only (loosely, it's actually >> 7-bit ASCII supersets). >> >> Allowing non-ASCII breaks this, no matter how we wave magic wands about >> parsers - the parser simply never gets to see the URI, because the BER >> decoder (or whatever) throws an error. >> > > You and I have different ideas of "magic wands". I will also note that I > personally dislike this style of discourse. > > Actually you've entirely misunderstood my use of the term. I wasn't being flippant in this instance, and my apologies if I inadvertently sounded that way. I do try to make it very clear when I *am* being flippant. > Whatever they are called (URI, IRI, URL), as commonly practiced they may > contain fragments and those fragments may contain bytes with the high ord= er > bit on. > > What they're called makes a distinct difference here. URIs as specified are 7-bit clean, IRIs as specified are a unicode sequence of codepoints. > The exists specs that make claims that such values aren't valid. There > exists software components (e.g. parses) that purport to convert URIs, > IRIs, or URLs into spec compliant strings. As a general rule, they do > things differently. In particular, most leave fragments alone. Even whe= n > they contain characters with a high order bit on. > > People who read such specs and the high level descriptions of said > software components may indeed be mislead into designing schema choosing > the wrong type of string[1], and that choice will cause runtime failures = to > occur. > > Given the above, and using your term ("magic wand"), it is my belief that > the attempt to invoke "magic" occurs in the existing specification, and > that the choice to do so does a disservice to the readers. > > Note: it would be presumptuous of me to assume that my perception of wher= e > the "magic wand" occurs in this scenario is shared with you. Please permi= t > me the same courtesy. > > By use of the term "magic wand", I did not mean in the sense you seem to imply of a religious text, I meant a device which enables the wielder warp reality in an [otherwise] impossible manner. The "magic wand" lies in the problems of declaring one side the winner without considering the damage it'll have on the losing side, as it were. To safely fix the damage in any reasonable timeframe may require such a wand. If we say "fragments are 7-bit in URIs", then these parsers will be fine on valid URIs. We're in a situation of garbage in, garbage out. If we say "fragments can be any codepoint", then X.509 breaks - given there are X.509 certificates blown into silicon, and in every DoD CAC, for example, this is problematic, to various degrees. There are fixes, of course - we would have to retire the old schema, and possibly the containing extension, and replace it. There'll be a crossover period of decades for this, where both extensions need to be supported, and some URLs will be unrepresentable in some X.509 systems during this period. Having two extensions fulfilling the same function is a worrying thought in a security protocol, and I've little doubt there'd be an excitingly named TLS exploit with a beautifully designed logo as a result. URIs embedded into X.509 certificates include, for example, CRL Distribution Points and OCSP Responders, and are therefore security-critical. So my question is why you consider that the running code you cite should be accorded more weight than the combination of the running code others have cited *and* the specification? Of course, you can also say "fragments are unicode in my very own URLs, here is a transformation to turn them into URIs", but then... That said, we clearly do have the >> IRI specifications (and their bis drafts), and if there is interest from >> the W3C I think we could find the energy to complete that work. >> > > Finding the energy to complete the IRI work would indeed be a game > changer. At the moment, I'm skeptical, but suffice it to say that I woul= d > be very interested if that came to pass. > > Until that time, my intent I view with skepticism any and all use of the > term IRI. > > ... you're set on a path of either completing the IRI work, or duplicating it. > How would you feel about the possibility of having an API that looked >> somewhat like this: >> >> Given: >> >> u =3D new URL(S) # Accepts strictly valid, and certain invalid, IRIs. >> >> u.href # "cleaned" valid IRI string, with any syntax cleaned according >> to rules. >> >> u.canonical # "canonical" IRI string. >> >> u.toASCII() # "cleaned" URI string, for use in HTTP, LDAP, etc. >> >> So with S as http://caf=C3=A9.im:80/t=C5=B7/%2e >> > C5%B7/%2e> >> >> u.href =3D> http://caf=C3=A9.im:80/t=C5=B7/ < >> http://xn--caf-dma.im:80/t%C5%B7/>. >> (although variants allowed) >> > > The current (and widely deployed) definition of href would produce exactl= y > what you define as toASCII below. And, in fact, is used for HTTP. > > OK. I'd actually prefer those to stay unicode, and in particular wouldn't have expected hostnames to be rewritten to ASCII. I particularly don't like this because it means for computed URL objects, it'll lose the internationalization, so it can't be used for display anywhere, which seems unfortunate to say the least. > u.canonical =3D> http://caf=C3=A9.im/ty < >> http://xn--caf-dma.im/ty> >> > > The use case for this would need to be provided. > > Comparison for equivalency. > u.toASCII() =3D> http://xn--caf-dma.im/t%C5%B7 >> > > Again, this result is indistinguishable from .href. > > How hard would it be to persuade parser implementors to do this? >> > > The canonical case concerns me most, as it is both a lot of work and ther= e > doesn't seem to be agreement as to what canonicalization means. See: > > http://intertwingly.net/blog/2004/07/31/URI-Equivalence > > Those results were produced over a decade ago. I reran those tests > recently, and saw zero change. :-( > > It's the part that interests me most, actually. In part, because I think once canonicalization is properly understood, the rest just falls out. It *is* the hardest part, I agree. > Dave. >> > > - Sam Ruby > > [1] http://www.zytrax.com/books/ldap/apa/types.html#strings > --001a11c2f49aa2effb050cc8614f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 16 January 2015 at 15:43, Sam Ruby <rubys@intertwingly.net= > wrote:
On 01= /16/2015 08:57 AM, Dave Cridland wrote:

Taking the example of LDAP, this relies on schemas where a URI is
transported in a IA5String, which is ASCII-only (loosely, it's actually=
7-bit ASCII supersets).

Allowing non-ASCII breaks this, no matter how we wave magic wands about
parsers - the parser simply never gets to see the URI, because the BER
decoder (or whatever) throws an error.

 You and I have different ideas of "magic wands".=C2=A0 I will als= o note that I personally dislike this style of discourse.


Actually you've entirely misunders= tood my use of the term. I wasn't being flippant in this instance, and = my apologies if I inadvertently sounded that way. I do try to make it very = clear when I *am* being flippant.
=C2=A0
Whatever they are called (URI, IRI, URL), as commonly practiced they may co= ntain fragments and those fragments may contain bytes with the high order b= it on.


What they're called makes a distin= ct difference here. URIs as specified are 7-bit clean, IRIs as specified ar= e a unicode sequence of codepoints.
=C2=A0
The exists specs that make claims that such values aren't valid.=C2=A0 = There exists software components (e.g. parses) that purport to convert URIs= , IRIs, or URLs into spec compliant strings.=C2=A0 As a general rule, they = do things differently.=C2=A0 In particular, most leave fragments alone.=C2= =A0 Even when they contain characters with a high order bit on.

People who read such specs and the high level descriptions of said software= components may indeed be mislead into designing schema choosing the wrong = type of string[1], and that choice will cause runtime failures to occur.
Given the above, and using your term ("magic wand"), it is my bel= ief that the attempt to invoke "magic" occurs in the existing spe= cification, and that the choice to do so does a disservice to the readers.<= br>
Note: it would be presumptuous of me to assume that my perception of where = the "magic wand" occurs in this scenario is shared with you. Plea= se permit me the same courtesy.


By use of the term "magic = wand", I did not mean in the sense you seem to imply of a religious te= xt, I meant a device which enables the wielder warp reality in an [otherwis= e] impossible manner.

The "magic wand" l= ies in the problems of declaring one side the winner without considering th= e damage it'll have on the losing side, as it were. To safely fix the d= amage in any reasonable timeframe may require such a wand.

If we say "fragments are 7-bit in URIs", then these pars= ers will be fine on valid URIs. We're in a situation of garbage in, gar= bage out.

If we say "fragments can be any cod= epoint", then X.509 breaks - given there are X.509 certificates blown = into silicon, and in every DoD CAC, for example, this is problematic, to va= rious degrees. There are fixes, of course - we would have to retire the old= schema, and possibly the containing extension, and replace it. There'l= l be a crossover period of decades for this, where both extensions need to = be supported, and some URLs will be unrepresentable in some X.509 systems d= uring this period. Having two extensions fulfilling the same function is a = worrying thought in a security protocol, and I've little doubt there= 9;d be an excitingly named TLS exploit with a beautifully designed logo as = a result.

URIs embedded into X.509 certificates in= clude, for example, CRL Distribution Points and OCSP Responders, and are th= erefore security-critical. So my question is why you consider that the runn= ing code you cite should be accorded more weight than the combination of th= e running code others have cited *and* the specification?

Of course, you can also say "fragments are unicode in my very = own URLs, here is a transformation to turn them into URIs", but then..= .

That said, we clearly do have the
IRI specifications (and their bis drafts), and if there is interest from the W3C I think we could find the energy to complete that work.

 Finding the energy to complete the IRI work would indeed be a game changer.= =C2=A0 At the moment, I'm skeptical, but suffice it to say that I would= be very interested if that came to pass.

Until that time, my intent I view with skepticism any and all use of the te= rm IRI.


... you're set on a path of either= completing the IRI work, or duplicating it.
=C2=A0
How would you feel about the possibility of having an API that looked
somewhat like this:

Given:

u =3D new URL(S) # Accepts strictly valid, and certain invalid, IRIs.

u.href #=C2=A0 "cleaned" valid IRI string, with any syntax cleane= d according
to rules.

u.canonical # "canonical" IRI string.

u.toASCII() # "cleaned" URI string, for use in HTTP, LDAP, etc.
So with S as http://caf=C3=A9.im:80/t=C5=B7/%2e <http://xn--caf-dma.im:80/t%C= 5%B7/%2e>

u.href =3D> http://caf=C3=A9.im:80/t=C5=B7/ <http://xn--caf-dma.im:80/t%C5%B7/>.
(although variants allowed)

The current (and widely deployed) definition of href would produce exactly = what you define as toASCII below.=C2=A0 And, in fact, is used for HTTP.


OK. I'd actually prefer those to s= tay unicode, and in particular wouldn't have expected hostnames to be r= ewritten to ASCII. I particularly don't like this because it means for = computed URL objects, it'll lose the internationalization, so it can= 9;t be used for display anywhere, which seems unfortunate to say the least.=
=C2=A0
u.canonical =3D> = http://caf=C3=A9.im/ty <http://xn--caf-dma.im/ty>

The use case for this would need to be provided.


Comparison for equivalency.
= =C2=A0
u.toASCII() =3D> http://xn--caf-dma.im/t%C5%B7

Again, this result is indistinguishable from .href.

How hard would it be to persuade parser implementors to do this?

 The canonical case concerns me most, as it is both a lot of work and there = doesn't seem to be agreement as to what canonicalization means.=C2=A0 S= ee:

http://intertwingly.net/blog/2004/07/31/URI-Equivalence<= /a>

Those results were produced over a decade ago.=C2=A0 I reran those tests re= cently, and saw zero change.=C2=A0 :-(


=
=C2=A0
Dave.

- Sam Ruby

[1] http://www.zytrax.com/books/ldap/apa/types.html#strin= gs

--001a11c2f49aa2effb050cc8614f-- From nobody Sat Jan 17 07:25:33 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A501ACD69 for ; Sat, 17 Jan 2015 07:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGJJwMB2JQzM for ; Sat, 17 Jan 2015 07:25:28 -0800 (PST) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id D43C01ACD81 for ; Sat, 17 Jan 2015 07:25:27 -0800 (PST) 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 1YCVFd-0002Nv-hG; Sat, 17 Jan 2015 15:25:25 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YCVFd-0004ot-Gm; Sat, 17 Jan 2015 15:25:25 +0000 Message-ID: <54BA7EE2.1040102@ninebynine.org> Date: Sat, 17 Jan 2015 15:25:22 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B806A2.8020803@intertwingly.net>, <54b9381b.8ca1e00a.243f.ffffcae4@mx.google.com> <98A81DE7-1845-46EC-A3EB-F00438863ECB@seantek.com> <54B93F2A.5070900@intertwingly.net> In-Reply-To: <54B93F2A.5070900@intertwingly.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jan 2015 15:25:30 -0000 On 16/01/2015 16:41, Sam Ruby wrote: > As to what the breakage it, that is less clear to me. There are existing > parsers that don't percent encode square brackets when they occur at some point > after a question mark is encountered in the input. Perhaps those parsers lose > the ability to claim that they are "RFC 3986 compliant". Surely, it's not the role of a *parser* to %-encode, but a *generator* of URIs? The primary role of a URI parser is to simply decide if a given string is or is not a valid URI. A parser can only be RFC3986-compliant in the extent to which it correctly makes this determination in accordance with RFC3986. Of course, parsers may do more than this, but the detail of such behaviour is not specified by RFC3986. (I would say that a *generator* of URIs that does not %-encode square brackets in fragments is not RFC3986 compliant.) #g -- From nobody Sat Jan 17 07:31:22 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0561ACDAF for ; Sat, 17 Jan 2015 07:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8hLBa-Fzhg4 for ; Sat, 17 Jan 2015 07:31:18 -0800 (PST) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id BBAEE1ACDB7 for ; Sat, 17 Jan 2015 07:31:16 -0800 (PST) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YCVLI-0003Cc-gS for apps-discuss@ietf.org; Sat, 17 Jan 2015 15:31:16 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YCVLH-0001Xq-G3 for apps-discuss@ietf.org; Sat, 17 Jan 2015 15:31:16 +0000 Message-ID: <54BA8043.90501@ninebynine.org> Date: Sat, 17 Jan 2015 15:31:15 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54B16C2B.9050604@seantek.com> <54B17BBE.4000900@intertwingly.net> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B806A2.8020803@intertwingly.net>, <54b9381b.8ca1e00a.243f.ffffcae4@mx.google.com>, <54B93CB4.7060805@intertwingly.net> <54b94026.5229e00a.77ab.ffffd0d7@mx.google.com> In-Reply-To: <54b94026.5229e00a.77ab.ffffd0d7@mx.google.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jan 2015 15:31:20 -0000 On 16/01/2015 16:42, darrel.miller@gmail.com wrote: >> It is not a valid IP-literal, but it is a valid reg-name (at least >> according to the ABNF): >> >> host = IP-literal / IPv4address / reg-name >> reg-name = *( unreserved / pct-encoded / sub-delims ) >> >> See also: >> >> https://lists.w3.org/Archives/Public/public-ietf-w3c/2014Dec/0075.html > > > > That is unfortunate. Thanks for pointing that out, I was not aware of that potential for ambiguity. (Aside, not central to the main discussion...) FWIW, RFC3986 is explicit that the formal syntax is ambiguous, and describes use of a "first-match-wins" algorithm to obtain an unambiguous parse. (Personally, I'm not a fan of this approach, but I don't see it as a great problem.) Cf. https://tools.ietf.org/html/rfc3986#section-3.2.2 #g -- From nobody Sat Jan 17 07:52:05 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AD21ACDDE for ; Sat, 17 Jan 2015 07:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqCyttoXxSMV for ; Sat, 17 Jan 2015 07:52:00 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 625391ACDD4 for ; Sat, 17 Jan 2015 07:51:59 -0800 (PST) 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 t0HFpnB6021865; Sat, 17 Jan 2015 15:51:53 GMT 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 t0HFpnrY016581; Sat, 17 Jan 2015 15:51:49 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id t0HFpmvs026009; Sat, 17 Jan 2015 15:51:48 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id t0HFplng026005; Sat, 17 Jan 2015 15:51:47 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Julian Reschke References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <54B924B0.40105@seantek.com> <54B9458D.9070403@gmx.de> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Sat, 17 Jan 2015 15:51:47 +0000 In-Reply-To: <54B9458D.9070403@gmx.de> (Julian Reschke's message of "Fri\, 16 Jan 2015 18\:08\:29 +0100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (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: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Terminology and scope of [UI]Rx-like objects X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jan 2015 15:52:03 -0000 Julian Reschke writes: > On 2015-01-16 16:13, Henry S. Thompson wrote: >> ... >> It has become increasingly necessary to take the distinction I'm >> concerned with seriously as time has gone by, not just because of the >> advent of UCS, but because of the expanded requirements of the >> human-facing context of use. I'm thinking here particularly of the >> status of the space character. >> ... > > When RFC 3987 was written, adding SP to the set of allowed characters > was considered. However, it's in conflict with cases where formats > need a white-space separated list of identifiers, or use whitespace as > delimiters around identifiers, and that's why RFC 3987 stayed > consistent with 3986. Indeed. And that's exactly why the LEIRI spec. says "caution needed" [1]. On balance, I think the scales _just_ tip towards allowing space in the human-facing context, but do _not_ tip for the low-level protocol context. That is, I think 3986 was right _not_ to allow it and LEIRIs are right _to_ allow it. 3987 has a weakness, in my view, which is that it hasn't fully commited to being a high-level human-facing standard, always layered on top of/mapping onto 3986 when used in e.g. HTTP or LDAP transactions. Until that is clarified, it's hard to have a sensible discussion about whether e.g. space should be allowed in IRIs or not. ht [1] http://www.w3.org/TR/leiri/#charStatus -- 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 Sat Jan 17 09:43:44 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840E71ACD45 for ; Sat, 17 Jan 2015 09:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOJtgRnq-yVJ for ; Sat, 17 Jan 2015 09:43:41 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0790.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::790]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5FF1ACD44 for ; Sat, 17 Jan 2015 09:43:40 -0800 (PST) Received: from pc6 (81.151.167.59) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.53.17; Sat, 17 Jan 2015 17:38:11 +0000 Message-ID: <02ca01d0327c$368eb500$4001a8c0@gateway.2wire.net> From: t.petch To: Matthew Kerwin References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com><036301d02e94$15a95200$4001a8c0@gateway.2wire.net><01d501d02f36$530acaa0$4001a8c0@gateway.2wire.net> Date: Sat, 17 Jan 2015 17:34:08 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: AMSPR02CA0033.eurprd02.prod.outlook.com (10.242.225.161) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB3PR07MB060; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DB3PR07MB060; X-Forefront-PRVS: 04599F3534 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(51444003)(189002)(77096005)(229853001)(77156002)(122386002)(62236002)(47776003)(44716002)(42186005)(61296003)(68736005)(97736003)(14496001)(1456003)(84392001)(33646002)(66066001)(62966003)(64706001)(230783001)(116806002)(19580395003)(87976001)(101416001)(93886004)(50226001)(50466002)(44736004)(92566002)(40100003)(105586002)(86362001)(46102003)(110136001)(76176999)(81816999)(81686999)(50986999)(106356001)(23676002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jan 2015 17:38:11.4334 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060 Archived-At: Cc: IETF Apps Discuss Subject: [apps-discuss] draft-ietf-appsawg-file Reserved characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jan 2015 17:43:43 -0000 Matthew Assuming that the minicharter requires us to conform to RFC3986, then I think that s.2 has to be changed to remove the vertical bar (³ ?). RFC6874 has the same issue and the idea of updating RFC3986 to change the reserved and unreserved character sets was roundly rejected by the IETF, although the character in question was in widespread use by some browsers, in contravention of RFC3986. I think you will have to follow the same pattern, that the formal syntax for file: must conform to RFC3986 but an explanatory note can say that there is this non-conforming variant in use (but SHOULD NOT be). RFC6874 also picks up on the difference between a URI and a browser box, that the latter can contain anything, such as c| \\host.example.com which can be rendered into a conformant URI. I think that this I-D should also cover this. Tom Petch From nobody Sat Jan 17 11:00:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F441ACF02 for ; Sat, 17 Jan 2015 11:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1S3pU3OPzkvx for ; Sat, 17 Jan 2015 11:00:22 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.228]) by ietfa.amsl.com (Postfix) with ESMTP id C9E001ACD4E for ; Sat, 17 Jan 2015 11:00:21 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:50099] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 3B/4B-15759-441BAB45; Sat, 17 Jan 2015 19:00:21 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 5CE9B140872; Sat, 17 Jan 2015 14:00:20 -0500 (EST) Message-ID: <54BAB143.1080006@intertwingly.net> Date: Sat, 17 Jan 2015 14:00:19 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Graham Klyne , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B806A2.8020803@intertwingly.net>, <54b9381b.8ca1e00a.243f.ffffcae4@mx.google.com> <98A81DE7-1845-46EC-A3EB-F00438863ECB@seantek.com> <54B93F2A.5070900@intertwingly.net> <54BA7EE2.1040102@ninebynine.org> In-Reply-To: <54BA7EE2.1040102@ninebynine.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jan 2015 19:00:23 -0000 On 01/17/2015 10:25 AM, Graham Klyne wrote: > On 16/01/2015 16:41, Sam Ruby wrote: >> As to what the breakage it, that is less clear to me. There are existing >> parsers that don't percent encode square brackets when they occur at >> some point >> after a question mark is encountered in the input. Perhaps those >> parsers lose >> the ability to claim that they are "RFC 3986 compliant". > > Surely, it's not the role of a *parser* to %-encode, but a *generator* > of URIs? > > The primary role of a URI parser is to simply decide if a given string > is or is not a valid URI. A parser can only be RFC3986-compliant in the > extent to which it correctly makes this determination in accordance with > RFC3986. Of course, parsers may do more than this, but the detail of > such behaviour is not specified by RFC3986. > > (I would say that a *generator* of URIs that does not %-encode square > brackets in fragments is not RFC3986 compliant.) As many people have pointed out, nomenclature seems to be a big problem here. I started to write a reply that spells this out, but I realized that I was repeating things that I've said before, and figured it made sense to pull it out into a separate blog post that I can point to: http://intertwingly.net/blog/2015/01/17/RFC-3986bis TL;DR: URL parsers consume URLs and generate URIs. Such URIs are not RFC 3986 complaint. I’d like to fix that. > #g > -- - Sam Ruby From nobody Sat Jan 17 11:58:49 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E751ACECB for ; Sat, 17 Jan 2015 11:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMmK9FiV1dfE for ; Sat, 17 Jan 2015 11:58:45 -0800 (PST) Received: from nm17-vm6.bullet.mail.ne1.yahoo.com (nm17-vm6.bullet.mail.ne1.yahoo.com [98.138.91.110]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0FD1ACD82 for ; Sat, 17 Jan 2015 11:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1421524724; bh=XoDtVWzN6s4n9nI2zD+iErMxmbaTL20+0/UpgBI/jP0=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From:Subject; b=rUBRrVEXayYScIon5vaQXy7Z7X2w7NE74s6qcnRExcMVhBwVlt8vxaicLdRER3YmoDw4myquUUSwPWFpKI3ltyeDAZqi7Rw+GToeQd0YKfAEpgK6Q7LirLFXuXZRCq0GwjgAdwjlTi+fEp5DhgUSdD0X0KZhj6pN1d71MMoIIeK94uVTvVCsC+c8ziC0+/vf8gR/VGyUdirR4UoxEhHymk952sixNodWF8vLioVC8GPWaUvYUt94k4v1vMopnxvhDTGeGDpW09vi1Dq8zKTlgzyS5Nva0gIowOqCiwTeQYGz2bkP5OwXJCm9q0JuTMzjp4efNpU/CZEgAZ11uGgC5g== Received: from [98.138.100.102] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 17 Jan 2015 19:58:44 -0000 Received: from [98.138.104.116] by tm101.bullet.mail.ne1.yahoo.com with NNFMP; 17 Jan 2015 19:58:44 -0000 Received: from [127.0.0.1] by smtp225.mail.ne1.yahoo.com with NNFMP; 17 Jan 2015 19:58:44 -0000 X-Yahoo-Newman-Id: 724084.1038.bm@smtp225.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: S7P8FmcVM1m2r97S8wYMib39y7PcyEUyjaxVMZhnBCwBRjp 30kykaCUUdcbMSkpuAxsrQgxrLrLw2M2LR_b_MLB1iPkENLa_e24.CBaiRvz _Ngls7aaqZMwBnJchtjq50od9dY9yBkYCQgIVP2a20E72MfXb9kD23_c5cg1 NMh8fEb7Xpr_V72KEGP526kvxnkv6O9owlJTdMWWVp42rnilL11WniJxJTsl 0LbMj25wJ4SVkc4ObTexz1lXgwhWNuLk02Xfg5KdvtBuia.N7tra2lp3m8nS i6Lt0VuAdyJcEeNUBgFCA2SHSz1.0Tnht8JMPCoOyOBms2V8OBwOMcXNDujw kYkYzOcxJcJ6v2OIzWRYcj1k0JWGMoQIxE_67HhVphwfXOEk6hX86E0lLfkg cbjWETLr6_ETJdCp389Neuy3sRDpnWGg6p7WZJEZAkUtaBN34Up.ZBjekX0T mW2GVkpm_VXzLBBNFQIkUtbn9WivnlWBvXNLOcUDHb29nSI_BFW8yrn0wEi2 hv0oqP6SUFHAau4fQAR2sLEUT.6Tl.J3B9VsjEaoGOT2uXLXIfDd1yAKbYFG AuQkjoHL89SfavE5Ww3EX2SAslCBetHwrSggX8kUtdsYd9yXZf5s4kgc8ouL OSL2p9Rh0NO.RXHuyoSZ9HWGE4dQC2mWHtVBKHYp73FVxKkKk5QGNp4Q0jhM Uf2FZM.0cIgP6OJg2n7NbIjvd3FjWNt1z6WBJGcMHEnWJK6145HV2OQwhmOT OYtOxdWiWyA-- X-Yahoo-SMTP: i12ABOmswBAkPG1PnjmsmmFRWA-- Received: by mail-lb0-f169.google.com with SMTP id f15so2501966lbj.0 for ; Sat, 17 Jan 2015 11:58:42 -0800 (PST) X-Gm-Message-State: ALoCoQmUryMVvWhFVFoXvXQ/+oV8TnEaH04lq4PLsKUrVJZX740yjPIKUcsOzY5Y1yJqpW+qLbTV X-Received: by 10.112.156.169 with SMTP id wf9mr21810163lbb.85.1421524722458; Sat, 17 Jan 2015 11:58:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.166.203 with HTTP; Sat, 17 Jan 2015 11:58:21 -0800 (PST) In-Reply-To: <54BAB143.1080006@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B806A2.8020803@intertwingly.net> <54b9381b.8ca1e00a.243f.ffffcae4@mx.google.com> <98A81DE7-1845-46EC-A3EB-F00438863ECB@seantek.com> <54B93F2A.5070900@intertwingly.net> <54BA7EE2.1040102@ninebynine.org> <54BAB143.1080006@intertwingly.net> From: mike amundsen Date: Sat, 17 Jan 2015 14:58:21 -0500 Message-ID: To: Sam Ruby Content-Type: multipart/alternative; boundary=001a11c240b01f3e6e050cde84af Archived-At: Cc: Graham Klyne , IETF Apps Discuss Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jan 2015 19:58:47 -0000 --001a11c240b01f3e6e050cde84af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sam: i might be missing some key points but.. What is effectively being said is that documenting how things actually work will break things, which is clearly untrue. let's not confuse "changing the specification" with "documenting." documenting NEVER breaks things. changing a specification MAY break things= . if all this is about is writing *documentation*, have at it. if you want to write some BCPs, no worries. but if the work involves changing specifications, as long as those changes are made in ways that do not break existing *spec-compliant* implementations, i have no problem with the work. changing shared specs to match one or more existing non-compliant implementations is rarely the right approach. mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://linkedin.com/in/mamund On Sat, Jan 17, 2015 at 2:00 PM, Sam Ruby wrote: > On 01/17/2015 10:25 AM, Graham Klyne wrote: > >> On 16/01/2015 16:41, Sam Ruby wrote: >> >>> As to what the breakage it, that is less clear to me. There are existi= ng >>> parsers that don't percent encode square brackets when they occur at >>> some point >>> after a question mark is encountered in the input. Perhaps those >>> parsers lose >>> the ability to claim that they are "RFC 3986 compliant". >>> >> >> Surely, it's not the role of a *parser* to %-encode, but a *generator* >> of URIs? >> >> The primary role of a URI parser is to simply decide if a given string >> is or is not a valid URI. A parser can only be RFC3986-compliant in the >> extent to which it correctly makes this determination in accordance with >> RFC3986. Of course, parsers may do more than this, but the detail of >> such behaviour is not specified by RFC3986. >> >> (I would say that a *generator* of URIs that does not %-encode square >> brackets in fragments is not RFC3986 compliant.) >> > > As many people have pointed out, nomenclature seems to be a big problem > here. I started to write a reply that spells this out, but I realized th= at > I was repeating things that I've said before, and figured it made sense t= o > pull it out into a separate blog post that I can point to: > > http://intertwingly.net/blog/2015/01/17/RFC-3986bis > > TL;DR: URL parsers consume URLs and generate URIs. Such URIs are not RFC > 3986 complaint. I=E2=80=99d like to fix that. > > #g >> -- >> > > - Sam Ruby > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a11c240b01f3e6e050cde84af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sam:

i might be missing some key points= but..

<snip>
What is effectively being said i= s that documenting how things actually work will break things, which is cle= arly untrue.
</snip>

let's not confuse "chan= ging the specification" with "documenting." =C2=A0documentin= g NEVER breaks things. changing a specification MAY break things.

if all this is about is writing *documentation*, have at it= . if you want to write some BCPs, no worries.

but = if the work involves changing specifications, as long as those changes are = made in ways that do not break existing *spec-compliant* implementations, i= have no problem with the work.=C2=A0

changing sha= red specs to match one or more existing non-compliant implementations is ra= rely the right approach.=C2=A0



On Sat, Jan 17, 2015 at 2:00 PM, Sam Ruby <rubys@intertwingly.net> wrote:
On 01/17/2015 10:25 AM, Graham Klyne wrote:
On 16/01/2015 16:41, Sam Ruby wrote:
As to what the breakage it, that is less clear to me.=C2=A0 There are exist= ing
parsers that don't percent encode square brackets when they occur at some point
after a question mark is encountered in the input. Perhaps those
parsers lose
the ability to claim that they are "RFC 3986 compliant".

Surely, it's not the role of a *parser* to %-encode, but a *generator*<= br> of URIs?

The primary role of a URI parser is to simply decide if a given string
is or is not a valid URI.=C2=A0 A parser can only be RFC3986-compliant in t= he
extent to which it correctly makes this determination in accordance with RFC3986.=C2=A0 Of course, parsers may do more than this, but the detail of<= br> such behaviour is not specified by RFC3986.

(I would say that a *generator* of URIs that does not %-encode square
brackets in fragments is not RFC3986 compliant.)

 As many people have pointed out, nomenclature seems to be a big problem her= e.=C2=A0 I started to write a reply that spells this out, but I realized th= at I was repeating things that I've said before, and figured it made se= nse to pull it out into a separate blog post that I can point to:

http://intertwingly.net/blog/2015/01/17/RFC-3986bis

TL;DR: URL parsers consume URLs and generate URIs.=C2=A0 Such URIs are not = RFC 3986 complaint.=C2=A0 I=E2=80=99d like to fix that.

#g
--

- Sam Ruby

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

--001a11c240b01f3e6e050cde84af-- From nobody Sat Jan 17 12:21:32 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86A31AD0A9 for ; Sat, 17 Jan 2015 12:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoyRIvxBueeB for ; Sat, 17 Jan 2015 12:21:29 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.227]) by ietfa.amsl.com (Postfix) with ESMTP id 34A9A1AD06A for ; Sat, 17 Jan 2015 12:21:29 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:59571] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 15/87-15759-844CAB45; Sat, 17 Jan 2015 20:21:28 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 433A6140AEA; Sat, 17 Jan 2015 15:21:28 -0500 (EST) Message-ID: <54BAC447.7030706@intertwingly.net> Date: Sat, 17 Jan 2015 15:21:27 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: mike amundsen References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B806A2.8020803@intertwingly.net> <54b9381b.8ca1e00a.243f.ffffcae4@mx.google.com> <98A81DE7-1845-46EC-A3EB-F00438863ECB@seantek.com> <54B93F2A.5070900@intertwingly.net> <54BA7EE2.1040102@ninebynine.org> <54BAB143.1080006@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: Cc: Graham Klyne , IETF Apps Discuss Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jan 2015 20:21:31 -0000 On 01/17/2015 02:58 PM, mike amundsen wrote: > Sam: > > i might be missing some key points but.. > > > What is effectively being said is that documenting how things actually > work will break things, which is clearly untrue. > > > let's not confuse "changing the specification" with "documenting." > documenting NEVER breaks things. changing a specification MAY break > things. > > if all this is about is writing *documentation*, have at it. if you want > to write some BCPs, no worries. > > but if the work involves changing specifications, as long as those > changes are made in ways that do not break existing *spec-compliant* > implementations, i have no problem with the work. I have trouble with the words "existing *spec-compliant* implementations". Either that term is meaningless, or I have yet to find one. LDAP schemas that make use of IA5String can be said to be spec compliant in that they accept all RFC 3986 compliant URIs. But that's quite a different matter than saying that they implement RFC 3986 in any meaningful way. I've taken a look at a lot of libraries that produce and consume URIs (some call them URLs, but lets not worry about that for the moment). I have yet to find one that is spec compliant. > changing shared specs to match one or more existing non-compliant > implementations is rarely the right approach. There are a large and growing number of non-RFC 3986 compliant applications today. I am working with a small and growing number of developers of these libraries. I am building a shared specification to which these applications will be compliant. When done I will have a large list of compliant applications that I can point to. I would like to see that there be an update to RFC 3986 so that I can build upon that as a base. But that's merely a desire, not a blocker. > mamund > +1.859.757.1449 > skype: mca.amundsen > http://amundsen.com/blog/ > http://twitter.com/mamund > https://github.com/mamund > http://linkedin.com/in/mamund - Sam Ruby > On Sat, Jan 17, 2015 at 2:00 PM, Sam Ruby > wrote: > > On 01/17/2015 10:25 AM, Graham Klyne wrote: > > On 16/01/2015 16:41, Sam Ruby wrote: > > As to what the breakage it, that is less clear to me. There > are existing > parsers that don't percent encode square brackets when they > occur at > some point > after a question mark is encountered in the input. Perhaps those > parsers lose > the ability to claim that they are "RFC 3986 compliant". > > > Surely, it's not the role of a *parser* to %-encode, but a > *generator* > of URIs? > > The primary role of a URI parser is to simply decide if a given > string > is or is not a valid URI. A parser can only be > RFC3986-compliant in the > extent to which it correctly makes this determination in > accordance with > RFC3986. Of course, parsers may do more than this, but the > detail of > such behaviour is not specified by RFC3986. > > (I would say that a *generator* of URIs that does not %-encode > square > brackets in fragments is not RFC3986 compliant.) > > > As many people have pointed out, nomenclature seems to be a big > problem here. I started to write a reply that spells this out, but > I realized that I was repeating things that I've said before, and > figured it made sense to pull it out into a separate blog post that > I can point to: > > http://intertwingly.net/blog/__2015/01/17/RFC-3986bis > > > TL;DR: URL parsers consume URLs and generate URIs. Such URIs are > not RFC 3986 complaint. I’d like to fix that. > > #g > -- > > > - Sam Ruby > > _________________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/__listinfo/apps-discuss > > > From nobody Sat Jan 17 13:46:07 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27311AD259 for ; Sat, 17 Jan 2015 13:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.172 X-Spam-Level: X-Spam-Status: No, score=0.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sgg-n_d9VMEx for ; Sat, 17 Jan 2015 13:46:04 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E031AD190 for ; Sat, 17 Jan 2015 13:46:04 -0800 (PST) Received: by mail-qg0-f42.google.com with SMTP id q107so7281865qgd.1 for ; Sat, 17 Jan 2015 13:46:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lWxNjZJjVqEoRsOhS+6gWyrVmTjfFdC3WnHzPU0YK2c=; b=Dv7sXOY0/xvt9eX8bh7oc9Pk+G2p6BI9p3vg5UQmJwdDninYav26U2JFXk2G6OoC0K VnNj4TDI6kVy452JE1GI6jsmU/9ffXx4zPjDxPqKZCs8F6bD/ZiqyKxKfi0IkfTigscq 8SvTrqwCbJuHCJfE1D02ZCVXfq1zIOUyebzSlvYK6WlecaSh72ct5cmXF70pcZyLk7fR iDoFU8hSr86jQE3djwERZcDXIm+1szBC1hJAh/IImXfab6agyA5GtKyJBi/90gK8QE7F M5BDy5f0iJ56d4s2x/HMOQnwOqDxCrgkA1032pX1WcAmRGeTSyAM8+6dV1qEhKty3Wp+ VSBA== MIME-Version: 1.0 X-Received: by 10.224.37.131 with SMTP id x3mr11969518qad.36.1421531163560; Sat, 17 Jan 2015 13:46:03 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.93.98 with HTTP; Sat, 17 Jan 2015 13:46:03 -0800 (PST) In-Reply-To: <02ca01d0327c$368eb500$4001a8c0@gateway.2wire.net> References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> <036301d02e94$15a95200$4001a8c0@gateway.2wire.net> <01d501d02f36$530acaa0$4001a8c0@gateway.2wire.net> <02ca01d0327c$368eb500$4001a8c0@gateway.2wire.net> Date: Sun, 18 Jan 2015 07:46:03 +1000 X-Google-Sender-Auth: lwLEJKV_DdNmHIu2lS15xHoP-yA Message-ID: From: Matthew Kerwin To: "t.petch" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-file Reserved characters X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jan 2015 21:46:06 -0000 On 18/01/2015, t.petch wrote: > Matthew > > Assuming that the minicharter requires us to conform to RFC3986, then I > think that s.2 has to be changed to remove the vertical bar (³ ?). > Yeah, that discussion has been had on the list, and was one on the motivators for suggesting separate non-normative appendices for non-conforming but oft-seen variations. I'm not sure we can entirely punt it to "human-facing", though, since historically actual machine-land URLs have included the bar character. I think it will be enough to say that they exist(ed?), and if one were to be updated to the current spec it could be translated *thus*. I am working on making this change. -- Matthew Kerwin http://matthew.kerwin.net.au/ From nobody Sat Jan 17 17:49:27 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324991ACE2A for ; Sat, 17 Jan 2015 17:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 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_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrehUSPG72FC for ; Sat, 17 Jan 2015 17:49:24 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C7C1ACD96 for ; Sat, 17 Jan 2015 17:49:24 -0800 (PST) Received: by mail-qg0-f44.google.com with SMTP id l89so12452718qgf.3 for ; Sat, 17 Jan 2015 17:49:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:from:to:cc:subject:importance:date :in-reply-to:references:content-type; bh=ztEYLRggdzPOihYx+rCdcXwvGTlKB6iO098ZVmDYL5M=; b=t2WWP5arVnkdi6s1SgPGteb8xZ+A0r6z3RIuHnswBG0rIYfShB3LeWdcBvWiXjpm7g T/LEjP1SV3Udo3K+vhiKO4JOonEsZR3rbB7xYMT/8qDl2bcLxB819Vu4adm5iqsjD5DH 4n/tAR3LOM8ruPbmBxtRZi0lOU1JKjKS8qb0YE0MkRwhE9ETZDu+Llp+GCth+WVVGCqW O0aN6ioI5Clg4WFQDCKi3viCMiJnIJAvOjEP58eh2pgdC/sbJyf7iUQC7Xm/eDYQ5Lz0 DzulEvkIKIBOJfSn9Zuacl0EDTF4R/oXcX2xVrUkONhrZEGK2NTtHDz7yqZmqZO1V31N jNUw== X-Received: by 10.140.100.248 with SMTP id s111mr35583566qge.44.1421545763604; Sat, 17 Jan 2015 17:49:23 -0800 (PST) Received: from Pecan (bas11-montreal02-1128535737.dsl.bell.ca. [67.68.22.185]) by mx.google.com with ESMTPSA id l10sm4108263qay.22.2015.01.17.17.49.22 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 17 Jan 2015 17:49:22 -0800 (PST) Message-ID: <54bb1122.4aa6e00a.410f.ffff88b3@mx.google.com> MIME-Version: 1.0 From: To: =?utf-8?Q?Sam_Ruby?= , =?utf-8?Q?mike_amundsen?= Importance: Normal Date: Sun, 18 Jan 2015 01:08:59 +0000 In-Reply-To: <54BAC447.7030706@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B806A2.8020803@intertwingly.net> <54b9381b.8ca1e00a.243f.ffffcae4@mx.google.com> <98A81DE7-1845-46EC-A3EB-F00438863ECB@seantek.com> <54B93F2A.5070900@intertwingly.net> <54BA7EE2.1040102@ninebynine.org> <54BAB143.1080006@intertwingly.net> , <54BAC447.7030706@intertwingly.net> Content-Type: multipart/alternative; boundary="_6256A262-4134-4E04-86E7-F3E49BFB5969_" Archived-At: Cc: =?utf-8?Q?IETF_Apps_Discuss?= Subject: Re: [apps-discuss] =?utf-8?q?Scope_of_RFC3986_and_successor_-_what_is?= =?utf-8?q?_a_URI=3F?= X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jan 2015 01:49:26 -0000 --_6256A262-4134-4E04-86E7-F3E49BFB5969_ Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" DQoNCg0KDQpGcm9tOiBTYW0gUnVieQ0KDQo+IEkgaGF2ZSB0cm91YmxlIHdpdGggdGhlIHdvcmRz ICJleGlzdGluZyAqc3BlYy1jb21wbGlhbnQqIGltcGxlbWVudGF0aW9ucyIuDQoNCj4gRWl0aGVy IHRoYXQgdGVybSBpcyBtZWFuaW5nbGVzcywgb3IgSSBoYXZlIHlldCB0byBmaW5kIG9uZS4NCg0K DQoNCj5JJ3ZlIHRha2VuIGEgbG9vayBhdCBhIGxvdCBvZiBsaWJyYXJpZXMgdGhhdCBwcm9kdWNl IGFuZCBjb25zdW1lIFVSSXMgDQo+KHNvbWUgY2FsbCB0aGVtIFVSTHMsIGJ1dCBsZXRzIG5vdCB3 b3JyeSBhYm91dCB0aGF0IGZvciB0aGUgbW9tZW50KS4gIEkgDQo+aGF2ZSB5ZXQgdG8gZmluZCBv bmUgdGhhdCBpcyBzcGVjIGNvbXBsaWFudC4NCg0KDQoNCkFnYWluIEkgY2FuIG9ubHkgc3BlYWsg Zm9yIHRoZSB0ZXN0cyB0aGF0IHlvdSBhcmUgZG9pbmcgb24gdGhlIGNzaGFycCBpbXBsZW1lbnRh dGlvbiwgYnV0IHRoZSB0ZXN0IHJlc3VsdHMgYXJlIGZhciBmcm9tIGNvbmNsdXNpdmUgd2hlbiBp dCBjb21lcyB0byBjb21wYXJpbmcgYWdhaW5zdCBSRkMgMzk4Ni4gIEZyb20gbG9va2luZyBhdCB5 b3VyIG1ha2VmaWxlLCBJ4oCZbSBtYWtpbmcgYSBndWVzcyB0aGF0IHlvdSBhcmUgdXNpbmcgbW9u byB0byBidWlsZCB0aGUgY3NoYXJwIGNvZGUuICBUaGUgU3lzdGVtLlVyaSBjbGFzcyBpcyBhY3R1 YWxseSBwYXJ0IG9mIHRoZSAubmV0IGZyYW1ld29yay4gIEN1cnJlbnRseSB0aGVyZSBhcmUgbXVs dGlwbGUgdmVyc2lvbnMvZWRpdGlvbnMgb2YgdGhlIC5uZXQgZnJhbWV3b3JrIGluIGFkZGl0aW9u IHRvIHRoZSBtb25vIHZlcnNpb24uICBFdmVuIHdpdGhpbiB0aGUgTWljcm9zb2Z0IC5uZXQgZnJh bWV3b3JrIHRoZXJlIGFyZSBjb25maWd1cmF0aW9uIHNldHRpbmdzIHRoYXQgY29udHJvbCBVUkkg cGFyc2luZyBiZWhhdmlvcg0KDQoNCllvdSBjYW4gdHVybiBvbiBJUkkgY29tcGxpYW50IHBhcnNp bmcgd2l0aCBhIGdsb2JhbCBzZXR0aW5nLiAgaHR0cDovL21zZG4ubWljcm9zb2Z0LmNvbS9lbi11 cy9saWJyYXJ5L2JiODgyNjAwKHY9dnMuMTEwKS5hc3B4ICBUaGUgZGVmYXVsdCBvZiB0aGlzIGds b2JhbCBzZXR0aW5nIHdhcyBjaGFuZ2VkIGZyb20gZmFsc2UgdG8gdHJ1ZSBvbiB0aGUgbW92ZSBm cm9tIC5OZXQgNC4wIHRvIDQuNS4NCg0KDQpZb3UgY2FuIGFsc28gY29uZmlndXJlIGFsbCBraW5k cyBvZiBvdGhlciBiZWhhdmlvciByZWxhdGVkIHRvIFVSSSBwYXJzaW5nDQoNCmh0dHA6Ly9tc2Ru Lm1pY3Jvc29mdC5jb20vZW4tdXMvbGlicmFyeS9iYjg4MjYxOSUyOHY9dnMuMTEwJTI5LmFzcHgN Cg0KDQpNeSByZWFzb24gZm9yIGJyaW5naW5nIHVwIHRoZXNlIGRldGFpbHMgaXMgYmVjYXVzZSBJ IGJlbGlldmUgdGhhdCBkZWNsYXJpbmcgUkZDIDM5ODYgaW52YWxpZCBiZWNhdXNlIGltcGxlbWVu dGF0aW9ucyBkb24ndCBtYXRjaCBpdHMgYmVoYXZpb3IgaXMgc2VsZi1kZWZlYXRpbmcuICBJTUhP LCBhIHNwZWMgc2hvdWxkIGJlIGEgZ29hbCB0aGF0IGltcGxlbWVudGF0aW9ucyBhaW0gZm9yLCBu b3QgYSByZWZsZWN0aW9uIG9mIHRoZSBiZWhhdmlvciBvZiBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0 IGN1cnJlbnRseSBoYXMgdGhlIGJpZ2dlc3QgbWFya2V0IHNoYXJlLg0KDQoNCkhhdmluZyBzYWlk IGFsbCB0aGlzLCBJIHdpbGwgdHJ5IGFuZCBydW4geW91ciB0ZXN0cyBvbiB2YXJpb3VzIHZlcnNp b25zIG9mIE1pY3Jvc29mdOKAmXMgLm5ldCBmcmFtZXdvcmsgYW5kIHNlZSBob3cgbXVjaCB0aGUg cmVzdWx0cyBkZXZpYXRlLiAgSSBkaWQgdHJ5IHJ1bm5pbmcgeW91ciBDIyB0ZXN0cywgYnV0IHRo ZXkgYXJlIGJhc2VkIG9uIGEgSlNPTiBmaWxlIHRoYXQgSSBiZWxpZXZlIGdldHMgY3JlYXRlZCBi eSBzb21lIGphdmFzY3JpcHQgdGhhdCBJIGRpZG7igJl0IGZpbmQuICBNeSBqcyBza2lsbHMgYXJl IGxlc3MgdGhhbiBzdGVsbGFyIQ0KDQoNCkRhcnJlbA== --_6256A262-4134-4E04-86E7-F3E49BFB5969_ Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" CjxodG1sPgo8aGVhZD4KPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJXaW5kb3dzIE1h aWwgMTcuNS45NjAwLjIwNjg5Ij4KPHN0eWxlIHR5cGU9InRleHQvY3NzIj48IS0taHRtbCB7IGZv bnQtZmFtaWx5OiAiQ29sb3IgRW1vamkiLCAiQ2FsaWJyaSIsICJTZWdvZSBVSSIsICJNZWlyeW8i LCAiTWljcm9zb2Z0IFlhSGVpIFVJIiwgIk1pY3Jvc29mdCBKaGVuZ0hlaSBVSSIsICJNYWxndW4g R290aGljIiwgInNhbnMtc2VyaWYiOyB9LS0+PC9zdHlsZT48c3R5bGUgZGF0YS1leHRlcm5hbHN0 eWxlPSJ0cnVlIj48IS0tCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGggewptYXJnaW4tdG9wOjBpbjsKbWFyZ2luLXJpZ2h0OjBpbjsK bWFyZ2luLWJvdHRvbTowaW47Cm1hcmdpbi1sZWZ0Oi41aW47Cm1hcmdpbi1ib3R0b206LjAwMDFw dDsKfQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsIHsKbWFyZ2luOjBp bjsKbWFyZ2luLWJvdHRvbTouMDAwMXB0Owp9CnAuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCwg bGkuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmly c3QsIApwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hT cE1pZGRsZSwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCAKcC5Nc29MaXN0UGFyYWdy YXBoQ3hTcExhc3QsIGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGhDeFNwTGFzdCB7Cm1hcmdpbi10b3A6MGluOwptYXJnaW4tcmlnaHQ6MGluOwptYXJnaW4t Ym90dG9tOjBpbjsKbWFyZ2luLWxlZnQ6LjVpbjsKbWFyZ2luLWJvdHRvbTouMDAwMXB0OwpsaW5l LWhlaWdodDoxMTUlOwp9Ci0tPjwvc3R5bGU+PC9oZWFkPgo8Ym9keSBkaXI9Imx0ciI+CjxkaXYg ZGF0YS1leHRlcm5hbHN0eWxlPSJmYWxzZSIgZGlyPSJsdHIiIHN0eWxlPSJmb250LWZhbWlseTog J0NhbGlicmknLCAnU2Vnb2UgVUknLCAnTWVpcnlvJywgJ01pY3Jvc29mdCBZYUhlaSBVSScsICdN aWNyb3NvZnQgSmhlbmdIZWkgVUknLCAnTWFsZ3VuIEdvdGhpYycsICdzYW5zLXNlcmlmJztmb250 LXNpemU6MTJwdDsiPjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9InBhZGRpbmctdG9wOiA1cHg7 IGJvcmRlci10b3AtY29sb3I6IHJnYigyMjksIDIyOSwgMjI5KTsgYm9yZGVyLXRvcC13aWR0aDog MXB4OyBib3JkZXItdG9wLXN0eWxlOiBzb2xpZDsiPjxkaXY+PGZvbnQgZmFjZT0iICdDYWxpYnJp JywgJ1NlZ29lIFVJJywgJ01laXJ5bycsICdNaWNyb3NvZnQgWWFIZWkgVUknLCAnTWljcm9zb2Z0 IEpoZW5nSGVpIFVJJywgJ01hbGd1biBHb3RoaWMnLCAnc2Fucy1zZXJpZiciIHN0eWxlPSdsaW5l LWhlaWdodDogMTVwdDsgbGV0dGVyLXNwYWNpbmc6IDAuMDJlbTsgZm9udC1mYW1pbHk6ICJDYWxp YnJpIiwgIlNlZ29lIFVJIiwgIk1laXJ5byIsICJNaWNyb3NvZnQgWWFIZWkgVUkiLCAiTWljcm9z b2Z0IEpoZW5nSGVpIFVJIiwgIk1hbGd1biBHb3RoaWMiLCAic2Fucy1zZXJpZiI7IGZvbnQtc2l6 ZTogMTJwdDsnPjxiPkZyb206PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpydWJ5c0BpbnRlcnR3 aW5nbHkubmV0IiB0YXJnZXQ9Il9wYXJlbnQiPlNhbSBSdWJ5PC9hPjxicj48L2ZvbnQ+PGJyPiZn dDsgSSBoYXZlIHRyb3VibGUgd2l0aCB0aGUgd29yZHMgImV4aXN0aW5nICpzcGVjLWNvbXBsaWFu dCogaW1wbGVtZW50YXRpb25zIi48YnI+PGJyPiZndDsgRWl0aGVyIHRoYXQgdGVybSBpcyBtZWFu aW5nbGVzcywgb3IgSSBoYXZlIHlldCB0byBmaW5kIG9uZS48YnI+PC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj4mZ3Q7SSd2ZSB0YWtlbiBhIGxvb2sgYXQgYSBsb3Qgb2YgbGlicmFyaWVzIHRoYXQg cHJvZHVjZSBhbmQgY29uc3VtZSBVUklzIDxicj4mZ3Q7KHNvbWUgY2FsbCB0aGVtIFVSTHMsIGJ1 dCBsZXRzIG5vdCB3b3JyeSBhYm91dCB0aGF0IGZvciB0aGUgbW9tZW50KS4mbmJzcDsgSSA8YnI+ Jmd0O2hhdmUgeWV0IHRvIGZpbmQgb25lIHRoYXQgaXMgc3BlYyBjb21wbGlhbnQuPGJyPjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+QWdhaW4gSSBjYW4gb25seSBzcGVhayBmb3IgdGhlIHRlc3Rz IHRoYXQgeW91IGFyZSBkb2luZyBvbiB0aGUgY3NoYXJwIGltcGxlbWVudGF0aW9uLCBidXQgdGhl IHRlc3QgcmVzdWx0cyBhcmUgZmFyIGZyb20gY29uY2x1c2l2ZSB3aGVuIGl0IGNvbWVzIHRvIGNv bXBhcmluZyBhZ2FpbnN0IFJGQyAzOTg2LiZuYnNwOyBGcm9tIGxvb2tpbmcgYXQgeW91ciBtYWtl ZmlsZSwgSeKAmW0gbWFraW5nIGEgZ3Vlc3MgdGhhdCB5b3UgYXJlIHVzaW5nIG1vbm8gdG8mbmJz cDtidWlsZCB0aGUgY3NoYXJwIGNvZGUuJm5ic3A7IFRoZSBTeXN0ZW0uVXJpIGNsYXNzIGlzIGFj dHVhbGx5IHBhcnQgb2YgdGhlIC5uZXQgZnJhbWV3b3JrLiZuYnNwOyBDdXJyZW50bHkgdGhlcmUg YXJlIG11bHRpcGxlIHZlcnNpb25zL2VkaXRpb25zIG9mIHRoZSAubmV0IGZyYW1ld29yayBpbiBh ZGRpdGlvbiB0byB0aGUgbW9ubyB2ZXJzaW9uLiZuYnNwOyBFdmVuIHdpdGhpbiB0aGUgTWljcm9z b2Z0IC5uZXQgZnJhbWV3b3JrIHRoZXJlIGFyZSBjb25maWd1cmF0aW9uIHNldHRpbmdzIHRoYXQg Y29udHJvbCBVUkkgcGFyc2luZyBiZWhhdmlvcjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+WW91 IGNhbiB0dXJuIG9uIElSSSBjb21wbGlhbnQgcGFyc2luZyB3aXRoIGEgZ2xvYmFsIHNldHRpbmcu Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly9tc2RuLm1pY3Jvc29mdC5jb20vZW4tdXMvbGlicmFyeS9i Yjg4MjYwMCh2PXZzLjExMCkuYXNweCIgdGFyZ2V0PSJfcGFyZW50Ij5odHRwOi8vbXNkbi5taWNy b3NvZnQuY29tL2VuLXVzL2xpYnJhcnkvYmI4ODI2MDAodj12cy4xMTApLmFzcHg8L2E+Jm5ic3A7 IFRoZSBkZWZhdWx0IG9mIHRoaXMgZ2xvYmFsIHNldHRpbmcgd2FzIGNoYW5nZWQgZnJvbSBmYWxz ZSB0byB0cnVlIG9uIHRoZSBtb3ZlIGZyb20gLk5ldCA0LjAgdG8gNC41LjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+WW91IGNhbiBhbHNvIGNvbmZpZ3VyZSBhbGwga2luZHMgb2Ygb3RoZXIgYmVo YXZpb3IgcmVsYXRlZCB0byBVUkkgcGFyc2luZzwvZGl2PjxkaXY+PGEgaHJlZj0iaHR0cDovL21z ZG4ubWljcm9zb2Z0LmNvbS9lbi11cy9saWJyYXJ5L2JiODgyNjE5JTI4dj12cy4xMTAlMjkuYXNw eCIgdGFyZ2V0PSJfcGFyZW50Ij5odHRwOi8vbXNkbi5taWNyb3NvZnQuY29tL2VuLXVzL2xpYnJh cnkvYmI4ODI2MTklMjh2PXZzLjExMCUyOS5hc3B4PC9hPjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+TXkgcmVhc29uIGZvciBicmluZ2luZyB1cCB0aGVzZSZuYnNwO2RldGFpbHMgaXMgYmVjYXVz ZSBJIGJlbGlldmUgdGhhdCBkZWNsYXJpbmcmbmJzcDtSRkMgMzk4NiZuYnNwO2ludmFsaWQgYmVj YXVzZSBpbXBsZW1lbnRhdGlvbnMmbmJzcDtkb24ndCBtYXRjaCBpdHMgYmVoYXZpb3IgaXMmbmJz cDtzZWxmLWRlZmVhdGluZy4mbmJzcDsgSU1ITywmbmJzcDthIHNwZWMgc2hvdWxkIGJlIGEgZ29h bCB0aGF0IGltcGxlbWVudGF0aW9ucyBhaW0gZm9yLCBub3QgYSByZWZsZWN0aW9uIG9mIHRoZSBi ZWhhdmlvciBvZiBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0IGN1cnJlbnRseSBoYXMgdGhlIGJpZ2dl c3QgbWFya2V0IHNoYXJlLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SGF2aW5nIHNhaWQgYWxs IHRoaXMsIEkgd2lsbCB0cnkgYW5kIHJ1biB5b3VyIHRlc3RzIG9uIHZhcmlvdXMgdmVyc2lvbnMg b2YgTWljcm9zb2Z04oCZcyAubmV0IGZyYW1ld29yayBhbmQgc2VlIGhvdyBtdWNoIHRoZSByZXN1 bHRzIGRldmlhdGUuJm5ic3A7IEkgZGlkIHRyeSBydW5uaW5nIHlvdXIgQyMgdGVzdHMsIGJ1dCB0 aGV5IGFyZSBiYXNlZCBvbiBhIEpTT04gZmlsZSB0aGF0IEkgYmVsaWV2ZSBnZXRzIGNyZWF0ZWQg Ynkgc29tZSBqYXZhc2NyaXB0IHRoYXQgSSBkaWRu4oCZdCBmaW5kLiZuYnNwOyBNeSBqcyBza2ls bHMgYXJlIGxlc3MgdGhhbiBzdGVsbGFyITwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+RGFycmVs PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48 YnI+PC9kaXY+PC9kaXY+PC9kaXY+CjwvYm9keT4KPC9odG1sPgo= --_6256A262-4134-4E04-86E7-F3E49BFB5969_-- From nobody Sat Jan 17 18:49:44 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56CD1ACD97 for ; Sat, 17 Jan 2015 18:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2pMDWe2vO9K for ; Sat, 17 Jan 2015 18:49:40 -0800 (PST) Received: from nm14-vm6.bullet.mail.ne1.yahoo.com (nm14-vm6.bullet.mail.ne1.yahoo.com [98.138.91.107]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68E601A9140 for ; Sat, 17 Jan 2015 18:49:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1421549379; bh=HAWUsAvQP6y5MqQslRfqhzuqISbCWj2OzD6Bikz0G5U=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From:Subject; b=uBEbKQIO2ABe5jZVkhukBB8OeyqYw/LYB6vuxeEAEtQcSmXPepjFM/ZUhLISq3tPZYJJs2JjdAXaPNo+lhbzD5i8ONYPJicHYlu3RqsMjD+WZIFgfPz5FVS7t7m3QCccR2Y3iOzsNjOIybgVMvDVQLanT1DJlQOUsBkYQ+AeA3Y8X5TIU9tZdSx9vPehQdndh/m5zgsk5jjrjzSiV88hqCSnkZPMayEbtW8T0g9VqSdTHI9pFNEQqiX7PHp5utdi5Q0DljooCAA6HpKOYuLalJh9iPczrvkhJDVueXghbRftu+MZMmtX6RiLOSEoWeoGg5sFhSI5qUDGkPrWBdjTRQ== Received: from [98.138.226.176] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2015 02:49:39 -0000 Received: from [98.138.226.127] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2015 02:49:39 -0000 Received: from [127.0.0.1] by smtp206.mail.ne1.yahoo.com with NNFMP; 18 Jan 2015 02:49:39 -0000 X-Yahoo-Newman-Id: 748658.95798.bm@smtp206.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: pT9KVloVM1lH9o3ySUszjGyUCf9MXR3tzrElT2.DIpWvoiJ VIy7XB.YVblgOJlWV1CC6dP_w28cR_inw18XvLWacvJ7ay_J6m9CMeIvvMN3 cZRFsy4t.SwUzsDQ5Fzhrgnx5Tm4oFY9dP7cSW8nVhxx9xxMGt..ZcZm7N41 nrfc7SPvo8pHV339yZPs1wytdkGxnKx3jHnLlbLkAYDb6oZIVY93EOWl_A47 TijDtzpdNTJMpyc9xt.91srPR5OihmzDsj0Mh0u9d2EGNfw5inyhl_4MYLmA iM4wZJaeV98f.CuiREMPgZmluUQnvDeAezYQotqFM18DysYOrCCDhJ0eakuS SbTZGikrxKpM8xx53Q2tvG7C4lwUoIZ9Q2ykFZEcAZVIIHAeI8xbKakWlt4M DnJYX5LM63lnNCERMi8FdMgZvnrwS8pP1SzYmg3nRvusGMHfPHFb4feicBL6 JdQUHvud47zBWrP9HSMBrBYRDrRLo9hMZzlfRMCH8bbpWH0I.erUQmmHZQvc g0xNmyNd8MWCwEa4gACy9EtpZ5OKhE5O.q_NtI9uutANvFXUapo.ZpAkHlbB GsIoxOgvSIhQL605bdyFXZNJLkRi8NhV0gmI2hJ_3IutXE6ovyiqTtGvo0cz DvplJr4VDm6WmleI1nJcCZZoMexDBHwQK44WOhH.Vi84rZjGltmVNW_BAJf1 TjUG8B8qO0wpXy_i40xGiQyFK6RA5GOtxVSluqnjT33bYVc940BoZCcQzQSM 73.wzE_uA.csi X-Yahoo-SMTP: i12ABOmswBAkPG1PnjmsmmFRWA-- Received: by mail-lb0-f175.google.com with SMTP id z11so23633763lbi.6 for ; Sat, 17 Jan 2015 18:49:37 -0800 (PST) X-Gm-Message-State: ALoCoQljtXDQQkWQ4jZZ9ZvNpY7TsZVzcwoaCUQWkSWOUlOomqJXq8xf2Fqj4mdMfnob8xPsAYBV X-Received: by 10.152.228.164 with SMTP id sj4mr22182001lac.98.1421549377471; Sat, 17 Jan 2015 18:49:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.166.203 with HTTP; Sat, 17 Jan 2015 18:49:16 -0800 (PST) In-Reply-To: <54BAC447.7030706@intertwingly.net> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B806A2.8020803@intertwingly.net> <54b9381b.8ca1e00a.243f.ffffcae4@mx.google.com> <98A81DE7-1845-46EC-A3EB-F00438863ECB@seantek.com> <54B93F2A.5070900@intertwingly.net> <54BA7EE2.1040102@ninebynine.org> <54BAB143.1080006@intertwingly.net> <54BAC447.7030706@intertwingly.net> From: mike amundsen Date: Sat, 17 Jan 2015 21:49:16 -0500 Message-ID: To: Sam Ruby Content-Type: multipart/alternative; boundary=001a11343716acdf3f050ce44191 Archived-At: Cc: Graham Klyne , IETF Apps Discuss Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jan 2015 02:49:43 -0000 --001a11343716acdf3f050ce44191 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Either that term is meaningless, or I have yet to find one. i can only wonder... first, these are not the only options and are not mutually exclusive. second, the phrase "spec-compliant implementation" *is* meaningful however, i suspect you're trying to say something else, as in "I challenge anyone to find a single 3986-compliant implementation anywhere, ever" or something along those lines. finally, asserting that there exist no compliant implementations (seems we're in Russell's teapot territory here) still does not give license to introduce backward-incompatible changes to the spec. again, if you are focused on *documenting* existing practices, this is all much-needed and non-controversial work. mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://linkedin.com/in/mamund On Sat, Jan 17, 2015 at 3:21 PM, Sam Ruby wrote: > On 01/17/2015 02:58 PM, mike amundsen wrote: > >> Sam: >> >> i might be missing some key points but.. >> >> >> What is effectively being said is that documenting how things actually >> work will break things, which is clearly untrue. >> >> >> let's not confuse "changing the specification" with "documenting." >> documenting NEVER breaks things. changing a specification MAY break >> things. >> >> if all this is about is writing *documentation*, have at it. if you want >> to write some BCPs, no worries. >> >> but if the work involves changing specifications, as long as those >> changes are made in ways that do not break existing *spec-compliant* >> implementations, i have no problem with the work. >> > > I have trouble with the words "existing *spec-compliant* implementations"= . > > Either that term is meaningless, or I have yet to find one. > > LDAP schemas that make use of IA5String can be said to be spec compliant > in that they accept all RFC 3986 compliant URIs. But that's quite a > different matter than saying that they implement RFC 3986 in any meaningf= ul > way. > > I've taken a look at a lot of libraries that produce and consume URIs > (some call them URLs, but lets not worry about that for the moment). I > have yet to find one that is spec compliant. > > changing shared specs to match one or more existing non-compliant >> implementations is rarely the right approach. >> > > There are a large and growing number of non-RFC 3986 compliant > applications today. > > I am working with a small and growing number of developers of these > libraries. I am building a shared specification to which these > applications will be compliant. When done I will have a large list of > compliant applications that I can point to. > > I would like to see that there be an update to RFC 3986 so that I can > build upon that as a base. But that's merely a desire, not a blocker. > > mamund >> +1.859.757.1449 >> skype: mca.amundsen >> http://amundsen.com/blog/ >> http://twitter.com/mamund >> https://github.com/mamund >> http://linkedin.com/in/mamund >> > > - Sam Ruby > > On Sat, Jan 17, 2015 at 2:00 PM, Sam Ruby > > wrote: >> >> On 01/17/2015 10:25 AM, Graham Klyne wrote: >> >> On 16/01/2015 16:41, Sam Ruby wrote: >> >> As to what the breakage it, that is less clear to me. There >> are existing >> parsers that don't percent encode square brackets when they >> occur at >> some point >> after a question mark is encountered in the input. Perhaps >> those >> parsers lose >> the ability to claim that they are "RFC 3986 compliant". >> >> >> Surely, it's not the role of a *parser* to %-encode, but a >> *generator* >> of URIs? >> >> The primary role of a URI parser is to simply decide if a given >> string >> is or is not a valid URI. A parser can only be >> RFC3986-compliant in the >> extent to which it correctly makes this determination in >> accordance with >> RFC3986. Of course, parsers may do more than this, but the >> detail of >> such behaviour is not specified by RFC3986. >> >> (I would say that a *generator* of URIs that does not %-encode >> square >> brackets in fragments is not RFC3986 compliant.) >> >> >> As many people have pointed out, nomenclature seems to be a big >> problem here. I started to write a reply that spells this out, but >> I realized that I was repeating things that I've said before, and >> figured it made sense to pull it out into a separate blog post that >> I can point to: >> >> http://intertwingly.net/blog/__2015/01/17/RFC-3986bis >> >> >> TL;DR: URL parsers consume URLs and generate URIs. Such URIs are >> not RFC 3986 complaint. I=E2=80=99d like to fix that. >> >> #g >> -- >> >> >> - Sam Ruby >> >> _________________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/__listinfo/apps-discuss >> >> >> >> --001a11343716acdf3f050ce44191 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<snip>
Either tha= t term is meaningless, or I have yet to find one.
</snip>

i can on= ly wonder...

first, these are not the only options and are not mutually exclusiv= e.

second, the phrase "spec-compliant impleme= ntation" *is* meaningful however, i suspect you're trying to say s= omething else, as in "I challenge anyone to find a single 3986-complia= nt implementation anywhere, ever" or something along those lines.

finally, asserting that there exist no compliant imple= mentations (seems we're in Russell's teapot territory here) still d= oes not give license to introduce backward-incompatible changes to the spec= .

again, if you are focused on *documenting* = existing practices, this is all much-needed and non-controversial work. =C2= =A0
=C2=A0


On Sat, Jan 17, 2015 at 3:21 PM, Sam Ruby <rubys@intertwingly.net> wrote:
On 01/17/2015 02:58 PM, mike amundsen wrote:
Sam:

i might be missing some key points but..

<snip>
What is effectively being said is that documenting how things actually
work will break things, which is clearly untrue.
</snip>

let's not confuse "changing the specification" with "doc= umenting."
=C2=A0 documenting NEVER breaks things. changing a specification MAY break<= br> things.

if all this is about is writing *documentation*, have at it. if you want to write some BCPs, no worries.

but if the work involves changing specifications, as long as those
changes are made in ways that do not break existing *spec-compliant*
implementations, i have no problem with the work.

 I have trouble with the words "existing *spec-compliant* implementatio= ns".

Either that term is meaningless, or I have yet to find one.

LDAP schemas that make use of IA5String can be said to be spec compliant in= that they accept all RFC 3986 compliant URIs.=C2=A0 But that's quite a= different matter than saying that they implement RFC 3986 in any meaningfu= l way.

I've taken a look at a lot of libraries that produce and consume URIs (= some call them URLs, but lets not worry about that for the moment).=C2=A0 I= have yet to find one that is spec compliant.

changing shared specs to match one or more existing non-compliant
implementations is rarely the right approach.

 There are a large and growing number of non-RFC 3986 compliant applications= today.

I am working with a small and growing number of developers of these librari= es.=C2=A0 I am building a shared specification to which these applications = will be compliant.=C2=A0 When done I will have a large list of compliant ap= plications that I can point to.

I would like to see that there be an update to RFC 3986 so that I can build= upon that as a base.=C2=A0 But that's merely a desire, not a blocker.<= span class=3D"">

mamund
= +1.859.757.1449
skype: mca.amundsen
http://amundsen.com= /blog/
http://twitter.com/= mamund
https://github.com/= mamund
http://linkedin= .com/in/mamund

- Sam Ruby

On Sat, Jan 17, 2015 at 2:00 PM, Sam Ruby <rubys@intertwingly.net
<mailto:ruby= s@intertwingly.net>> wrote:

=C2=A0 =C2=A0 On 01/17/2015 10:25 AM, Graham Klyne wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 16/01/2015 16:41, Sam Ruby wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 As to what the breakage it, that = is less clear to me.=C2=A0 There
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 are existing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 parsers that don't percent en= code square brackets when they
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 occur at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 some point
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 after a question mark is encounte= red in the input. Perhaps those
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 parsers lose
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the ability to claim that they ar= e "RFC 3986 compliant".


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Surely, it's not the role of a *parser* to = %-encode, but a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *generator*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of URIs?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The primary role of a URI parser is to simply d= ecide if a given
=C2=A0 =C2=A0 =C2=A0 =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is or is not a valid URI.=C2=A0 A parser can on= ly be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC3986-compliant in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 extent to which it correctly makes this determi= nation in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 accordance with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC3986.=C2=A0 Of course, parsers may do more t= han this, but the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 detail of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 such behaviour is not specified by RFC3986.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (I would say that a *generator* of URIs that do= es not %-encode
=C2=A0 =C2=A0 =C2=A0 =C2=A0 square
=C2=A0 =C2=A0 =C2=A0 =C2=A0 brackets in fragments is not RFC3986 compliant.= )


=C2=A0 =C2=A0 As many people have pointed out, nomenclature seems to be a b= ig
=C2=A0 =C2=A0 problem here.=C2=A0 I started to write a reply that spells th= is out, but
=C2=A0 =C2=A0 I realized that I was repeating things that I've said bef= ore, and
=C2=A0 =C2=A0 figured it made sense to pull it out into a separate blog pos= t that
=C2=A0 =C2=A0 I can point to:

=C2=A0 =C2=A0 http://intertwingly.net/blog/__2015/01/17/RFC= -3986bis
=C2=A0 =C2=A0 <http://intertwingly.net/blog/2015/01/17/RFC= -3986bis>

=C2=A0 =C2=A0 TL;DR: URL parsers consume URLs and generate URIs.=C2=A0 Such= URIs are
=C2=A0 =C2=A0 not RFC 3986 complaint.=C2=A0 I=E2=80=99d like to fix that.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 #g
=C2=A0 =C2=A0 =C2=A0 =C2=A0 --


=C2=A0 =C2=A0 - Sam Ruby

 =C2=A0 =C2=A0 _________________________________________________
=C2=A0 =C2=A0 apps-discuss mailing list
=C2=A0 =C2=A0 ap= ps-discuss@ietf.org <mailto:apps-discuss@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/__listinfo/apps-d= iscuss
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listinfo/apps-d= iscuss>

--001a11343716acdf3f050ce44191-- From nobody Sat Jan 17 18:53:13 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FDA1ACD97 for ; Sat, 17 Jan 2015 18:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4MbeB3JP688 for ; Sat, 17 Jan 2015 18:53:10 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.229]) by ietfa.amsl.com (Postfix) with ESMTP id 533721A9140 for ; Sat, 17 Jan 2015 18:53:10 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:64936] helo=rubix) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 46/9F-21299-5102BB45; Sun, 18 Jan 2015 02:53:09 +0000 Received: from [192.168.1.115] (unknown [192.168.1.115]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id A345B140A83; Sat, 17 Jan 2015 21:53:09 -0500 (EST) Message-ID: <54BB2014.7070500@intertwingly.net> Date: Sat, 17 Jan 2015 21:53:08 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: darrel.miller@gmail.com References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B806A2.8020803@intertwingly.net> <54b9381b.8ca1e00a.243f.ffffcae4@mx.google.com> <98A81DE7-1845-46EC-A3EB-F00438863ECB@seantek.com> <54B93F2A.5070900@intertwingly.net> <54BA7EE2.1040102@ninebynine.org> <54BAB143.1080006@intertwingly.net> , <54BAC447.7030706@intertwingly.net> <54bb1122.4aa6e00a.410f.ffff88b3@mx.google.com> In-Reply-To: <54bb1122.4aa6e00a.410f.ffff88b3@mx.google.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jan 2015 02:53:12 -0000 On 01/17/2015 08:08 PM, darrel.miller@gmail.com wrote: > > *From:* Sam Ruby > > > I have trouble with the words "existing *spec-compliant* > implementations". > > > Either that term is meaningless, or I have yet to find one. > > >I've taken a look at a lot of libraries that produce and consume URIs > >(some call them URLs, but lets not worry about that for the moment). I > >have yet to find one that is spec compliant. > > Again I can only speak for the tests that you are doing on the csharp > implementation, but the test results are far from conclusive when it > comes to comparing against RFC 3986. From looking at your makefile, I’m > making a guess that you are using mono to build the csharp code. The > System.Uri class is actually part of the .net framework. Currently > there are multiple versions/editions of the .net framework in addition > to the mono version. Even within the Microsoft .net framework there are > configuration settings that control URI parsing behavior I tried Mono at first, but saw very poor results. I then removed it from the makefile, and reran with Microsoft .Net and saw much improved results. You can see the version I ran with here: https://github.com/webspecs/url/blob/develop/evaluate/useragent-results/csharp > You can turn on IRI compliant parsing with a global setting. > http://msdn.microsoft.com/en-us/library/bb882600(v=vs.110).aspx The > default of this global setting was changed from false to true on the > move from .Net 4.0 to 4.5. > > You can also configure all kinds of other behavior related to URI parsing > http://msdn.microsoft.com/en-us/library/bb882619%28v=vs.110%29.aspx If you have new results or updates to the code to suggest, I'm interested. My preference is GitHub pull requests, but whatever works for you is fine with me. > My reason for bringing up these details is because I believe that > declaring RFC 3986 invalid because implementations don't match its > behavior is self-defeating. IMHO, a spec should be a goal that > implementations aim for, not a reflection of the behavior of an > implementation that currently has the biggest market share. I, too, believe that a spec should be a goal that implementations aim for. I also believe that spec writers should listed to implementers. I am NOT saying that that wasn't done here, but I am saying that there is clear evidence that a decade after RFC 3986 was published that implementors (with the possible exception of Microsoft?) have not adopted RFC 3986 as a goal. This includes quite a number of implementations that make claims of compatibility. I will say that in the case of Microsoft, they have identified the URL specification as one that they are considering: https://status.modern.ie/urlapi They have a developer who is working on this, and he has posted feedback to the W3C mailing list. > Having said all this, I will try and run your tests on various versions > of Microsoft’s .net framework and see how much the results deviate. I > did try running your C# tests, but they are based on a JSON file that I > believe gets created by some javascript that I didn’t find. My js > skills are less than stellar! I'll make it easier for you. You can find the json file you need here: https://url.spec.whatwg.org/interop/urltestdata.json > Darrel - Sam Ruby From nobody Sun Jan 18 13:09:42 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566261ACE16 for ; Sun, 18 Jan 2015 13:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qW7acBQv8duo for ; Sun, 18 Jan 2015 13:09:35 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0070.outbound.protection.outlook.com [65.55.169.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94A7D1ACD13 for ; Sun, 18 Jan 2015 13:09:35 -0800 (PST) Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0959.namprd02.prod.outlook.com (25.160.216.27) with Microsoft SMTP Server (TLS) id 15.1.53.17; Sun, 18 Jan 2015 21:09:33 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) by DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) with mapi id 15.01.0053.000; Sun, 18 Jan 2015 21:09:33 +0000 From: Larry Masinter To: Sam Ruby Thread-Topic: [apps-discuss] Scope of RFC3986 and successor - what is a URI? Thread-Index: AQHQMK/BbmNYRMhSwEGw8Ys6JgInPJzBF8kAgAAGVICAAAr/AIAAG5asgAAEooCAAAkQgIAAA94AgAA70ACAAB+YgIAAFYKQgAA0mYCAABAxgIABeKuAgAGoDQCAABJigIAAFm7wgACjAQCAABVEQA== Date: Sun, 18 Jan 2015 21:09:32 +0000 Message-ID: References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net> <54B7E32A.9090800@intertwingly.net> <54B82FD7.9060208@intertwingly.net> <54B86E01.5000607@intertwingly.net> <54B9B78F.3060000@intertwingly.net> <54BB2AB3.5090805@intertwingly.net> <54BBC640.5000607@intertwingly.net> In-Reply-To: <54BBC640.5000607@intertwingly.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:9:8380:992:ec21:132e:caaf:6bd0] authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DM2PR0201MB0959; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB0959; x-forefront-prvs: 046060344D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(74316001)(105586002)(86362001)(99286002)(76176999)(62966003)(50986999)(54356999)(77156002)(15975445007)(97736003)(33656002)(102836002)(64706001)(2950100001)(68736005)(46102003)(54206007)(19580395003)(110136001)(93886004)(106356001)(92566002)(122556002)(40100003)(76576001)(2656002)(106116001)(101416001)(87936001)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0959; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2015 21:09:32.8629 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB0959 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jan 2015 21:09:39 -0000 PiAgICAgICAgIFRoZSBwcmltYXJ5IHJvbGUgb2YgYSBVUkkgcGFyc2VyIGlzIHRvIHNpbXBseSBk ZWNpZGUgaWYgYSBnaXZlbg0KPiAgICAgICAgIHN0cmluZyBpcyBvciBpcyBub3QgYSB2YWxpZCBV UkkuICBBIHBhcnNlciBjYW4gb25seSBiZQ0KPiAgICAgICAgIFJGQzM5ODYtY29tcGxpYW50IGlu IHRoZSBleHRlbnQgdG8gd2hpY2ggaXQgY29ycmVjdGx5IG1ha2VzIA0KPiAgICAgICAgIHRoaXMg ZGV0ZXJtaW5hdGlvbiBpbiBhY2NvcmRhbmNlIHdpdGggUkZDMzk4Ni4NCg0KSSBkaXNhZ3JlZSB3 aXRoIGJvdGggdGhlc2Ugc2VudGVuY2VzLCBhdCBsZWFzdCBhcyBJIHVuZGVyc3RhbmQgdGhlDQp0 ZXJtcyAicHJpbWFyeSByb2xlIiwgInBhcnNlciIsICJ2YWxpZCIsICJjb21wbGlhbnQiLg0KDQpU aGUgcHJpbWFyeSByb2xlIG9mIGEgcGFyc2VyIGh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kv UGFyc2luZyNQYXJzZXINCmlzIHRvIHRha2UgaW5wdXQgZGF0YSBhbmQgZ2l2ZSBhIHN0cnVjdHVy YWwgcmVwcmVzZW50YXRpb24gb2YgdGhlIGlucHV0LA0Kd2hpbGUgY2hlY2tpbmcgZm9yIGNvcnJl Y3Qgc3ludGF4IGluIHRoZSBwcm9jZXNzLg0KDQpEZWNpZGluZyB2YWxpZGl0eSBpcyB0aGUgcm9s ZSBvZiBhIGh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvVmFsaWRhdG9yLg0KDQpSRkMgMzk4 NiBtYWlubHkgZGVmaW5lcyBjb25mb3JtYW5jZSBmb3IgVVJJcywgYW5kIEkgZG9uJ3QNCmZpbmQg YW55IDIxMTktTVVTVC9NQVkvU0hPVUxEIGZvciBwYXJzZXJzLCBzbyANCmFueSBwYXJzZXIgdGhh dCBhY2NlcHRzIHZhbGlkLXBlci0zOTg2IFVSSSBpbnB1dCBhbmQgcGFyc2VzDQppdCBzdWNjZXNz ZnVsbHkgY291bGQgYmUgImNvbmZvcm1pbmciLCAgZXZlbiBpZiBhbHNvIGFjY2VwdHMgaW52YWxp ZA0KaW5wdXQuIA0KDQoNCg0KPiBMREFQIHNjaGVtYXMgdGhhdCBtYWtlIHVzZSBvZiBJQTVTdHJp bmcgY2FuIGJlIHNhaWQgdG8gYmUgc3BlYyBjb21wbGlhbnQgDQo+IGluIHRoYXQgdGhleSBhY2Nl cHQgYWxsIFJGQyAzOTg2IGNvbXBsaWFudCBVUklzLiAgQnV0IHRoYXQncyBxdWl0ZSBhIA0KPiBk aWZmZXJlbnQgbWF0dGVyIHRoYW4gc2F5aW5nIHRoYXQgdGhleSBpbXBsZW1lbnQgUkZDIDM5ODYg aW4gYW55IA0KPiBtZWFuaW5nZnVsIHdheS4NCiANClBhc3MtdGhyb3VnaCBhcHBsaWNhdGlvbnMg dGhhdCBlbWJlZCBVUklzLCBhbmQgaW1wbGVtZW50YXRpb25zDQp0aGF0IG9ubHkgZG8gbWluaW1h bCB2YWxpZGF0aW9uIChidXQgZG9uJ3QgcmVqZWN0IGFsbCBpbnZhbGlkIGlucHV0KQ0Kc2hvdWxk IGJlIGNvdW50ZWQgYXMgbWVhbmluZ2Z1bCB1c2UgY2FzZXMgYW5kIGltcGxlbWVudGF0aW9ucw0K d2hlbiBjb25zaWRlcmluZyB3aGV0aGVyIGNoYW5nZXMgYXJlIGNvbXBhdGlibGUuDQoNClJGQyAz OTg2IGlzIGFuIEludGVybmV0IFN0YW5kYXJkLCBzZWUgIlJldmlzaW5nIGEgU3RhbmRhcmQiDQpo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjAyNiNzZWN0aW9uLTYuMyANCiANCkNoYW5n ZXMgd291bGQgYmUgYmVzdCBhY2NvbXBsaXNoZWQgYnkgbWFraW5nIGEgbmV3DQpzdGFuZGFyZCBy YXRoZXIgdGhhbiB1cGRhdGUgdGhlIG9sZCwgdW5sZXNzIGl0J3MgY2xlYXINCnRoYXQgdGhlIG92 ZXJ3aGVsbWluZyBtYWpvcml0eSBvZiB0aGUgaW5zdGFsbGVkIGJhc2UNCndvdWxkbid0IGJlIGFm ZmVjdGVkLiAgSSBkb24ndCB0aGluayB5b3VyIGV4YW1wbGVzDQptZWV0IHRoYXQgY3JpdGVyaW9u LiANCkl0J3MgcG9zc2libGUgdGhhdCBvdGhlciB1cGRhdGVzIHRvIDM5ODYgbWlnaHQuIFdlDQpz aG91bGQgZGlzY3VzczoNCg0KKiBDaGFuZ2VzIHRoYXQgbWFrZSBwcmV2aW91c2x5IGludmFsaWQg c3RyaW5ncyB2YWxpZCBVUklzDQogKGUuZy4sIGFsbG93aW5nIGFkZGl0aW9uYWwgcmVzZXJ2ZWQg QVNDSUkgY2hhcmFjdGVycyBsaWtlICMNCmFuZCA8PiAgaW4gdGhlIGZyYWdtZW50PykNCg0KKiBD aGFuZ2VzIHRoYXQgbWFrZSBwcmV2aW91c2x5IHZhbGlkIHN0cmluZ3MgaW52YWxpZA0KIChlLmcu LCBkaXNhbGxvd2luZyAyNTguMjU4LjI1OC4yNTggYXMgYSBob3N0PykgDQoNCiogQ2hhbmdlcyB0 aGF0IGFmZmVjdCBob3cgdGhlIHN0cnVjdHVyZSBvZiBVUkkgc3RyaW5ncw0KICBhcmUgZGVzY3Jp YmVkLCB0aGUgb3V0cHV0IG9mIHBhcnNpbmcuIFRoZXNlIG1pZ2h0IGJlDQogT0sgYnV0IHNvIG1h bnkgb3RoZXIgc3BlY3MgbWFrZSBub3JtYXRpdmUNCiAgcmVmZXJlbmNlIGludG8gMzk4NiB0aGF0 IGl0J3Mgd29ydGh3aGlsZSBiZWluZyBjYXV0aW91cy4NCg0KVXBkYXRpbmcgb3IgcmVwbGFjaW5n IDM5ODcgSV9JUkkgdG8gYWxpZ24gd2l0aCBXX1VSTFdXDQppcyBhIGRpZmZlcmVudCBzdG9yeSBi ZWNhdXNlIGl0J3MgYSBkaWZmZXJlbnQgc3RhdHVzLg0KDQpMYXJyeQ0KLS0NCmh0dHA6Ly9sYXJy eS5tYXNpbnRlci5uZXQNCg0K From nobody Sun Jan 18 14:52:10 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653351ACE72 for ; Sun, 18 Jan 2015 14:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJCB76pCEHOa for ; Sun, 18 Jan 2015 14:52:08 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.229]) by ietfa.amsl.com (Postfix) with ESMTP id 535D61ACE7E for ; Sun, 18 Jan 2015 14:52:08 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:43695] helo=rubix) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 61/4A-21299-7193CB45; Sun, 18 Jan 2015 22:52:07 +0000 Received: from [192.168.1.115] (unknown [192.168.1.115]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id ADAB41402BE; Sun, 18 Jan 2015 17:52:07 -0500 (EST) Message-ID: <54BC3916.7000800@intertwingly.net> Date: Sun, 18 Jan 2015 17:52:06 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Mark Nottingham , IETF Apps Discuss References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jan 2015 22:52:09 -0000 On 01/07/2015 04:35 PM, Mark Nottingham wrote: > I’ve updated my Python script that serves as a translation of ABNF for URIs into regex. > > https://gist.github.com/mnot/138549 I've attempted to convert this to JavaScript: https://url.spec.whatwg.org/reference-implementation/uri-validate.js I've built a web page that makes use of it: https://url.spec.whatwg.org/reference-implementation/uri-validate.html - - - Issues I encountered the process: 1) file_auth_path is defined with four instead of three double quotes 2) the last re.match rejects inputs that do not have a hash sign 3) extra, and potentially misleading, output is provided if instr starts with the characters "absolute:". - Sam Ruby From nobody Mon Jan 19 06:10:19 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC32B1B2A5D for ; Mon, 19 Jan 2015 06:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3dAlFVz3Tny for ; Mon, 19 Jan 2015 06:10:16 -0800 (PST) Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8601B2A2A for ; Mon, 19 Jan 2015 06:10:16 -0800 (PST) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YDD1y-0003da-po; Mon, 19 Jan 2015 14:10:14 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YDD1x-0001oX-Fl; Mon, 19 Jan 2015 14:10:13 +0000 Message-ID: <54BD1046.2060503@ninebynine.org> Date: Mon, 19 Jan 2015 14:10:14 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , apps-discuss@ietf.org References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <54B7BD4A.1090803@intertwingly.net> <54B7CF28.7060408@gmx.de> <54B7D605.2060307@intertwingly.net> <54B806A2.8020803@intertwingly.net>, <54b9381b.8ca1e00a.243f.ffffcae4@mx.google.com> <98A81DE7-1845-46EC-A3EB-F00438863ECB@seantek.com> <54B93F2A.5070900@intertwingly.net> <54BA7EE2.1040102@ninebynine.org> <54BAB143.1080006@intertwingly.net> In-Reply-To: <54BAB143.1080006@intertwingly.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Archived-At: Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jan 2015 14:10:18 -0000 On 17/01/2015 19:00, Sam Ruby wrote: > TL;DR: URL parsers consume URLs and generate URIs. Such URIs are not RFC 3986 > complaint. I’d like to fix that. That's a usage which is at odds with (or at least extends) established computer science meaning of "parser". #g From nobody Mon Jan 19 06:17:11 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2A21AD2A9 for ; Mon, 19 Jan 2015 06:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JirtcSvrRzc5 for ; Mon, 19 Jan 2015 06:16:45 -0800 (PST) Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id 389741B2A8D for ; Mon, 19 Jan 2015 06:16:45 -0800 (PST) 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 1YDD8F-0005aH-bi; Mon, 19 Jan 2015 14:16:43 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YDD8F-00022G-ES; Mon, 19 Jan 2015 14:16:43 +0000 Message-ID: <54BD11CC.7030708@ninebynine.org> Date: Mon, 19 Jan 2015 14:16:44 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Larry Masinter , Sam Ruby References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <54B7BD4A.1090803@intertwingly.net> <54B7D851.7060201@intertwingly.net> <54B7E32A.9090800@intertwingly.net> <54B82FD7.9060208@intertwingly.net> <54B86E01.5000607@intertwingly.net> <54B9B78F.3060000@intertwingly.net> <54BB2AB3.5090805@intertwingly.net> <54BBC640.5000607@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jan 2015 14:16:59 -0000 On 18/01/2015 21:09, Larry Masinter wrote: >> The primary role of a URI parser is to simply decide if a given >> string is or is not a valid URI. A parser can only be >> RFC3986-compliant in the extent to which it correctly makes >> this determination in accordance with RFC3986. > > I disagree with both these sentences, at least as I understand the > terms "primary role", "parser", "valid", "compliant". > > The primary role of a parser http://en.wikipedia.org/wiki/Parsing#Parser > is to take input data and give a structural representation of the input, > while checking for correct syntax in the process. At risk or going down an unhelpful rathole... A key phrase in your quote is "while checking for correct syntax". In the absence of a definition of a "structural representation" in RFC3986, I don't see how RFC3986 compliance can extend beyond the determination of correct syntax, which is what I meant by "valid". > > Deciding validity is the role of a http://en.wikipedia.org/wiki/Validator. Per that definition, I would say a parser is (or incorporates) a particular kind of validator. #g -- From nobody Mon Jan 19 06:36:03 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94371B2A93 for ; Mon, 19 Jan 2015 06:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TE0OmcsoMSrW for ; Mon, 19 Jan 2015 06:35:59 -0800 (PST) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id D7C5E1B2A8B for ; Mon, 19 Jan 2015 06:35:58 -0800 (PST) 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 1YDDQq-0006KG-hJ; Mon, 19 Jan 2015 14:35:56 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YDDQq-0004Hh-Gk; Mon, 19 Jan 2015 14:35:56 +0000 Message-ID: <54BD164D.3010300@ninebynine.org> Date: Mon, 19 Jan 2015 14:35:57 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sam Ruby , Nico Williams References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <54B8F225.1060308@intertwingly.net> In-Reply-To: <54B8F225.1060308@intertwingly.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] What does it mean? (Re: Scope of RFC3986 and successor - what is a URI?) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 19 Jan 2015 14:36:01 -0000 On 16/01/2015 11:12, Sam Ruby wrote: >> I don't see a need for controversy if no breaking changes are proposed. >> If some proposed changes are breaking, we can discuss their impact and >> possibly accept them, but there will be controversy. >> >> A change that would break things on paper might not, of course, and can >> be considered even if it did, but it would be controversial even if it >> turned out that the change would not be breaking in actual deployments. > > Thank you, thank you, thank you for putting this so clearly! I do believe that > "break things on paper" is necessary given my data that valid URIs are a merely > a Platonic ideal. I do believe that "breaking in actual deployments" should be > avoided. I've been mulling this comment, as I think it goes to the heart of the debate. In particular, I wholly agree that "breaking in actual deployments should be avoided" is the crux. The main point I want to make is that in considering actual deployments, the URI analyzers built into web application frameworks (such as ruby/rails, Django, Tomcat, Node, etc.) are an important part of the deployment landscape. I hazard that these may be likely areas of breakage if incompatible changes are made to the URI spec as defined by RFC3986. (If we lived in a world where all Web applications were built and designed along REST principles, including HATEOAS, then this would not be the case, but we are a long way from that, even among applications that claim to be RESTful.) A second, lesser point is that while there are many parsers that are lax in what they accept, as shown by your data, they do not of themselves cause breakage by virtue of being lax. #g -- From nobody Mon Jan 19 08:54:23 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9C81B2A0D; Mon, 19 Jan 2015 08:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nysuWKmjqBmn; Mon, 19 Jan 2015 08:54:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 670931B2B29; Mon, 19 Jan 2015 08:54:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150119165416.30306.4591.idtracker@ietfa.amsl.com> Date: Mon, 19 Jan 2015 08:54:16 -0800 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-mdn-3798bis-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 16:54:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Message Disposition Notification Authors : Tony Hansen Alexey Melnikov Filename : draft-ietf-appsawg-mdn-3798bis-01.txt Pages : 32 Date : 2015-01-19 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: http://tools.ietf.org/html/draft-ietf-appsawg-mdn-3798bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-mdn-3798bis-01 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 Tue Jan 20 03:04:44 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7409B1B29B5 for ; Tue, 20 Jan 2015 03:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.823 X-Spam-Level: *** X-Spam-Status: No, score=3.823 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTTP_ESCAPED_HOST=1.125, J_CHICKENPOX_19=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4W10nfG35BJ for ; Tue, 20 Jan 2015 03:04:40 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7806C1B29AC for ; Tue, 20 Jan 2015 03:04:40 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 329B532E55A; Tue, 20 Jan 2015 20:03:55 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 6996_b3e1_e6ec937b_1e15_486d_a53f_3beecefe83b8; Tue, 20 Jan 2015 20:03:54 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 4AA92BF4BA; Tue, 20 Jan 2015 20:03:54 +0900 (JST) Message-ID: <54BE3619.2050109@it.aoyama.ac.jp> Date: Tue, 20 Jan 2015 20:03:53 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Dave Cridland , Sam Ruby References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <54 B8F74A.70601@intertwingly.net> <54B909F4.4020908@intertwingly.net> <54B9319F.8020900@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] What does it mean? (Re: Scope of RFC3986 and successor - what is a URI?) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jan 2015 11:04:42 -0000 On 2015/01/17 02:34, Dave Cridland wrote: > On 16 January 2015 at 15:43, Sam Ruby wrote: > >> On 01/16/2015 08:57 AM, Dave Cridland wrote: >>> So with S as http://caf=C3=A9.im:80/t=C5=B7/%2e >> u.canonical =3D> http://caf=C3=A9.im/ty < >>> http://xn--caf-dma.im/ty> >>> >> >> The use case for this would need to be provided. Like Sam, I'm strongly doubting there is a use case here. > Comparison for equivalency. Definitely, 'ty' and 't=C5=B7' cannot be assumed to be equivalent. What's more, as explained in http://tools.ietf.org/html/rfc3986#section-6 comparison/equivalence isn't a single operation, because different=20 contexts need and use different equivalences. At one end are XML=20 namespaces and RDF, where even 'http://www.example.org' and=20 'Http://www.example.org' are different. At the other end are crawlers,=20 which in general don't go to 'http://www.example.org/A' if they have=20 been to 'http://www.example.org/a', because the chance that they get the=20 same thing once again is too big for them to waste time, even if there's=20 a chance that the two addresses will return totally different stuff. So any kind of 'equivalence' or 'canonicalization' or 'normalization' or=20 whatever we want to call it has to be qualified: What kind of e.g.=20 equivalence, for what. Regards, Martin. From nobody Tue Jan 20 15:15:50 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CA21A0087 for ; Tue, 20 Jan 2015 15:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zd2Ov4Lex0uJ for ; Tue, 20 Jan 2015 15:15:49 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259451A007F for ; Tue, 20 Jan 2015 15:15:49 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id z11so36477572lbi.6 for ; Tue, 20 Jan 2015 15:15:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=0/+c/PRMC+YYY0Oy+Udsp3NXh/mYv24iSbesCgxjB1A=; b=iF+81q4F2el2JM6OjjFsP+AXDNbYbPuvgU8xgKA5nGHQ424BoM0OriFfoFBePwdeWw lxhKEUtNsnMGE8CEL1vGRfNVFO4+93Mx92s8zBpapfGrjPRqtqErZgu9wT/u6pU+h2o6 RpangYmFGTQ90IUG0Xg4S7wFHdy7358+clB/nydF84s5U1M9L9I+XMwRzGESDRtGiShc b+xgC+RwTvHQammXFD5SR/k1X95w+hMNI7kMDATBJEeX8HhrqsbCOdrPlYJe0k/AsW5O vl5BSs67CQ729dTe9o8F4IVH6vG4Xn6HL8FP/khl34d+NaYCvfFqd+wgYIDf6jaWKkj2 IKZw== MIME-Version: 1.0 X-Received: by 10.112.156.132 with SMTP id we4mr40839318lbb.59.1421795747474; Tue, 20 Jan 2015 15:15:47 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Tue, 20 Jan 2015 15:15:47 -0800 (PST) Date: Tue, 20 Jan 2015 18:15:47 -0500 X-Google-Sender-Auth: pXvNHN1PD-BRYMbS7JF2Jwrjea4 Message-ID: From: Applications Area Directors To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Subject: [apps-discuss] Designated experts needed for LDAP registries X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jan 2015 23:15:50 -0000 Kurt Zeilenga has served for many years as the designated expert for a number of LDAP-related registries. He's asked to be replaced, as he's been out of the LDAP world for quite some time, and no longer has the resources to do this. Thanks very much to Kurt for all the time he's put in until now. I need to find one or two (ideally, two) people who know LDAP well enough to serve as designated experts for the following registries: LDAP Parameters, created by RFC 4520: - Attribute Description Options - Bind Authentication Method - LDAP authzid prefixes - LDAP ModifyRequest Operations - LDAP Search Scopes - Object Identifier Descriptors - resultCode values LDAP-related media types, created by RFC 2425: - text/directory Parameters - text/directory Profiles - text/directory Types These are all very low-activity registries, but it's important that we have someone to review new and updated registrations when they come up. The Applications Directorate list no longer shows anyone with LDAP expertise. Is there anyone out there who can step up and handle this? Please give generously....... Barry & Pete, Applications ADs From nobody Wed Jan 21 13:49:00 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D7D1A006D for ; Wed, 21 Jan 2015 13:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.231 X-Spam-Level: ** X-Spam-Status: No, score=2.231 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHimknmq6yjJ for ; Wed, 21 Jan 2015 13:48:57 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4F70A1A886F for ; Wed, 21 Jan 2015 13:48:41 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PHGCG8HLK000HQ66@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 18 Jan 2015 06:38:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1421591917; bh=HSU9MZoCMecrG05eC1NHYlbOLM710MBtoH6fXzXx/4k=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=Axd37p7gG8gddCy8bmg2IJQimow/uPmiIxUu0VqWiLPnLTCx8j3uDkC6G17+dhWyF 9+UwpSfwYUiMvCbyDQfcLUFdhkis2Wen6LN9IdFjYG1Be9tqNveOCazDMSw4kXPIHd ZE+87RzNoMF1D2KbyO+Fl1WJ/48OS/QKgbSCkcew= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PH4G1QXR7400FTL0@mauve.mrochek.com>; Sun, 18 Jan 2015 06:38:23 -0800 (PST) Message-id: <01PHGCG474BQ00FTL0@mauve.mrochek.com> Date: Sat, 17 Jan 2015 20:26:51 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 15 Jan 2015 00:53:03 +0100 (CET)" References: <20150111215428.13470.qmail@ary.lan> <632a2444-bb0f-4ce9-ad40-4f378f856a57@gulbrandsen.priv.no> <20150113021011.18290.qmail@ary.lan> <46d08f77a738c09bc65d3ba47d4eabecdad3bee307f423e09990ed368d6efaad.sha-256@android.antelope.email> <20150113155123.21938.qmail@ary.lan> <1e2448a8-95ef-4ad5-baa0-d439c5013b06@gulbrandsen.priv.no> <679506e9-c52b-46d5-8e39-d4c943e89621@gulbrandsen.priv.no> <01PHAY6286CU00FTL0@mauve.mrochek.com> <01PHB8AHXGVS00FTL0@mauve.mrochek.com> To: Claudio Allocchio Archived-At: Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] what's a real bounce, was generating DSNs (RFC3464) signed with S/MIME? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jan 2015 21:48:58 -0000 > :-) > let me continue a bit this brainstorming (also because it helps in > clarifying some scenarios)... > On Wed, 14 Jan 2015, Ned Freed wrote: > > > >> > So all someone who > >> > happens to have an account on the system has to do is intercept the > >> message, > >> > then send out a DSN for that message using their account. That message > >> will > >> > be DKIM signed along with all the rest of the mail that system sends out. > > > >> but he/she cannot know the ENVID value. > > > > Of course they do. In my proposed scenario they intercepted the message and > > it > > was part of the transaction. > a "normal" user of that system can intercept the message during the > transation? No, unless the machine has been compromised (but in such a > case we are in a different scenario). A system administrator can do that, > of course, but again... we are in a different scenario where something > has already gone quite wrong there. If we consider these scenarios, also > third party certifications can go really wrong if machines or > administrators are "compromised". > > But this is really beside the point. The issue at hand is your claim that, to > > use your own words, "the owner of cyrus-c1v2.dir.garr.it cannot resonably > > repudiate that this machine generated the DSN". I just showed that that claim > > isn't reasonable in general, and that in particular DKIM adds almost no > > additional value in this context. > > > > All the owner of cyrus-c1v2.dir.garr.it has to do is point out that the > > message > > could have been intercepted, the ENVID determined, and the DSN forged. > So they admit they have a compromised machine or bogus administrators. They admit nothing of the sort. Messages in transit across the open Internet can be intercepted in various ways having nothing to do with the security of the end site. Or the compromise could have occured on the sending system. (Last mile connections are especially vulnerable, and almost always beyond the ability of sites to effectively secure.) Indeed, we're currently expending a hell of a lot of effort in the IETF to try and improve the overall security of email in transit. Are you actually arguing that this isn't a vulnerability and this work is unnnecessary? And on the receiving system - and this is my main point - all that's needed is a regular user account. Nothing else. I repeat: How many sites can vouch for the integrity of every user with a regular account on their system? > And yes, in such a situation they can deny... but they also declare a very > bad unreliable service level (or a bad reputation, if you like). They need declare nothing of the sort. See above. > > And then deline your request for them to check their logs, because why > > should they waste their time doing that for you? > True, if they are unrealiable or just acting non correctly they can do > that. A site telling you to suck it for such a request has nothing to do with being any of those things. DKIM isn't entirely free of cost, so people who attach DKIM signatures do so for a particular reason, usually part of some scheme for insuring delivery of legitimate mail and/or attempting to detect forgery attempts. I very much doubt there's anyone, anywhere, who attaches DKIM signatures to DSNs with the intention of providing nonrepudiation of delivery. as a service. So if you ask for such information, assuming they understand what you're asking for (very big assumption), and assuming they know how to dig such things out of their logs (another big assumption), and assuming they have such logs (another big assumption), then you kind of need to assume they understand the potential liability they are undertaking if they help you, in which case I doubt they'll cooperate. I know I damned well wouldn't in that position, no matter what kind of site I was operating. Ned From nobody Thu Jan 22 02:37:00 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46151A0AF8 for ; Thu, 22 Jan 2015 02:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAiO4LOOy9fN for ; Thu, 22 Jan 2015 02:36:57 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0796.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::796]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4D991A9175 for ; Thu, 22 Jan 2015 02:36:56 -0800 (PST) Received: from pc6 (81.151.167.59) by AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) with Microsoft SMTP Server (TLS) id 15.1.59.20; Thu, 22 Jan 2015 10:36:33 +0000 Message-ID: <015c01d0362f$1f6f6020$4001a8c0@gateway.2wire.net> From: t.petch To: Larry Masinter References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> Date: Thu, 22 Jan 2015 10:19:31 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB4PR02CA0033.eurprd02.prod.outlook.com (10.242.174.161) To AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:AMSPR07MB050; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:AMSPR07MB050; X-Forefront-PRVS: 0464DBBBC4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(189002)(199003)(64706001)(77156002)(46102003)(23756003)(81686999)(87976001)(66066001)(116806002)(92566002)(110136001)(50986999)(122386002)(33646002)(62966003)(76176999)(42186005)(81816999)(105586002)(230783001)(86362001)(61296003)(14496001)(93886004)(1456003)(50226001)(558084003)(50466002)(1556002)(44736004)(106356001)(47776003)(62236002)(44716002)(97736003)(101416001)(84392001)(229853001)(77096005)(40100003)(68736005)(74416001)(7726001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB050; H:pc6; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB050; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2015 10:36:33.3642 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB050 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] draft-ietf-iri-comparison X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jan 2015 10:36:58 -0000 Larry I notice that this (expired) I-D updates RFC3986 which seems germane to recent discussions on this list. Reading it, I can see why it might update RFC3987 or 3987bis but cannot see where it updates RFC3986. What am I missing? Tom Petch From nobody Thu Jan 22 02:58:30 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BB11AC447 for ; Thu, 22 Jan 2015 02:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1PANmLokwwK for ; Thu, 22 Jan 2015 02:58:26 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id DB7E41AC410 for ; Thu, 22 Jan 2015 02:58:25 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 0F15132E52B; Thu, 22 Jan 2015 19:57:40 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 6681_4f01_c687b32a_1f56_4a98_bdd9_f98877f3ec3e; Thu, 22 Jan 2015 19:57:39 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 28B20BF4C5; Thu, 22 Jan 2015 19:57:39 +0900 (JST) Message-ID: <54C0D7A2.6040208@it.aoyama.ac.jp> Date: Thu, 22 Jan 2015 19:57:38 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "t.petch" , Larry Masinter References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <01 5c01d0362f$1f6f6020$4001a8c0@gateway.2wire.net> In-Reply-To: <015c01d0362f$1f6f6020$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-iri-comparison X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jan 2015 10:58:27 -0000 Hello Tom, On 2015/01/22 19:19, t.petch wrote: > Larry > > I notice that this (expired) I-D updates RFC3986 which seems germane to > recent discussions on this list. Reading it, I can see why it might > update RFC3987 or 3987bis but cannot see where it updates RFC3986. Wha= t > am I missing? First, it says "3986 (if approved)", so this was conditional (of course). Second, there's the following sentence in the introduction, which may be=20 enough of an explanation: As every URI is also an IRI, the comparison and canonicalization methods also apply to URIs. Third, I think that for this topic, 10 different people would write 10=20 different stories, but the conclusion would be the same: *it depends*.=20 Larry hoped that we could write a better story than RFC 3986 (and RFC=20 3987, which is mostly the same story, just with some twists added).=20 Also, on occasion, we had the dream to get rid of the URI vs. IRI=20 distinction. Based on the experience with that document, I'd recommend to mostly=20 leave the equivalence/canonicalization/comparison story alone to save=20 cycles for more immediately relevant work. Of course that doesn't=20 exclude the possibility that somebody write a better story, but that can=20 be done as a paper or a blog entry or an informal RFC independent of=20 standards work. Just my 2=C2=A2. Regards, Martin. From nobody Thu Jan 22 10:11:41 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34DB1A6F3C for ; Wed, 21 Jan 2015 10:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.967 X-Spam-Level: ** X-Spam-Status: No, score=2.967 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etcUAZ2yp8NS for ; Wed, 21 Jan 2015 10:52:37 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A63A21A6F28 for ; Wed, 21 Jan 2015 10:52:36 -0800 (PST) Received: from Philemon (173-164-94-161-Oregon.hfc.comcastbusiness.net [173.164.94.161]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 0B28E38F31; Wed, 21 Jan 2015 10:52:34 -0800 (PST) From: "Jim Schaad" To: "'Bert Greevenbosch'" References: <042b01d031fe$0c7edfc0$257c9f40$@augustcellars.com> <54BDFBF3.9010101@bertgreevenbosch.nl> In-Reply-To: <54BDFBF3.9010101@bertgreevenbosch.nl> Date: Wed, 21 Jan 2015 10:51:48 -0800 Message-ID: <031201d035ab$5077e9a0$f167bce0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0313_01D03568.425A00D0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQIkoVtF/wxHHQfQmcTr3uIMbS3ufgHaP14+AafTl2KcBQwjIA== Archived-At: X-Mailman-Approved-At: Thu, 22 Jan 2015 10:11:37 -0800 Cc: apps-discuss@ietf.org, draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org Subject: Re: [apps-discuss] ??: New round of comments on draft-greevenbosch-appsawg-cbor-cddl-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jan 2015 18:52:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0313_01D03568.425A00D0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Bert Greevenbosch [mailto:ietf@bertgreevenbosch.nl]=20 Sent: Monday, January 19, 2015 10:56 PM To: Jim Schaad Cc: draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org Subject: Re: ??: New round of comments on = draft-greevenbosch-appsawg-cbor-cddl-04 =20 Hi Jim, Thank you for your comments. They are very helpful. Please find my = answers below. B.T.W.,would you mind including the apps-discuss mailing list in this = discussion? It may be good for the chairs and others to see activity on = this draft. 1. You have a length restriction on float, do you see a need for begin = able to do length restrictions on int, tstr and bstr? I don't know if a = restriction based on number of bytes or based on a value range would be = better. It make sense to use the () syntax to specify a length = restriction since you are already using it for float.=20 I started out with such notation, e.g. "int(16)" for a 16-bit integer. = However, there is a difference between ints and floats: for any integer = number, it is easy to find out how much bits are needed. Hence we could = allow some freedom in choosing the number of bits on a per-number basis = on the encoder side. This was a comment from Carsten, and we = subsequently removed the "int(16)" notation. For floats, this is harder, as the number of bits does not depend on the = value of the variable, but on the precision with which we want to = represent that variable. For example, the value 1/3 can be represented = using both a float(16) and a float(32), but the latter representation = would be closer to the real value than the former. [JLS] What I was looking for was a size limitation which might be = helpful. That is the integer that goes here is limited to 16 bits. 3. I will reiterate the request for some type of alternate syntax for = types - i.e. TypeA or TypeB I like your earlier proposed notation: price: uint | float(16) and think we can implement this in the next version of the draft. 2. You have removed the union/choice structure from the document. I = highly recommend that this be added back in some form.=20 I think we can use the same solution for (3) as well, as follows: *smallStructure1 { dish: tstr; recipe: tstr; } *smallStructure2 { drink: tstr; price: int; } *BigStructure : { subStructure: smallStructure1 | smallStructure2;=20 } Interesting would be how to distinguish between smallStructure1 and = smallStructure2. Especially in the following case: *smallStructure1 { dish: tstr; recipe: tstr; } *smallStructure2 { drink: tstr; ingredients: tstr; } *BigStructure : { subStructure: smallStructure1 | smallStructure2;=20 } The last may need some more consideration. [JLS] while one could use tags =E2=80=93 is there a reason not to go = back to the world of using an int field to discriminate? 4. A structure can be folded at the top level into a structure by not = using the '*' operator on a type. Do you want to be able to do the same = type of thing for a map? Not sure about this. Do you have an example? CDDL maps need a CBOR map encoding. A structure, however, does not = necessarily require what I call an "encompassing array". Thus the = encompassing array is signalled by the asterisk, because there is a = choice. [JLS] If one looks at the COSE document that I am working on. One can = define three maps, one each for an EC key, for an RSA key and for a = secret key. One can then define a base key with common fields that are = not algorithm specific. One could then define single map that included = each of the other items into it by reference rather than as sub items. =20 COSE_KEY : map { base_key; rsa_key; ec_key; secret_key } 5. I don't understand the last example in section 4.5.1 - You are = combining a structure and a map together into a single item. Would the = syntax "ToString: map(., tstr)" be a better example? This is a map in = this case and that is what you are talking about=20 Yes, indeed this would be better: toString: map( ., tstr ); (Notice the lower case "t" at the beginning, this is a convention I use = for variable names, although it is not mandatory.) Best regards, Bert On 19-01-15 01:59, Sunruinan wrote: Hi Bert=EF=BC=8C I received such email from Jim. Since I can't find it = in appsawg email list, I think this is a system automatic email, is it = right? Can I find some web pages about these comments? As the title of = this email, it means New round of comments. Are these comments has some = relationship with the previous round comments? Thank you in advance for = your reply! Best Regards! Ruinan = -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- = =E5=8F=91=E4=BB=B6=E4=BA=BA: Jim Schaad [mailto:ietf@augustcellars.com] = =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B41=E6=9C=8817=E6=97=A5 = 10:34 =E6=94=B6=E4=BB=B6=E4=BA=BA: = draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org =E4=B8=BB=E9=A2=98: = New round of comments on draft-greevenbosch-appsawg-cbor-cddl-04 Here = comes a new round of comments on the draft. I have tried not hit the = same points again. 1. You have a length restriction on float, do you see = a need for begin able to do length restrictions on int, tstr and bstr? I = don't know if a restriction based on number of bytes or based on a value = range would be better. It make sense to use the () syntax to specify a = length restriction since you are already using it for float. 2. You have = removed the union/choice structure from the document. I highly recommend = that this be added back in some form. 3. I will reiterate the request = for some type of alternate syntax for types - i.e. TypeA or TypeB 4. A = structure can be folded at the top level into a structure by not using = the '*' operator on a type. Do you want to be able to do the same type = of thing for a map? 5. I don't understand the last example in section = 4.5.1 - You are combining a structure and a map together into a single = item. Would the syntax "ToString: map(., tstr)" be a better example? = This is a map in this case and that is what you are talking about Jim .=20 -- Bert Greevenbosch ietf@bertgreevenbosch.nl=20 Best regards, Bert On 20-01-15 07:09, Sunruinan wrote: Hi Jim, Thank you for your comments! Since Bert is original editor of this draft and more familiar with = previous discussion, I forward your comments to his new email address. He can give some answers. =20 Best Regards! Ruinan Sun Huawei =20 -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Jim Schaad [mailto:ietf@augustcellars.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B41=E6=9C=8817=E6=97=A5 = 10:34 =E6=94=B6=E4=BB=B6=E4=BA=BA: = draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org =E4=B8=BB=E9=A2=98: New round of comments on = draft-greevenbosch-appsawg-cbor-cddl-04 =20 Here comes a new round of comments on the draft. I have tried not hit = the same points again. =20 1. You have a length restriction on float, do you see a need for begin = able to do length restrictions on int, tstr and bstr? I don't know if a = restriction based on number of bytes or based on a value range would be = better. It make sense to use the () syntax to specify a length = restriction since you are already using it for float. =20 2. You have removed the union/choice structure from the document. I = highly recommend that this be added back in some form. =20 3. I will reiterate the request for some type of alternate syntax for = types - i.e. TypeA or TypeB =20 4. A structure can be folded at the top level into a structure by not = using the '*' operator on a type. Do you want to be able to do the same type = of thing for a map?=20 =20 5. I don't understand the last example in section 4.5.1 - You are = combining a structure and a map together into a single item. Would the = syntax "ToString: map(., tstr)" be a better example? This is a map in this = case and that is what you are talking about =20 =20 Jim . =20 =20 ------=_NextPart_000_0313_01D03568.425A00D0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Bert Greevenbosch [mailto:ietf@bertgreevenbosch.nl] =
Sent: Monday, January 19, 2015 10:56 PM
To: Jim = Schaad
Cc: = draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org
Subject: = Re: ??: New round of comments on = draft-greevenbosch-appsawg-cbor-cddl-04

=

 

Hi Jim,

Thank you for your = comments. They are very helpful. Please find my answers = below.

B.T.W.,would you mind including the apps-discuss mailing = list in this discussion? It may be good for the chairs and others to see = activity on this draft.

1. = You have a length restriction on float, do you see a need for begin able = to do length restrictions on int, tstr and bstr? I don't know if a = restriction based on number of bytes or based on a value range would be = better. It make sense to use the () syntax to specify a length = restriction since you are already using it for float.

I = started out with such notation, e.g. "int(16)" for a 16-bit = integer. However, there is a difference between ints and floats: for any = integer number, it is easy to find out how much bits are needed. Hence = we could allow some freedom in choosing the number of bits on a = per-number basis on the encoder side. This was a comment from Carsten, = and we subsequently removed the "int(16)" notation.

For = floats, this is harder, as the number of bits does not depend on the = value of the variable, but on the precision with which we want to = represent that variable. For example, the value 1/3 can be represented = using both a float(16) and a float(32), but the latter representation = would be closer to the real value than the former.

[JLS] What I was looking for was a size = limitation which might be helpful.=C2=A0 That is the integer that goes = here is limited to 16 bits.

3. I will reiterate the = request for some type of alternate syntax for types - i.e. TypeA or = TypeB

I like your earlier proposed notation:

price: uint | float(16)

and think we can implement this in the next version of = the draft.

2. You have removed the union/choice structure from = the document. I highly recommend that this be added back in some form. =

I think we can use the same solution for (3) as well, as = follows:

*smallStructure1 = {
   dish: tstr;
   recipe: = tstr;
}

*smallStructure2 {
   drink: = tstr;
   price: int;
}

*BigStructure : = {
   subStructure: smallStructure1 | smallStructure2; =
}

Interesting would be how to = distinguish between smallStructure1 and smallStructure2. Especially in = the following case:

*smallStructure1 = {
   dish: tstr;
   recipe: = tstr;
}

*smallStructure2 {
   drink: = tstr;
   ingredients: tstr;
}

*BigStructure : = {
   subStructure: smallStructure1 | smallStructure2; =
}

The last may need some more = consideration.

[JLS] while one could use tags =E2=80=93 is there a reason not to go = back to the world of using an int field to = discriminate?



4. A = structure can be folded at the top level into a structure by not using = the '*' operator on a type. Do you want to be able to do the same type = of thing for a map?

Not sure about this. Do you have an = example?

CDDL maps need a CBOR map encoding. A structure, = however, does not necessarily require what I call an "encompassing = array". Thus the encompassing array is signalled by the asterisk, = because there is a choice.

[JLS]=C2=A0 If one looks at the COSE document that I am working on. = =C2=A0One can define three maps, one each for an EC key, for an RSA key = and for a secret key.=C2=A0 One can then define a base key with common = fields that are not algorithm specific. =C2=A0One could then = define=C2=A0 single map that included each of the other items into it by = reference rather than as sub items.

 

COSE_KEY : map { base_key; rsa_key; ec_key; secret_key = }



5. I don't = understand the last example in section 4.5.1 - You are combining a = structure and a map together into a single item. Would the syntax = "ToString: map(., tstr)" be a better example? This is a map in = this case and that is what you are talking about

Yes, indeed = this would be better:

toString: map( = ., tstr );

(Notice the lower case "t" at = the beginning, this is a convention I use for variable names, although = it is not mandatory.)

Best = regards,
Bert

On = 19-01-15 01:59, Sunruinan wrote:

Hi = Bert=EF=BC=8C I received = such email from Jim. Since I can't find it in appsawg email list, I = think this is a system automatic email, is it right? Can I find some web = pages about these comments? As the title of this email, it means New = round of comments. Are these comments has some relationship with the = previous round comments? Thank you in advance for your reply! Best = Regards! Ruinan -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB= =B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Jim Schaad [mailto:ietf@augustcellars.com]= =E5=8F=91=E9=80=81=E6=97=B6=E9=97= =B4: 2015=E5=B9=B41=E6=9C=8817=E6=97=A5 10:34 =E6=94=B6=E4=BB=B6=E4=BA=BA: draft= -greevenbosch-appsawg-cbor-cddl@tools.ietf.org =E4=B8=BB=E9=A2=98: New round of = comments on draft-greevenbosch-appsawg-cbor-cddl-04 Here comes a new = round of comments on the draft. I have tried not hit the same points = again. 1. You have a length restriction on float, do you see a need for = begin able to do length restrictions on int, tstr and bstr? I don't know = if a restriction based on number of bytes or based on a value range = would be better. It make sense to use the () syntax to specify a length = restriction since you are already using it for float. 2. You have = removed the union/choice structure from the document. I highly recommend = that this be added back in some form. 3. I will reiterate the request = for some type of alternate syntax for types - i.e. TypeA or TypeB 4. A = structure can be folded at the top level into a structure by not using = the '*' operator on a type. Do you want to be able to do the same type = of thing for a map? 5. I don't understand the last example in section = 4.5.1 - You are combining a structure and a map together into a single = item. Would the syntax "ToString: map(., tstr)" be a better = example? This is a map in this case and that is what you are talking = about Jim .


-- Bert = Greevenbosch ietf@bertgreevenbosch.nl =



Best = regards,
Bert

On = 20-01-15 07:09, Sunruinan wrote:

Hi =
Jim,
Thank you for your =
comments!
Since Bert is original editor of this =
draft and more familiar with previous discussion, I forward your =
comments to his new email address.
He can give some =
answers.
 
Best =
Regards!
Ruinan =
Sun
Huawei
 
-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6=
-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: Jim =
Schaad [mailto:ietf@augustcellars.com]=
 
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=
: 2015=E5=B9=B41=E6=9C=8817=E6=97=A5 =
10:34
=E6=94=B6=E4=BB=B6=E4=BA=BA: draft=
-greevenbosch-appsawg-cbor-cddl@tools.ietf.org
<=
span style=3D'font-family:"MS Gothic"'>=E4=B8=BB=E9=A2=98: New round of comments on =
draft-greevenbosch-appsawg-cbor-cddl-04
 <=
/o:p>
Here comes a new round of comments on the draft.=C2=A0 I =
have tried not hit the same points =
again.
 
1. You have a =
length restriction on float, do you see a need for begin able to do =
length restrictions on int, tstr and bstr?=C2=A0 I don't know if a =
restriction based on number of bytes or based on a value range would be =
better.=C2=A0 It make sense to use the () syntax to specify a length =
restriction since you are already using it for =
float.
 
2. You have =
removed the union/choice structure from the document.=C2=A0 I highly =
recommend that this be added back in some =
form.
 
3. I will =
reiterate the request for some type of alternate syntax for =
types
- i.e. TypeA or =
TypeB
 
4. A structure =
can be folded at the top level into a structure by not =
using
the '*' operator on a type.=C2=A0=C2=A0 Do =
you want to be able to do the same type of
thing =
for a map? 
 
5. I don't =
understand the last example in section 4.5.1 - You are combining a =
structure and a map together into a single item.=C2=A0 Would the =
syntax
"ToString: map(., tstr)" be a =
better example?=C2=A0 This is a map in this case and that is what you =
are talking =
about
 
 <=
/pre>
Jim
.
 

 

------=_NextPart_000_0313_01D03568.425A00D0-- From nobody Thu Jan 22 21:23:48 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D801A1A5B for ; Thu, 22 Jan 2015 21:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvFZW2ZZZpZm for ; Thu, 22 Jan 2015 21:23:38 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0615.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:615]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 005131A0275 for ; Thu, 22 Jan 2015 21:23:37 -0800 (PST) Received: from BN3PR0201MB0945.namprd02.prod.outlook.com (25.160.155.25) by BN3PR0201MB0948.namprd02.prod.outlook.com (25.160.155.28) with Microsoft SMTP Server (TLS) id 15.1.59.20; Fri, 23 Jan 2015 05:23:15 +0000 Received: from BN3PR0201MB0945.namprd02.prod.outlook.com ([25.160.155.25]) by BN3PR0201MB0945.namprd02.prod.outlook.com ([25.160.155.25]) with mapi id 15.01.0059.007; Fri, 23 Jan 2015 05:23:15 +0000 From: Larry Masinter To: t.petch Thread-Topic: draft-ietf-iri-comparison Thread-Index: AQHQNi9NMknCnoECn062w/S4lSg7MpzNBGKg Date: Fri, 23 Jan 2015 05:23:14 +0000 Message-ID: References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <015c01d0362f$1f6f6020$4001a8c0@gateway.2wire.net> In-Reply-To: <015c01d0362f$1f6f6020$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:9:8380:992:c17a:a9a3:47a2:acd0] authentication-results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=adobe.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BN3PR0201MB0948; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0201MB0948; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(93886004)(50986999)(76176999)(54606007)(54356999)(2900100001)(54206007)(15975445007)(102836002)(2656002)(33656002)(62966003)(77156002)(230783001)(74316001)(87936001)(76576001)(110136001)(46102003)(2950100001)(92566002)(106116001)(19580395003)(86362001)(99286002)(122556002)(40100003)(7059030)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0201MB0948; H:BN3PR0201MB0945.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2015 05:23:14.6287 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB0948 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-iri-comparison X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jan 2015 05:23:43 -0000 VG9tIFBldGNoIHdyb3RlLCByZSBkcmFmdC1pZXRmLWlyaS1jb21wYXJpc29uDQoNCj4gSSBub3Rp Y2UgdGhhdCB0aGlzIChleHBpcmVkKSBJLUQgdXBkYXRlcyBSRkMzOTg2IHdoaWNoIHNlZW1zIGdl cm1hbmUgdG8NCj4gcmVjZW50IGRpc2N1c3Npb25zIG9uIHRoaXMgbGlzdC4gIFJlYWRpbmcgaXQs IEkgY2FuIHNlZSB3aHkgaXQgbWlnaHQNCj4gdXBkYXRlIFJGQzM5ODcgb3IgMzk4N2JpcyBidXQg Y2Fubm90IHNlZSB3aGVyZSBpdCB1cGRhdGVzIFJGQzM5ODYuDQo+IFdoYXQgYW0gSSBtaXNzaW5n Pw0KDQpJJ20gYWZyYWlkDQoNCiIgQXMgVVJJcyBhcmUgYSBzdWJzZXQgb2YgSVJJcywgdGhlIGd1 aWRlbGluZXMgYXBwbHkgdG8gVVJJIGNvbXBhcmlzb24gYXMgd2VsbC4iDQoNCnNob3VsZCBoYXZl IHNhaWQgdGhlIGlkICgiQ29tcGFyaXNvbiwgRXF1aXZhbGVuY2UgYW5kIENhbm9uaWNhbGl6YXRp b24NCiBvZiBJbnRlcm5hdGlvbmFsaXplZCBSZXNvdXJjZSBJZGVudGlmaWVycyIpDQp3YXMgaW50 ZW5kZWQgdG8gcmVwbGFjZSBSRkMgMzk4NiBzZWN0aW9uIDYgIk5vcm1hbGl6YXRpb24gYW5kIENv bXBhcmlzb24iDQppbiBpdHMgZW50aXJldHkuDQoNCkF0IHRoaXMgcG9pbnQgSSdkIHN1Z2dlc3Qg Y29tbWVudHMgb24gb3BlbiBpbiBVUkwgaXNzdWVzDQpodHRwczovL2dpdGh1Yi5jb20vd2Vic3Bl Y3MvdXJsL2lzc3Vlcy8xOA0KaHR0cHM6Ly93d3cudzMub3JnL0J1Z3MvUHVibGljL3Nob3dfYnVn LmNnaT9pZD0yNzY0MA0KDQpTaG91bGQgZXF1aXZhbGVuY2Ugb2YgVVJMcyBzaG91bGQgbWFuZGF0 ZSB0aGF0IGlmIHlvdSBwYXJzZSBVUkwgIEEgYW5kDQpnZXQgYmFjayBVUkkgQiwgdGhlbiBBIG11 c3QgYmUgZXF1aXZhbGVudCB0byBCPw0KVGhlbiwgaWYgeW91IGhhdmUgYSBkaWZmZXJlbnQgVVJM IEMgdGhhdCB0dXJucyBpbnRvIEIsIEMgbXVzdCBhbHNvIGJlIGVxdWl2YWxlbnQNCnRvIEEgYW5k IEIuIEV2ZW4gZm9yIFVSTHMgdGhhdCBhcmUgdmFsaWQgVVJJcy4gDQpUaGlzIHJlcXVpcmVtZW50 IGluIDM5ODYgaXMganVzdCBhIE1BWS4NCg0KTGFycnkNCi0tDQpodHRwOi8vbGFycnkubWFzaW50 ZXIubmV0DQoNCg0KDQo= From nobody Thu Jan 22 22:59:11 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31921A016C for ; Thu, 22 Jan 2015 22:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Lfb-2UYqYDs for ; Thu, 22 Jan 2015 22:59:08 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0621.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::621]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D1521A024C for ; Thu, 22 Jan 2015 22:59:08 -0800 (PST) Received: from BN3PR0201MB0945.namprd02.prod.outlook.com (25.160.155.25) by BN3PR0201MB0948.namprd02.prod.outlook.com (25.160.155.28) with Microsoft SMTP Server (TLS) id 15.1.59.20; Fri, 23 Jan 2015 06:58:44 +0000 Received: from BN3PR0201MB0945.namprd02.prod.outlook.com ([25.160.155.25]) by BN3PR0201MB0945.namprd02.prod.outlook.com ([25.160.155.25]) with mapi id 15.01.0059.007; Fri, 23 Jan 2015 06:58:44 +0000 From: Larry Masinter To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , t.petch Thread-Topic: [apps-discuss] draft-ietf-iri-comparison Thread-Index: AQHQNi9NMknCnoECn062w/S4lSg7MpzL+BkAgAFMkyA= Date: Fri, 23 Jan 2015 06:58:44 +0000 Message-ID: References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <01 5c01d0362f$1f6f6020$4001a8c0@gateway.2wire.net> <54C0D7A2.6040208@it.aoyama.ac.jp> In-Reply-To: <54C0D7A2.6040208@it.aoyama.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:9:8380:992:c17a:a9a3:47a2:acd0] authentication-results: it.aoyama.ac.jp; dkim=none (message not signed) header.d=none;it.aoyama.ac.jp; dmarc=none action=none header.from=adobe.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BN3PR0201MB0948; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0201MB0948; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(106116001)(92566002)(40100003)(122556002)(99286002)(86362001)(19580395003)(33656002)(230783001)(77156002)(62966003)(54356999)(93886004)(50986999)(76176999)(54606007)(54206007)(2900100001)(2656002)(102836002)(15975445007)(46102003)(2950100001)(87936001)(74316001)(76576001)(7059030)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0201MB0948; H:BN3PR0201MB0945.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2015 06:58:44.6290 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB0948 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-iri-comparison X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jan 2015 06:59:09 -0000 PiBCYXNlZCBvbiB0aGUgZXhwZXJpZW5jZSB3aXRoIHRoYXQgZG9jdW1lbnQsIEknZCByZWNvbW1l bmQgdG8gbW9zdGx5DQo+IGxlYXZlIHRoZSBlcXVpdmFsZW5jZS9jYW5vbmljYWxpemF0aW9uL2Nv bXBhcmlzb24gc3RvcnkgYWxvbmUgdG8gc2F2ZQ0KPiBjeWNsZXMgZm9yIG1vcmUgaW1tZWRpYXRl bHkgcmVsZXZhbnQgd29yay4NCg0KSSB0aGluayBzZXBhcmF0aW5nIGl0IG91dCBpbnRvIGEgc2Vw YXJhdGUgZG9jdW1lbnQgdGhhdCBjYW4gcHJvY2VlZCBhdCBpdHMgb3duIHBhY2UgaXMgYSBnb29k IGlkZWEsIGJ1dCB0aGVyZSBhcmUgaW1wb3J0YW50IHNwZWNpZmljIHVzZSBjYXNlcyB0byBzdGFu ZGFyZGl6ZS4NCg0KPiBPZiBjb3Vyc2UgdGhhdCBkb2Vzbid0DQo+IGV4Y2x1ZGUgdGhlIHBvc3Np YmlsaXR5IHRoYXQgc29tZWJvZHkgd3JpdGUgYSBiZXR0ZXIgc3RvcnksIGJ1dCB0aGF0IGNhbg0K PiBiZSBkb25lIGFzIGEgcGFwZXIgb3IgYSBibG9nIGVudHJ5IG9yIGFuIGluZm9ybWFsIFJGQyBp bmRlcGVuZGVudCBvZg0KPiBzdGFuZGFyZHMgd29yay4NCg0KSSB0aGluayB0aGVyZSBhcmUgcmVx dWlyZW1lbnRzIG9uIGNvbXBhcmlzb24vZXF1aXZhbGVuY2UvY2Fub25pY2FsaXphdGlvbiB0aGF0 IG5lZWQgdG8gYmUgbm9ybWF0aXZlLCBhbmQgd2hhdCB3ZSBoYXZlLCBub3csIGlzIG5vcm1hdGl2 ZSBidXQgbWlzbGVhZGluZyBvciBpbmNvcnJlY3QuIEEgVVJMIG5lZWRzIHRvIGJlIGVxdWl2YWxl bnQgdG8gdGhlIFVSSSBpdCBwYXJzZXMgaW50by4NCg0KTGFycnkNCi0tDQpodHRwOi8vbGFycnku bWFzaW50ZXIubmV0DQoNCg== From nobody Fri Jan 23 05:31:46 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6311A90B6 for ; Fri, 23 Jan 2015 05:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.854 X-Spam-Level: X-Spam-Status: No, score=0.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_yf4-iHZH3W for ; Fri, 23 Jan 2015 05:31:41 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0769.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::769]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C661A90B8 for ; Fri, 23 Jan 2015 05:31:41 -0800 (PST) Received: from pc6 (81.151.167.59) by DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) with Microsoft SMTP Server (TLS) id 15.1.59.20; Fri, 23 Jan 2015 13:23:08 +0000 Message-ID: <01cc01d0370f$8ea72460$4001a8c0@gateway.2wire.net> From: t.petch To: Larry Masinter , =?UTF-8?Q?Martin_J._D=C3=BCrst?= References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <01 5c01d0362f$1f6f6020$4001a8c0@gateway.2wire.net> <54C0D7A2.6040208@it.aoyama.ac.jp> Date: Fri, 23 Jan 2015 13:21:47 +0000 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: [81.151.167.59] X-ClientProxiedBy: DB4PR05CA0014.eurprd05.prod.outlook.com (25.160.40.24) To DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DBXPR07MB064; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DBXPR07MB064; X-Forefront-PRVS: 0465429B7F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(13464003)(377454003)(19580395003)(81816999)(76176999)(50986999)(230783001)(81686999)(86362001)(42186005)(92566002)(46102003)(93886004)(587094005)(84392001)(19580405001)(62966003)(77156002)(23676002)(61296003)(1556002)(87976001)(50226001)(40100003)(44736004)(50466002)(14496001)(33646002)(116806002)(122386002)(44716002)(16601075003)(47776003)(62236002)(77096005)(1456003)(15975445007)(66066001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB064; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB064; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2015 13:23:08.5650 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB064 Archived-At: Cc: apps-discuss Subject: Re: [apps-discuss] draft-ietf-iri-comparison X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jan 2015 13:31:44 -0000 ---- Original Message ----- From: "Larry Masinter" To: "Martin J. Dürst" ; "t.petch" Cc: Sent: Friday, January 23, 2015 6:58 AM > > Based on the experience with that document, I'd recommend to mostly > > leave the equivalence/canonicalization/comparison story alone to save > > cycles for more immediately relevant work. > > I think separating it out into a separate document that can proceed at its own pace is a good idea, but there are important specific use cases to standardize. > > > Of course that doesn't > > exclude the possibility that somebody write a better story, but that can > > be done as a paper or a blog entry or an informal RFC independent of > > standards work. > > I think there are requirements on comparison/equivalence/canonicalization that need to be normative, and what we have, now, is normative but misleading or incorrect. A URL needs to be equivalent to the URI it parses into. Larry, Martin Thank you for the clarification. I see now how the I-D would have updated RFC3986 had it advanced to completion. I was not intending to pursue the subject of comparison further at this time, rather the I-D is part of a Bibliography I hark back to when issues of IRIs come up (as recently they did). Expired Draft it may be, but I still find it a useful source of ideas. Tom Petch > > Larry > -- > http://larry.masinter.net > > From nobody Mon Jan 26 02:30:46 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FC91A8897 for ; Mon, 26 Jan 2015 02:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.261 X-Spam-Level: **** X-Spam-Status: No, score=4.261 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdLeP5y4FOi4 for ; Mon, 26 Jan 2015 02:30:42 -0800 (PST) Received: from filter3.mijndomein.nl (filter3.mijndomein.nl [IPv6:2a00:4e40:1:1::9:3]) (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 5979A1A88A3 for ; Mon, 26 Jan 2015 02:30:40 -0800 (PST) Received: from smtp3.mijndomein.nl ([188.93.148.187]) by filter3.mijndomein.nl with esmtps (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YFgw0-0002A5-S5; Mon, 26 Jan 2015 10:30:38 +0000 Received: from a83-163-56-175.adsl.xs4all.nl ([83.163.56.175] helo=[192.168.178.34]) by smtp3.mijndomein.nl with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YFgvw-000GvG-91; Mon, 26 Jan 2015 11:30:16 +0100 X-BL: passed SBL and XBL Message-ID: <54C61737.50203@bertgreevenbosch.nl> Date: Mon, 26 Jan 2015 11:30:15 +0100 From: Bert Greevenbosch User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Jim Schaad References: <042b01d031fe$0c7edfc0$257c9f40$@augustcellars.com> <54BDFBF3.9010101@bertgreevenbosch.nl> <031201d035ab$5077e9a0$f167bce0$@augustcellars.com> In-Reply-To: <031201d035ab$5077e9a0$f167bce0$@augustcellars.com> Content-Type: multipart/alternative; boundary="------------070600020209030307090506" X-Filter-ID: s0sct1PQhAABKnZB5plbIbeyMPxSrGSJ4SQMxQlCFaEuE/LxIE34C/qwVUIcAs0scX1DsKxrfqSx 4PYxEQ1EGuxuDFJFNtN290+JywvAVMeP5iLc32Iw5qlEMDg85ZT+sqNYUlS/Pz/NUzwJMQ2WsP/Q 5JdvnZgHe6QklmSGfOrX3/7h7YP0zNYn4pUCVtIessGtn5x4MNFdXOCKXiWGTb/RQYB537hdIOmp XP+hH3exnz9PxZsWpghWTVPsq9/lCGWZKAKmtzBlNDXU39YLhGHr3G4hRYbecfvVuPjOGWJxdN/Y iezjBJI0QzE5uL/HXIDYmIO5MaByvz1GY8RZnArdi95bIaYBWldOmLuXQrVGJWOteWaoXFvbbwb3 Cge7mLIENHbaOnKR9I36sQzEGO0xO/0DPDy8+H6Y7XlgtCXDqcigOvSxdRnthmhn8Zn6FvuBiGoU 4Agjav+dcUaPtyTVr0ifmZFLoMCp3QjQ26nPaxFm6QYN0g9/559IwGJXQqHFAxHHyzEglvCW8rgZ 27sEGLV/Wn8v8RE7aRPUKGW5w+pZ2xHl9URp7H2O1P9LEcomSxZ0NLtVmCgIkNSeulrha91ByuhW XHYk4eYA7XAbk26wNS0s1ox7tcHLX7jvg8CBO1Snvm6qXHQp7O9kde6UF/g9IJ5OLPBBDBaN9U4G zksPRhc8k44v9RkKreKb6J1fhOzjF0b4LXcjJZ5lotmXu8UK157zeeBKyRPnLOZGwgCkvTeKqvnp sboaU8uY927hvFGbkmfOtciXT8ciWcAf9nRxmHUjga4/b+cmkFw= X-Report-Abuse-To: spam@filter1.mijndomein.nl X-Filter-Fingerprint: IFrWXGses7OKB5S5G8/dJR8Z5VD7FZiiT9tK6RAzQuhA3cTUQ1R++keuE7RDJ8Kg3RbMLUalw1oC mj99/u+PoqoVy8a3lsStJtAvpObFX0W9pwnCLfzqMQ4SqlQant4mUpndEJ0YoaLytXXo8BMTaX2p Mk7LBarWD9Fj4R3eIu5cOy/3Wm9qfF/CZNvP/2Kowv61T+KDYyYtREgszdyFwv8IxCB3p/oCKvxr eyISh3JGb7OS5oVgiO+kDxZrVPLz3MmEGC2PrUKqLq5WmHK+Nw== X-Originating-IP: 188.93.148.187 X-Mijndomein.nl-Domain: mijndomein.nl X-Mijndomein.nl-Username: 188.93.148.187 Authentication-Results: mijndomein.nl; auth=pass smtp.auth=188.93.148.187 X-Mijndomein.nl-Outgoing-Class: ham X-Mijndomein.nl-Outgoing-Evidence: Combined (0.02) X-Recommended-Action: accept Archived-At: Cc: apps-discuss@ietf.org, draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org Subject: Re: [apps-discuss] ??: New round of comments on draft-greevenbosch-appsawg-cbor-cddl-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jan 2015 10:30:46 -0000 This is a multi-part message in MIME format. --------------070600020209030307090506 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Jim, Thank you for your feedback. Please find my response inline, preceded with "[BG]". Best regards, Bert On 21-01-15 19:51, Jim Schaad wrote: > > *From:*Bert Greevenbosch [mailto:ietf@bertgreevenbosch.nl] > *Sent:* Monday, January 19, 2015 10:56 PM > *To:* Jim Schaad > *Cc:* draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org > *Subject:* Re: ??: New round of comments on > draft-greevenbosch-appsawg-cbor-cddl-04 > > Hi Jim, > > Thank you for your comments. They are very helpful. Please find my > answers below. > > B.T.W.,would you mind including the apps-discuss mailing list in this > discussion? It may be good for the chairs and others to see activity > on this draft. > > /1. You have a length restriction on float, do you see a need for > begin able to do length restrictions on int, tstr and bstr? I don't > know if a restriction based on number of bytes or based on a value > range would be better. It make sense to use the () syntax to specify a > length restriction since you are already using it for float. / > > I started out with such notation, e.g. "int(16)" for a 16-bit integer. > However, there is a difference between ints and floats: for any > integer number, it is easy to find out how much bits are needed. Hence > we could allow some freedom in choosing the number of bits on a > per-number basis on the encoder side. This was a comment from Carsten, > and we subsequently removed the "int(16)" notation. > > For floats, this is harder, as the number of bits does not depend on > the value of the variable, but on the precision with which we want to > represent that variable. For example, the value 1/3 can be represented > using both a float(16) and a float(32), but the latter representation > would be closer to the real value than the former. > > [JLS] What I was looking for was a size limitation which might be > helpful. That is the integer that goes here is limited to 16 bits. > [BG] Ah yes, that may be helpful. It would mean a slightly different meaning of "(16)" in "float(16)" and "uint(16)", but I could easily get used to that. > > > /3. I will reiterate the request for some type of alternate syntax for > types - i.e. TypeA or TypeB > / > I like your earlier proposed notation: > > price: uint | float(16) > > and think we can implement this in the next version of the draft. > > /2. You have removed the union/choice structure from the document. I > highly recommend that this be added back in some form. / > > I think we can use the same solution for (3) as well, as follows: > > *smallStructure1 { > dish: tstr; > recipe: tstr; > } > > *smallStructure2 { > drink: tstr; > price: int; > } > > *BigStructure : { > subStructure: smallStructure1 | smallStructure2; > } > > Interesting would be how to distinguish between smallStructure1 and > smallStructure2. Especially in the following case: > > *smallStructure1 { > dish: tstr; > recipe: tstr; > } > > *smallStructure2 { > drink: tstr; > ingredients: tstr; > } > > *BigStructure : { > subStructure: smallStructure1 | smallStructure2; > } > > The last may need some more consideration. > > [JLS] while one could use tags – is there a reason not to go back to > the world of using an int field to discriminate? > [BG] Any way of signalling to the application which of the two structures is meant is indeed required. This could be through an integer that contains a field-id, or in other ways e.g. through the semantics of the rest of the data structure. What I mean is, that it may be obvious to the application which structure is meant by inspecting earlier fields. For automatic parsing of such structure, this would be much harder though. A complex parser could perform "best effort parsing", whereas a simpler parser could consider ignoring verification of variables with alternative structures as datatype. (Simple datatypes should be easy to handle for simple parsers too.) > > /4. A structure can be folded at the top level into a structure by not > using the '*' operator on a type. Do you want to be able to do the > same type of thing for a map? > / > Not sure about this. Do you have an example? > > CDDL maps need a CBOR map encoding. A structure, however, does not > necessarily require what I call an "encompassing array". Thus the > encompassing array is signalled by the asterisk, because there is a > choice. > > [JLS] If one looks at the COSE document that I am working on. One can > define three maps, one each for an EC key, for an RSA key and for a > secret key. One can then define a base key with common fields that > are not algorithm specific. One could then define single map that > included each of the other items into it by reference rather than as > sub items. > > COSE_KEY : map { base_key; rsa_key; ec_key; secret_key } > [BG] OK, I see, so you want to define a single base_key, and then only one of rsa_key, ec_key, secret_key. Something like: map { "base_key": bstr; choice { "rsa_key": bstr; "ec_key" : bstr; "secret_key": bstr; } } (The choice construct doesn't exist in CDDL, I am just thinking here.) With the issue of identifiers above in mind, one could think of something like a simple switch statement, which only takes primitive types as input. For example: map { "base_key": bstr; "key_type": uint; switch("key_type") { 0: "rsa_key": bstr; 1: "ec_key": bstr; 2: "secret_key": bstr; } } Maybe something to about further. Best regards, Bert > > > /5. I don't understand the last example in section 4.5.1 - You are > combining a structure and a map together into a single item. Would the > syntax "ToString: map(., tstr)" be a better example? This is a map in > this case and that is what you are talking about > / > Yes, indeed this would be better: > > toString: map( ., tstr ); > > (Notice the lower case "t" at the beginning, this is a convention I > use for variable names, although it is not mandatory.) > > Best regards, > Bert > > On 19-01-15 01:59, Sunruinan wrote: > > Hi Bert， I received such email from Jim. Since I can't find it in > appsawg email list, I think this is a system automatic email, is > it right? Can I find some web pages about these comments? As the > title of this email, it means New round of comments. Are these > comments has some relationship with the previous round comments? > Thank you in advance for your reply! Best Regards! Ruinan -----邮 > 件原件----- 发 件人: Jim Schaad [mailto:ietf@augustcellars.com] 发 > 送时间: 2015年1月17日 10:34 收 件人: > draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org > 主题: > New round of comments on draft-greevenbosch-appsawg-cbor-cddl-04 > Here comes a new round of comments on the draft. I have tried not > hit the same points again. 1. You have a length restriction on > float, do you see a need for begin able to do length restrictions > on int, tstr and bstr? I don't know if a restriction based on > number of bytes or based on a value range would be better. It make > sense to use the () syntax to specify a length restriction since > you are already using it for float. 2. You have removed the > union/choice structure from the document. I highly recommend that > this be added back in some form. 3. I will reiterate the request > for some type of alternate syntax for types - i.e. TypeA or TypeB > 4. A structure can be folded at the top level into a structure by > not using the '*' operator on a type. Do you want to be able to do > the same type of thing for a map? 5. I don't understand the last > example in section 4.5.1 - You are combining a structure and a map > together into a single item. Would the syntax "ToString: map(., > tstr)" be a better example? This is a map in this case and that is > what you are talking about Jim . > > > -- Bert Greevenbosch ietf@bertgreevenbosch.nl > > > > > Best regards, > Bert > > On 20-01-15 07:09, Sunruinan wrote: > > Hi Jim, > > Thank you for your comments! > > Since Bert is original editor of this draft and more familiar with previous discussion, I forward your comments to his new email address. > > He can give some answers. > > > > Best Regards! > > Ruinan Sun > > Huawei > > > > -----邮件原件----- > > 发件人: Jim Schaad [mailto:ietf@augustcellars.com] > > 发送时间: 2015年1月17日 10:34 > > 收件人:draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org > > 主题: New round of comments on draft-greevenbosch-appsawg-cbor-cddl-04 > > > > Here comes a new round of comments on the draft. I have tried not hit the same points again. > > > > 1. You have a length restriction on float, do you see a need for begin able to do length restrictions on int, tstr and bstr? I don't know if a restriction based on number of bytes or based on a value range would be better. It make sense to use the () syntax to specify a length restriction since you are already using it for float. > > > > 2. You have removed the union/choice structure from the document. I highly recommend that this be added back in some form. > > > > 3. I will reiterate the request for some type of alternate syntax for types > > - i.e. TypeA or TypeB > > > > 4. A structure can be folded at the top level into a structure by not using > > the '*' operator on a type. Do you want to be able to do the same type of > > thing for a map? > > > > 5. I don't understand the last example in section 4.5.1 - You are combining a structure and a map together into a single item. Would the syntax > > "ToString: map(., tstr)" be a better example? This is a map in this case and that is what you are talking about > > > > > > Jim > > . > > > --------------070600020209030307090506 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Jim,

Thank you for your feedback. Please find my response inline, preceded with "[BG]".

Best regards,
Bert


On 21-01-15 19:51, Jim Schaad wrote:

 

 

From: Bert Greevenbosch [mailto:ietf@bertgreevenbosch.nl]
Sent: Monday, January 19, 2015 10:56 PM
To: Jim Schaad
Cc: draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org
Subject: Re: ??: New round of comments on draft-greevenbosch-appsawg-cbor-cddl-04

 

Hi Jim,

Thank you for your comments. They are very helpful. Please find my answers below.

B.T.W.,would you mind including the apps-discuss mailing list in this discussion? It may be good for the chairs and others to see activity on this draft.

1. You have a length restriction on float, do you see a need for begin able to do length restrictions on int, tstr and bstr? I don't know if a restriction based on number of bytes or based on a value range would be better. It make sense to use the () syntax to specify a length restriction since you are already using it for float.

I started out with such notation, e.g. "int(16)" for a 16-bit integer. However, there is a difference between ints and floats: for any integer number, it is easy to find out how much bits are needed. Hence we could allow some freedom in choosing the number of bits on a per-number basis on the encoder side. This was a comment from Carsten, and we subsequently removed the "int(16)" notation.

For floats, this is harder, as the number of bits does not depend on the value of the variable, but on the precision with which we want to represent that variable. For example, the value 1/3 can be represented using both a float(16) and a float(32), but the latter representation would be closer to the real value than the former.

[JLS] What I was looking for was a size limitation which might be helpful.  That is the integer that goes here is limited to 16 bits.

[BG] Ah yes, that may be helpful. It would mean a slightly different meaning of "(16)" in "float(16)" and "uint(16)", but I could easily get used to that.


3. I will reiterate the request for some type of alternate syntax for types - i.e. TypeA or TypeB

I like your earlier proposed notation:

price: uint | float(16)

and think we can implement this in the next version of the draft.

2. You have removed the union/choice structure from the document. I highly recommend that this be added back in some form.

I think we can use the same solution for (3) as well, as follows:

*smallStructure1 {
   dish: tstr;
   recipe: tstr;
}

*smallStructure2 {
   drink: tstr;
   price: int;
}

*BigStructure : {
   subStructure: smallStructure1 | smallStructure2;
}

Interesting would be how to distinguish between smallStructure1 and smallStructure2. Especially in the following case:

*smallStructure1 {
   dish: tstr;
   recipe: tstr;
}

*smallStructure2 {
   drink: tstr;
   ingredients: tstr;
}

*BigStructure : {
   subStructure: smallStructure1 | smallStructure2;
}

The last may need some more consideration.

[JLS] while one could use tags – is there a reason not to go back to the world of using an int field to discriminate?

[BG] Any way of signalling to the application which of the two structures is meant is indeed required. This could be through an integer that contains a field-id, or in other ways e.g. through the semantics of the rest of the data structure. What I mean is, that it may be obvious to the application which structure is meant by inspecting earlier fields.

For automatic parsing of such structure, this would be much harder though. A complex parser could perform "best effort parsing", whereas a simpler parser could consider ignoring verification of variables with alternative structures as datatype. (Simple datatypes should be easy to handle for simple parsers too.)


4. A structure can be folded at the top level into a structure by not using the '*' operator on a type. Do you want to be able to do the same type of thing for a map?

Not sure about this. Do you have an example?

CDDL maps need a CBOR map encoding. A structure, however, does not necessarily require what I call an "encompassing array". Thus the encompassing array is signalled by the asterisk, because there is a choice.

[JLS]  If one looks at the COSE document that I am working on.  One can define three maps, one each for an EC key, for an RSA key and for a secret key.  One can then define a base key with common fields that are not algorithm specific.  One could then define  single map that included each of the other items into it by reference rather than as sub items.

 

COSE_KEY : map { base_key; rsa_key; ec_key; secret_key }

[BG] OK, I see, so you want to define a single base_key, and then only one of rsa_key, ec_key, secret_key. Something like:

map {
  "base_key": bstr;
  choice {
    "rsa_key": bstr;
    "ec_key" : bstr;
    "secret_key": bstr;
  }
}

(The choice construct doesn't exist in CDDL, I am just thinking here.)

With the issue of identifiers above in mind, one could think of something like a simple switch statement, which only takes primitive types as input. For example:

map {
  "base_key": bstr;
  "key_type": uint;
  switch("key_type") {
    0: "rsa_key": bstr;
    1: "ec_key": bstr;
    2: "secret_key": bstr;
  }
}

Maybe something to about further.

Best regards,
Bert



5. I don't understand the last example in section 4.5.1 - You are combining a structure and a map together into a single item. Would the syntax "ToString: map(., tstr)" be a better example? This is a map in this case and that is what you are talking about

Yes, indeed this would be better:

toString: map( ., tstr );

(Notice the lower case "t" at the beginning, this is a convention I use for variable names, although it is not mandatory.)

Best regards,
Bert

On 19-01-15 01:59, Sunruinan wrote:

Hi Bert， I received such email from Jim. Since I can't find it in appsawg email list, I think this is a system automatic email, is it right? Can I find some web pages about these comments? As the title of this email, it means New round of comments. Are these comments has some relationship with the previous round comments? Thank you in advance for your reply! Best Regards! Ruinan -----邮件原件----- 发 件人: Jim Schaad [mailto:ietf@augustcellars.com] 发 送时间: 2015年1月17日 10:34 收 件人: draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org 主题: New round of comments on draft-greevenbosch-appsawg-cbor-cddl-04 Here comes a new round of comments on the draft. I have tried not hit the same points again. 1. You have a length restriction on float, do you see a need for begin able to do length restrictions on int, tstr and bstr? I don't know if a restriction based on number of bytes or based on a value range would be better. It make sense to use the () syntax to specify a length restriction since you are already using it for float. 2. You have removed the union/choice structure from the document. I highly recommend that this be added back in some form. 3. I will reiterate the request for some type of alternate syntax for types - i.e. TypeA or TypeB 4. A structure can be folded at the top level into a structure by not using the '*' operator on a type. Do you want to be able to do the same type of thing for a map? 5. I don't understand the last example in section 4.5.1 - You are combining a structure and a map together into a single item. Would the syntax "ToString: map(., tstr)" be a better example? This is a map in this case and that is what you are talking about Jim .


-- Bert Greevenbosch ietf@bertgreevenbosch.nl



Best regards,
Bert

On 20-01-15 07:09, Sunruinan wrote:

Hi Jim,
Thank you for your comments!
Since Bert is original editor of this draft and more familiar with previous discussion, I forward your comments to his new email address.
He can give some answers.
 
Best Regards!
Ruinan Sun
Huawei
 
-----邮件原件-----
发件人: Jim Schaad [mailto:ietf@augustcellars.com] 
发送时间: 2015年1月17日 10:34
收件人: draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org
主题: New round of comments on draft-greevenbosch-appsawg-cbor-cddl-04
 
Here comes a new round of comments on the draft.  I have tried not hit the same points again.
 
1. You have a length restriction on float, do you see a need for begin able to do length restrictions on int, tstr and bstr?  I don't know if a restriction based on number of bytes or based on a value range would be better.  It make sense to use the () syntax to specify a length restriction since you are already using it for float.
 
2. You have removed the union/choice structure from the document.  I highly recommend that this be added back in some form.
 
3. I will reiterate the request for some type of alternate syntax for types
- i.e. TypeA or TypeB
 
4. A structure can be folded at the top level into a structure by not using
the '*' operator on a type.   Do you want to be able to do the same type of
thing for a map? 
 
5. I don't understand the last example in section 4.5.1 - You are combining a structure and a map together into a single item.  Would the syntax
"ToString: map(., tstr)" be a better example?  This is a map in this case and that is what you are talking about
 
 
Jim
.
 

 


--------------070600020209030307090506-- From nobody Mon Jan 26 06:56:07 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D51B1A88C9 for ; Mon, 26 Jan 2015 06:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tANegvIdBm0I for ; Mon, 26 Jan 2015 06:56:03 -0800 (PST) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3751A8ABF for ; Mon, 26 Jan 2015 06:56:03 -0800 (PST) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YFl57-0006Q6-hX; Mon, 26 Jan 2015 14:56:01 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YFl57-0007LB-Ds; Mon, 26 Jan 2015 14:56:01 +0000 Message-ID: <54C65580.2080407@ninebynine.org> Date: Mon, 26 Jan 2015 14:56:00 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Larry Masinter References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <015c01d0362f$1f6f6020$4001a8c0@gateway.2wire.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-iri-comparison X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jan 2015 14:56:05 -0000 IF this issue gets further discussion, I'd be very concerned that a comparison of URI beyond simple character comparison would not be universally implemented. E.g., I do from time-to-time use URIs as index values for dictionary lookups - that depends implicitly on character-based equality. Further I don't believe it is possible to completely define URI equivalence of different URI strings in a meaningful way, because the notion of equivalence depends on context of use. When working with, say, RDF, when it is important to be sure that two references are denoting the same thing, the easy way is to just use the same referring string; alternatively, use some extrinsic assertion that two different URIs are denoting the same thing. In other words, why bother? Just keep it simple. #g -- On 23/01/2015 05:23, Larry Masinter wrote: > Tom Petch wrote, re draft-ietf-iri-comparison > >> I notice that this (expired) I-D updates RFC3986 which seems germane to >> recent discussions on this list. Reading it, I can see why it might >> update RFC3987 or 3987bis but cannot see where it updates RFC3986. >> What am I missing? > > I'm afraid > > " As URIs are a subset of IRIs, the guidelines apply to URI comparison as well." > > should have said the id ("Comparison, Equivalence and Canonicalization > of Internationalized Resource Identifiers") > was intended to replace RFC 3986 section 6 "Normalization and Comparison" > in its entirety. > > At this point I'd suggest comments on open in URL issues > https://github.com/webspecs/url/issues/18 > https://www.w3.org/Bugs/Public/show_bug.cgi?id=27640 > > Should equivalence of URLs should mandate that if you parse URL A and > get back URI B, then A must be equivalent to B? > Then, if you have a different URL C that turns into B, C must also be equivalent > to A and B. Even for URLs that are valid URIs. > This requirement in 3986 is just a MAY. > > Larry > -- > http://larry.masinter.net > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Mon Jan 26 10:21:50 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16FD1A8033 for ; Mon, 26 Jan 2015 10:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMHCEXHe-kwo for ; Mon, 26 Jan 2015 10:21:46 -0800 (PST) Received: from mail-in3.euro.apple.com (mail-in3.euro.apple.com [17.72.148.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEDB91A7007 for ; Mon, 26 Jan 2015 10:21:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1422296503; x=2286210103; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DcAHLZ9stNi/8o+jUyR+YcYsQ8y7bQYZC9hfvyQPxSc=; b=QYPSytdD4TLdQmiz+cmg6+BGc1AJPaSZuNpG1uQLGMp1RQZYKg7lqab9pyCRgpfw ZbIb56KS1XLqCWD2+UZlGXtgKPz7vqXyKlHLowymeyvsXg2Lq2D6AleOzgcJNBVY lriTXFO/EmDutxXQc2UPXU9ztXF49+DA/TNpmBJqajQ0YPLRov+obwU6dY6rJXeN xAyoWwpicEqZvL6SZ1RM7152REzGVJ2ohsGcmYylSU75Z0QD3BM3C2GPOVm2gxO5 xjEAngQp/24Kp7Ju0+IfeU4kQldWKRw4uetRC6e1Tf+Ft1i6OVAn/mSp4jugyrSG hT9ENKnCoYleWfJzjlqIbQ==; Received: from relay1.euro.apple.com ( [17.66.55.11]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail-in3.euro.apple.com (Symantec Mail Security) with SMTP id 96.D2.31914.7B586C45; Mon, 26 Jan 2015 18:21:43 +0000 (GMT) X-AuditID: 1148940d-f79936d000007caa-ed-54c685b7b680 Received: from crk-mmpp-sz02 (crk-mmpp-sz02.euro.apple.com [17.66.12.155]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay1.euro.apple.com (Symantec Mail Security) with SMTP id 41.27.19613.6B586C45; Mon, 26 Jan 2015 18:21:43 +0000 (GMT) Received: from nlams2-asavpn-l2tp-17-78-242-231.euro.apple.com ([17.78.242.231]) by crk-mmpp-sz02.euro.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NIS00A92R01IW70@crk-mmpp-sz02.euro.apple.com> for apps-discuss@ietf.org; Mon, 26 Jan 2015 18:21:42 +0000 (GMT) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: <54C65580.2080407@ninebynine.org> Date: Mon, 26 Jan 2015 19:21:37 +0100 Content-transfer-encoding: quoted-printable Message-id: References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <015c01d0362f$1f6f6020$4001a8c0@gateway.2wire.net> <54C65580.2080407@ninebynine.org> To: "apps-discuss@ietf.org" X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUi6GTOrbu99ViIwZ0uDovVL1ewOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4+btJewF5yQrji08xdjAeEuki5GTQ0LAROL95zfMELaYxIV7 69m6GLk4hAQmMkmsbjoC5HCAFXVv0YeIL2SSWDH/JzOEc5xJ4sSKzUwgRcwC6hJTpuSCDOIV 0JNoevKYCcQWFjCVeLh9ETuIzSagKvFgzjFGEJsTqKZlwjIwmwUofvHNYVYQm1lARWLZuz/s ELa2xJN3F1ghZtpIHHn9hB1i7y5WicNve8GaRQSMJSZtXsIG8YGsxL+LZ9gh7K+sEnsOGk1g FJ6FcN4sJOfNQrJiASPzKkbx3MTMHN3MPGO91NKifL3EgoKcVL3k/NxNjKBw9pjCu4Px+kHD Q4wCHIxKPLwfs4+FCLEmlhVX5h5ilOBgVhLhlc4FCvGmJFZWpRblxxeV5qQWH2KU5mBREudl mjk9REggPbEkNTs1tSC1CCbLxMEp1cCYfZYrwX/VSR2ZwETjdxP8PkYenLOmLkrdVO/RFIue vU81JP9wlN9nlPv/b/fPyZMiqpXztifn+L3erbvCV9Rsy75t3U1zVS0CTcUdZS882ugYmmzN ctz1yqvNitI3vvJq/vqQ4Z4X8Z5XXubjB7G+tL66+4cl5hUYmk3Yn5Nz1OLr8gnph9yVWIoz Eg21mIuKEwEP9HY1YwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUi6MQzW3d767EQg+4lbBarX65gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxs3bS9gLzklWHFt4irGB8ZZIFyMHh4SAiUT3Fv0uRk4gU0zi wr31bF2MXBxCAguZJFbM/8kM4RxnkjixYjMTSAOzgLrElCm5IA28AnoSTU8eM4HYwgKmEg+3 L2IHsdkEVCUezDnGCGJzAtW0TFgGZrMAxS++OcwKYjMLqEgse/eHHcLWlnjy7gIrxEwbiSOv n7BD7N3FKnH4bS9Ys4iAscSkzUvYIC6Vlfh38Qz7BEaBWQgnzUJy0iwkYxcwMq9iFC1KzUms NNRLLS3K10ssKMhJ1UvOz93ECA5Ac+4djMd3Gx5iFOBgVOLhNQcGphBrYllxZe4hRgkOZiUR XulcoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHe5+39wUIC6YklqdmpqQWpRTBZJg5OqQbGwB9d p998Vm3amhuhplbpEjSpL3tX8ppmn2nfnv2rN11+uO7lKv8vh73W+6RtzFQ9M0M+fe2HbfX1 kZV97vkVkc6yvIut9cRF7z7+c2SCqp5LdYN77CH5vLblm5r4H7Wb6XPPTng21fzVDPXqI5dZ v7vM+/3pjixL7oLwbYddtwU0v3ozZ9NEJZbijERDLeai4kQAfEw0OTwCAAA= Archived-At: Cc: Graham Klyne Subject: Re: [apps-discuss] draft-ietf-iri-comparison X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jan 2015 18:21:48 -0000 > On Jan 26, 2015, at 15:56 , Graham Klyne wrote: >=20 > IF this issue gets further discussion, I'd be very concerned that a = comparison of URI beyond simple character comparison would not be = universally implemented. E.g., I do from time-to-time use URIs as index = values for dictionary lookups - that depends implicitly on = character-based equality. >=20 > Further I don't believe it is possible to completely define URI = equivalence of different URI strings in a meaningful way, because the = notion of equivalence depends on context of use. When working with, = say, RDF, when it is important to be sure that two references are = denoting the same thing, the easy way is to just use the same referring = string; alternatively, use some extrinsic assertion that two different = URIs are denoting the same thing. >=20 > In other words, why bother? Just keep it simple. I guess it depends on what you mean by simple.=20 The simplest for the receiver is to say it=E2=80=99s byte-by-byte = equality. The simplest for each environment that the URI might pass = through is to insist it=E2=80=99s in the normal form for that = environment. These are in conflict. So, if at the terminal the URIs arrive, hypothetically one by a route = that wants UTF-8 and escaping, and the other by a route that handles = everything in UTF-16, the terminal won=E2=80=99t find byte equality when = the user expects it. The URIs need to be put in a canonical form. Which = means that that needs defining, alas. What am I missing? >=20 > #g > -- >=20 >=20 > On 23/01/2015 05:23, Larry Masinter wrote: >> Tom Petch wrote, re draft-ietf-iri-comparison >>=20 >>> I notice that this (expired) I-D updates RFC3986 which seems germane = to >>> recent discussions on this list. Reading it, I can see why it might >>> update RFC3987 or 3987bis but cannot see where it updates RFC3986. >>> What am I missing? >>=20 >> I'm afraid >>=20 >> " As URIs are a subset of IRIs, the guidelines apply to URI = comparison as well." >>=20 >> should have said the id ("Comparison, Equivalence and = Canonicalization >> of Internationalized Resource Identifiers") >> was intended to replace RFC 3986 section 6 "Normalization and = Comparison" >> in its entirety. >>=20 >> At this point I'd suggest comments on open in URL issues >> https://github.com/webspecs/url/issues/18 >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D27640 >>=20 >> Should equivalence of URLs should mandate that if you parse URL A = and >> get back URI B, then A must be equivalent to B? >> Then, if you have a different URL C that turns into B, C must also be = equivalent >> to A and B. Even for URLs that are valid URIs. >> This requirement in 3986 is just a MAY. >>=20 >> Larry >> -- >> http://larry.masinter.net >>=20 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss David Singer Manager, Software Standards, Apple Inc. From nobody Mon Jan 26 18:06:02 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B198C1A1B39 for ; Mon, 26 Jan 2015 18:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wO8fpiirGumM for ; Mon, 26 Jan 2015 18:05:43 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5061A008B for ; Mon, 26 Jan 2015 18:05:42 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id BF0D62005D82E; Mon, 26 Jan 2015 18:05:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=mlNAhiFH6Ps0TLWgb69FwU6aT44=; b=GsfQHEN+mYtvQHqA1XzJgzD/5B9+ 2hE5SHuWNUD5BgVHQ/cGwi1Zg9QOxbYJahsTyDjOVsQARPz0Bn7g3pUkGBwjsV97 znbrHVC6tOxd+Vm65oYjX+E30+LZzkEr6KKlPhPgVykcCFJKp3s9uwJ+OI2g/gvh LbTeEguZrIEqeEg= Received: from [192.168.1.12] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPSA id A73642005D82D; Mon, 26 Jan 2015 18:05:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: "Roy T. Fielding" In-Reply-To: Date: Mon, 26 Jan 2015 18:05:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <84E353AE-D96B-4211-99CB-D08AE17B1B1E@gbiv.com> References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <015c01d0362f$1f6f6020$4001a8c0@gateway.2wire.net> <54C65580.2080407@ninebynine.org> To: David Singer X-Mailer: Apple Mail (2.1283) Archived-At: Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-iri-comparison X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jan 2015 02:05:49 -0000 On Jan 26, 2015, at 10:21 AM, David Singer wrote: >> On Jan 26, 2015, at 15:56 , Graham Klyne wrote: >>=20 >> IF this issue gets further discussion, I'd be very concerned that a = comparison of URI beyond simple character comparison would not be = universally implemented. E.g., I do from time-to-time use URIs as index = values for dictionary lookups - that depends implicitly on = character-based equality. >>=20 >> Further I don't believe it is possible to completely define URI = equivalence of different URI strings in a meaningful way, because the = notion of equivalence depends on context of use. When working with, = say, RDF, when it is important to be sure that two references are = denoting the same thing, the easy way is to just use the same referring = string; alternatively, use some extrinsic assertion that two different = URIs are denoting the same thing. >>=20 >> In other words, why bother? Just keep it simple. >=20 > I guess it depends on what you mean by simple.=20 >=20 > The simplest for the receiver is to say it=92s byte-by-byte equality. = The simplest for each environment that the URI might pass through is to = insist it=92s in the normal form for that environment. >=20 > These are in conflict. >=20 > So, if at the terminal the URIs arrive, hypothetically one by a route = that wants UTF-8 and escaping, and the other by a route that handles = everything in UTF-16, the terminal won=92t find byte equality when the = user expects it. The URIs need to be put in a canonical form. Which = means that that needs defining, alas. Technically speaking, what namespaces use is character-by-character equality. Hence, that is not a problem. > What am I missing? I think people assume there exists some canonical form, and that it makes some difference to the application that it knows that form (or at least is able to derive it from a non-canonical URI). The reality is that a canonical form (if any) is only known by the = person who configures the software to provide a service that is associated with a given URI. All other forms are aliases. Some of those aliases might be mechanically expected (like hostname case), but others could be just as canonical as the first. In some cases, the preponderance of use in one form over another causes the original owner to change their mind about which URI is canonical. Regardless, what Graham noted is true: the definition of canonical for caching/reusing a GET is very different from the definition of canonical for something like namespaces. That was a deliberate decision, whether we agree with it or not, so it is fair to say that there is no single standard for canonicalizing a URI (or URL). This is, of course, why we have a link relation for canonical. It is not an algorithm that can be written, in code or in spec, so it is not a bug that needs fixing in RFC3986 (or anything that pretends to supplant it). The URI spec defines normalization of URIs in ways that are not scheme-specific. The scheme specs are supposed to define what can be normalized within each scheme. ....Roy p.s. Am I the only one that finds it incredibly annoying that the APPS area uses this umbrella list for technical discussions about topics for which we still have the original working group mailing list active, archived, and populated with folks still capable of answering these questions? Ya know, "http://lists.w3.org/Archives/Public/uri/" "http://lists.w3.org/Archives/Public/public-iri/" From nobody Tue Jan 27 09:19:21 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B79A1A8879 for ; Tue, 27 Jan 2015 09:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5sd2zC8QIIu for ; Tue, 27 Jan 2015 09:19:18 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0070.outbound.protection.outlook.com [65.55.169.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890D21A7029 for ; Tue, 27 Jan 2015 09:19:18 -0800 (PST) Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 27 Jan 2015 17:19:16 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) by DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) with mapi id 15.01.0065.013; Tue, 27 Jan 2015 17:19:16 +0000 From: Larry Masinter To: Graham Klyne Thread-Topic: [apps-discuss] draft-ietf-iri-comparison Thread-Index: AQHQNi9NMknCnoECn062w/S4lSg7MpzNBGKggAV/pACAAbYn4A== Date: Tue, 27 Jan 2015 17:19:16 +0000 Message-ID: References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <015c01d0362f$1f6f6020$4001a8c0@gateway.2wire.net> <54C65580.2080407@ninebynine.org> In-Reply-To: <54C65580.2080407@ninebynine.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] authentication-results: ninebynine.org; dkim=none (message not signed) header.d=none;ninebynine.org; dmarc=none action=none header.from=adobe.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DM2PR0201MB0960; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB0960; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(110136001)(102836002)(54206007)(93886004)(40100003)(66066001)(99286002)(122556002)(2900100001)(2950100001)(74316001)(2656002)(15975445007)(76176999)(54356999)(54606007)(46102003)(50986999)(19580395003)(76576001)(87936001)(62966003)(106116001)(77156002)(92566002)(86362001)(33656002)(230783001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0960; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2015 17:19:16.4607 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB0960 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-iri-comparison X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jan 2015 17:19:20 -0000 PiBJRiB0aGlzIGlzc3VlIGdldHMgZnVydGhlciBkaXNjdXNzaW9uLCBJJ2QgYmUgdmVyeSBjb25j ZXJuZWQgdGhhdCBhDQo+IGNvbXBhcmlzb24gb2YgVVJJIGJleW9uZCBzaW1wbGUgY2hhcmFjdGVy IGNvbXBhcmlzb24gd291bGQgDQo+IG5vdCBiZSB1bml2ZXJzYWxseSBpbXBsZW1lbnRlZC4NCg0K SSBkb24ndCB1bmRlcnN0YW5kIHlvdXIgY29uY2Vybi4gUkZDIDM5ODYgKFN0YW5kYXJkKSBhbmQg UkZDIDM5ODcNCihQcm9wb3NlZCBTdGFuZGFyZCkgYWxyZWFkeSB0YWxrIGFib3V0IGNvbXBhcmlz b24sIGluIGEgd2F5IHRoYXQNCmlzIGluY29tcGxldGUsIGFuZCBhdCB0aW1lcyBjb25mdXNpbmcg KGUuZy4sIGJ5IG5vdCBiZWluZyBjbGVhcg0KYWJvdXQgY29tcGFyaXNvbiB2cy4gZXF1aXZhbGVu Y2UgdnMuIGNhbm9uaWNhbGl6YXRpb24gb3INCm5vcm1hbGl6YXRpb24gYXMgY29uY2VwdHMuKQ0K DQpBbmQgc29tZSBraW5kcyBvZiBjb21wYXJpc29uIG5lZWQgc3RhbmRhcmRpemF0aW9uLCBsaWtl IGZvcg0KJ29yaWdpbicuDQoNCj4gRnVydGhlciBJIGRvbid0IGJlbGlldmUgaXQgaXMgcG9zc2li bGUgdG8gY29tcGxldGVseSBkZWZpbmUgVVJJDQo+IGVxdWl2YWxlbmNlIG9mIGRpZmZlcmVudCBV Ukkgc3RyaW5ncyBpbiBhIG1lYW5pbmdmdWwgd2F5LCANCg0KSSBkb24ndCB0aGluayB0aGUgZ29h bCBpcyB0byAiY29tcGxldGVseSBkZWZpbmUiIGl0LCBidXQgcmF0aGVyDQpwdXQgc29tZSBjb25z dHJhaW50cyBvbiBjb25mb3JtaW5nIGNvbXBhcmlzb24gbWV0aG9kcw0Kc3VjaCB0aGF0IFVSSS9V UkwvSVJJIHByb2R1Y2VycyBjYW4gbWFrZSBhc3N1bXB0aW9ucyBhYm91dA0KdGhlIElSSS9VUkwg LT4gVVJJIGNvbnZlcnNpb24gKGFuZCBVUkkgLT4gSVJJL1VSTCB0b28pLA0KTmFtZWx5IHRoYXQg dGhlIGNvbnZlcnNpb24gcmVzdWx0IHdpbGwgYmUgZXF1aXZhbGVudCB1bmRlcg0KYW55IGNvbmZv cm1pbmcgY29tcGFyaXNvbiBtZXRob2QgKG90aGVyIHRoYW4gY29kZS1wb2ludA0KYnkgY29kZS1w b2ludC4pDQoNCkxhcnJ5DQotLQ0KaHR0cDovL2xhcnJ5Lm1hc2ludGVyLm5ldA0K From nobody Tue Jan 27 15:01:54 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDAEA1A90DF for ; Tue, 27 Jan 2015 15:01:50 -0800 (PST) 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 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 sGPxcI0mclEB for ; Tue, 27 Jan 2015 15:01:48 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 6DE361A90E5 for ; Tue, 27 Jan 2015 15:01:35 -0800 (PST) Received: from [192.168.1.83] (unknown [118.209.44.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 01A1522E260; Tue, 27 Jan 2015 18:01:22 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Mark Nottingham In-Reply-To: <84E353AE-D96B-4211-99CB-D08AE17B1B1E@gbiv.com> Date: Wed, 28 Jan 2015 10:01:19 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <015c01d0362f$1f6f6020$4001a8c0@gateway.2wire.net> <54C65580.2080407@ninebynine.org> <84E353AE-D96B-4211-99CB-D08AE17B1B1E@gbiv.com> To: Roy Fielding X-Mailer: Apple Mail (2.1993) Archived-At: Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-iri-comparison X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jan 2015 23:01:51 -0000 On 27 Jan 2015, at 1:05 pm, Roy T. Fielding wrote: > p.s. Am I the only one that finds it incredibly annoying that the > APPS area uses this umbrella list for technical discussions about > topics for which we still have the original working group mailing > list active, archived, and populated with folks still capable of > answering these questions? Ya know, >=20 > "http://lists.w3.org/Archives/Public/uri/" > "http://lists.w3.org/Archives/Public/public-iri/" Nope - you are far from alone. However, appsawg is an active WG, whereas = URI/IRI are not, so perhaps that's why people tend to direct attention = here. I'd far prefer that appsawg were shut down and replaced by "mail" and = "Web" WGs, the latter taking responsibility for URIs. They'd fight over = format stuff, but that mirrors real life... /me notes arc of grenade and makes hasty exit -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jan 27 15:59:29 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B0A1A923D for ; Tue, 27 Jan 2015 15:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weJzeaRPjfnM for ; Tue, 27 Jan 2015 15:59:25 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADBA21A923A for ; Tue, 27 Jan 2015 15:59:25 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id x19so18555763ier.10 for ; Tue, 27 Jan 2015 15:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u/pp/2LAv16eWuRjokUyqCL805RLFg1bYrAxvGAMeZ8=; b=zQh4RA3U2HkYVp744sur+JyMuFs1zqwcW4GfWw9AKmxoR5ZETEdUd7e/4IU6U2+FfD QiMuCwF6KZeOU6MVDztYae659Z+7hghva1hdbiJ/6oJ+nEQ0oSgxxoZRPi2RldzWYB93 iiDRHpOhzrII0cZavebvDkaXL+fGMNEuLIO02wZp7Z2UBD1X2vcfPokgA6F50FrGIahf jXnfgT2apS01EAUz9UCNUL6jV9rYs9cYDC8wQ/IaIhtPSED3+Y8q7CN+X0E1L+bhr+8o ZbV/+dpaGVZTeiK57/GhnB4uVEUb12qFGW2ZFlmURl6pTzXPeotDaLFsmB3VqMXuFmGq cR6w== MIME-Version: 1.0 X-Received: by 10.42.62.145 with SMTP id y17mr695153ich.21.1422403164855; Tue, 27 Jan 2015 15:59:24 -0800 (PST) Received: by 10.36.17.68 with HTTP; Tue, 27 Jan 2015 15:59:23 -0800 (PST) Received: by 10.36.17.68 with HTTP; Tue, 27 Jan 2015 15:59:23 -0800 (PST) In-Reply-To: References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <015c01d0362f$1f6f6020$4001a8c0@gateway.2wire.net> <54C65580.2080407@ninebynine.org> <84E353AE-D96B-4211-99CB-D08AE17B1B1E@gbiv.com> Date: Tue, 27 Jan 2015 15:59:23 -0800 Message-ID: From: James M Snell To: Mark Nottingham Content-Type: multipart/alternative; boundary=90e6ba6149a05e66d1050dab0ba1 Archived-At: Cc: Roy Fielding , Graham Klyne , IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-iri-comparison X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jan 2015 23:59:27 -0000 --90e6ba6149a05e66d1050dab0ba1 Content-Type: text/plain; charset=UTF-8 Silent +1 thrown in from somewhere in the back On Jan 27, 2015 3:01 PM, "Mark Nottingham" wrote: > On 27 Jan 2015, at 1:05 pm, Roy T. Fielding wrote: > > > p.s. Am I the only one that finds it incredibly annoying that the > > APPS area uses this umbrella list for technical discussions about > > topics for which we still have the original working group mailing > > list active, archived, and populated with folks still capable of > > answering these questions? Ya know, > > > > "http://lists.w3.org/Archives/Public/uri/" > > "http://lists.w3.org/Archives/Public/public-iri/" > > Nope - you are far from alone. However, appsawg is an active WG, whereas > URI/IRI are not, so perhaps that's why people tend to direct attention here. > > I'd far prefer that appsawg were shut down and replaced by "mail" and > "Web" WGs, the latter taking responsibility for URIs. They'd fight over > format stuff, but that mirrors real life... > > /me notes arc of grenade and makes hasty exit > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --90e6ba6149a05e66d1050dab0ba1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Silent +1 thrown in from somewhere in the back

On Jan 27, 2015 3:01 PM, "Mark Nottingham&q= uot; <mnot@mnot.net> wrote:
On 27 Jan 2015, at 1:05 = pm, Roy T. Fielding <fielding@gbiv.= com> wrote:

> p.s.=C2=A0 Am I the only one that finds it incredibly annoying that th= e
>=C2=A0 =C2=A0 =C2=A0 APPS area uses this umbrella list for technical di= scussions about
>=C2=A0 =C2=A0 =C2=A0 topics for which we still have the original workin= g group mailing
>=C2=A0 =C2=A0 =C2=A0 list active, archived, and populated with folks st= ill capable of
>=C2=A0 =C2=A0 =C2=A0 answering these questions?=C2=A0 Ya know,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"http://lists.w3.org/Archives/Public= /uri/"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"http://lists.w3.org/Archives= /Public/public-iri/"

Nope - you are far from alone. However, appsawg is an active WG, whereas UR= I/IRI are not, so perhaps that's why people tend to direct attention he= re.

I'd far prefer that appsawg were shut down and replaced by "mail&q= uot; and "Web" WGs, the latter taking responsibility for URIs. Th= ey'd fight over format stuff, but that mirrors real life...

/me notes arc of grenade and makes hasty exit

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
--90e6ba6149a05e66d1050dab0ba1-- From nobody Tue Jan 27 17:54:03 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E021A1ABE for ; Tue, 27 Jan 2015 17:54:01 -0800 (PST) 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 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 Yoj6yMU3DGrw for ; Tue, 27 Jan 2015 17:53:59 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 2C4691A1AB1 for ; Tue, 27 Jan 2015 17:53:59 -0800 (PST) Received: from [192.168.1.83] (unknown [118.209.44.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A5E0722E261; Tue, 27 Jan 2015 20:53:52 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Mark Nottingham In-Reply-To: <54AEB660.1020701@intertwingly.net> Date: Wed, 28 Jan 2015 12:53:48 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54AEB660.1020701@intertwingly.net> To: Sam Ruby X-Mailer: Apple Mail (2.1993) Archived-At: Cc: Alex Russell , Domenic Denicola , IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 01:54:02 -0000 Hi Sam, > On 9 Jan 2015, at 3:54 am, Sam Ruby wrote: >=20 > Mark cares about valid URIs. He's certainly not alone in that. What = he has done is express his interests not merely in high level prose, but = in concrete, executable form. Given that he has done that, I can pose = some interesting questions. For example, if you consider the process of = canonicalizing a href value on an element and stringifying the = result, an implementation like Chrome will produce something that will = be sent across the wire. I've captured the results here: >=20 > = https://raw.githubusercontent.com/webspecs/url/develop/evaluate/useragent-= results/chrome >=20 > Given that data and Mark's script, I can produce a list of outputs = that Mark doesn't consider valid: [...] > With this data, we can have a discussion as to whether Mark's script = should be updated, or Chrome should change, or some spec should change. What I was hoping for was an update of the "valid URI" filter to take = this into account at = . E.g., that list currently includes test case 63, "https:/example.com/", = which is valid according to the generic syntax in RFC3986, but not when = you consider the scheme-specific constraints for HTTPS in RFC7230. By filtering out these cases, we can see the places we potentially need = to pay attention to in the RFCs. Is that possible? Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jan 27 17:57:05 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85411ACC80 for ; Tue, 27 Jan 2015 17:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1wqavNLmu4w for ; Tue, 27 Jan 2015 17:57:01 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 436081ACC83 for ; Tue, 27 Jan 2015 17:56:57 -0800 (PST) Received: from [192.168.1.83] (unknown [118.209.44.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9958622E263; Tue, 27 Jan 2015 20:56:55 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Mark Nottingham In-Reply-To: <54BC3916.7000800@intertwingly.net> Date: Wed, 28 Jan 2015 12:56:52 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <9D9F5DD6-0412-4A46-A3BC-543DBE9A6CB5@mnot.net> References: <54BC3916.7000800@intertwingly.net> To: Sam Ruby X-Mailer: Apple Mail (2.1993) Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 01:57:03 -0000 Fixed, thanks! > On 19 Jan 2015, at 9:52 am, Sam Ruby wrote: >=20 > On 01/07/2015 04:35 PM, Mark Nottingham wrote: >> I=E2=80=99ve updated my Python script that serves as a translation of = ABNF for URIs into regex. >>=20 >> https://gist.github.com/mnot/138549 >=20 > I've attempted to convert this to JavaScript: >=20 > https://url.spec.whatwg.org/reference-implementation/uri-validate.js >=20 > I've built a web page that makes use of it: >=20 > https://url.spec.whatwg.org/reference-implementation/uri-validate.html >=20 > - - - >=20 > Issues I encountered the process: >=20 > 1) file_auth_path is defined with four instead of three double quotes >=20 > 2) the last re.match rejects inputs that do not have a hash sign >=20 > 3) extra, and potentially misleading, output is provided if instr = starts with the characters "absolute:". >=20 > - Sam Ruby -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jan 27 18:24:58 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077921ACC86 for ; Tue, 27 Jan 2015 18:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujdeA87X3sRN for ; Tue, 27 Jan 2015 18:24:52 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.232]) by ietfa.amsl.com (Postfix) with ESMTP id BF1651ACC82 for ; Tue, 27 Jan 2015 18:24:52 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:17582] helo=rubix) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id A0/05-10978-37848C45; Wed, 28 Jan 2015 02:24:52 +0000 Received: from rubymacb.local (cpe-098-027-051-253.nc.res.rr.com [98.27.51.253]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 523E71408AD; Tue, 27 Jan 2015 21:24:52 -0500 (EST) Message-ID: <54C84872.5040902@intertwingly.net> Date: Tue, 27 Jan 2015 21:24:50 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Mark Nottingham References: <54AEB660.1020701@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 02:24:55 -0000 On 1/27/15 8:53 PM, Mark Nottingham wrote: > Hi Sam, > >> On 9 Jan 2015, at 3:54 am, Sam Ruby wrote: >> >> Mark cares about valid URIs. He's certainly not alone in that. What he has done is express his interests not merely in high level prose, but in concrete, executable form. Given that he has done that, I can pose some interesting questions. For example, if you consider the process of canonicalizing a href value on an element and stringifying the result, an implementation like Chrome will produce something that will be sent across the wire. I've captured the results here: >> >> https://raw.githubusercontent.com/webspecs/url/develop/evaluate/useragent-results/chrome >> >> Given that data and Mark's script, I can produce a list of outputs that Mark doesn't consider valid: > > [...] > >> With this data, we can have a discussion as to whether Mark's script should be updated, or Chrome should change, or some spec should change. > > What I was hoping for was an update of the "valid URI" filter to take this into account at . > > E.g., that list currently includes test case 63, "https:/example.com/", which is valid according to the generic syntax in RFC3986, but not when you consider the scheme-specific constraints for HTTPS in RFC7230. > > By filtering out these cases, we can see the places we potentially need to pay attention to in the RFCs. > > Is that possible? Since that code runs filters on the browser, it would be easiest for me integrate code written in JavaScript. Can you review the generated JavaScript? https://url.spec.whatwg.org/reference-implementation/uri-validate.js https://url.spec.whatwg.org/reference-implementation/uri-validate.html Also, I would like to discuss where this code should live: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13635.html > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ - Sam Ruby From nobody Tue Jan 27 21:36:37 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634841A0018 for ; Tue, 27 Jan 2015 21:36:33 -0800 (PST) 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 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 cDSTsZNEvJI3 for ; Tue, 27 Jan 2015 21:36:31 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 50A281A0016 for ; Tue, 27 Jan 2015 21:36:31 -0800 (PST) Received: from [192.168.1.83] (unknown [118.209.44.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2955E22E264; Wed, 28 Jan 2015 00:36:24 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Mark Nottingham In-Reply-To: <54C84872.5040902@intertwingly.net> Date: Wed, 28 Jan 2015 16:36:20 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54AEB660.1020701@intertwingly.net> <54C84872.5040902@intertwingly.net> To: Sam Ruby X-Mailer: Apple Mail (2.1993) Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 05:36:33 -0000 > On 28 Jan 2015, at 1:24 pm, Sam Ruby wrote: >=20 > On 1/27/15 8:53 PM, Mark Nottingham wrote: >> Hi Sam, >>=20 >>> On 9 Jan 2015, at 3:54 am, Sam Ruby wrote: >>>=20 >>> Mark cares about valid URIs. He's certainly not alone in that. = What he has done is express his interests not merely in high level = prose, but in concrete, executable form. Given that he has done that, I = can pose some interesting questions. For example, if you consider the = process of canonicalizing a href value on an element and = stringifying the result, an implementation like Chrome will produce = something that will be sent across the wire. I've captured the results = here: >>>=20 >>> = https://raw.githubusercontent.com/webspecs/url/develop/evaluate/useragent-= results/chrome >>>=20 >>> Given that data and Mark's script, I can produce a list of outputs = that Mark doesn't consider valid: >>=20 >> [...] >>=20 >>> With this data, we can have a discussion as to whether Mark's script = should be updated, or Chrome should change, or some spec should change. >>=20 >> What I was hoping for was an update of the "valid URI" filter to take = this into account at = . >>=20 >> E.g., that list currently includes test case 63, = "https:/example.com/", which is valid according to the generic syntax in = RFC3986, but not when you consider the scheme-specific constraints for = HTTPS in RFC7230. >>=20 >> By filtering out these cases, we can see the places we potentially = need to pay attention to in the RFCs. >>=20 >> Is that possible? >=20 > Since that code runs filters on the browser, it would be easiest for = me integrate code written in JavaScript. >=20 > Can you review the generated JavaScript? >=20 > https://url.spec.whatwg.org/reference-implementation/uri-validate.js > https://url.spec.whatwg.org/reference-implementation/uri-validate.html It looks like a reasonable transcription. I do notice you copied my = error: return new RegExp("^" + known[scheme] + "(#|$)").test(string) I think it should just be: return new RegExp("^" + known[scheme] + "$").test(string) ... which brings about another interesting observation -- only http and = https define fragments in their syntax; the other schemes do not. > Also, I would like to discuss where this code should live: >=20 > = http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13635.html I want to keep it going in Python, so I'll probably create a separate = repo at some point; is it bothersome to just keep the JS in your repo? If bugs are found in the regex themselves, I'll make sure to notify you = (and would appreciate the same). Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jan 27 23:16:27 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1F01A005D for ; Tue, 27 Jan 2015 23:16:25 -0800 (PST) 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 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 7ejyZSNv1iK6 for ; Tue, 27 Jan 2015 23:16:24 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 6C9DB1A0055 for ; Tue, 27 Jan 2015 23:16:24 -0800 (PST) Received: from [192.168.1.83] (unknown [118.209.44.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DA5DF22E1F4 for ; Wed, 28 Jan 2015 02:16:22 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <96A9C601-C46D-40CF-9E91-C87E11E85197@mnot.net> Date: Wed, 28 Jan 2015 18:16:19 +1100 To: IETF Apps Discuss Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: Subject: Re: [apps-discuss] Last Call: (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 07:16:26 -0000 This may be of interest to some here. -- Mark Nottingham https://www.mnot.net/ From nobody Wed Jan 28 00:20:36 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1EA1A00E9 for ; Wed, 28 Jan 2015 00:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLUM63os3-Yy for ; Wed, 28 Jan 2015 00:20:33 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 618611A00ED for ; Wed, 28 Jan 2015 00:20:33 -0800 (PST) Received: by mail-oi0-f52.google.com with SMTP id h136so16424659oig.11 for ; Wed, 28 Jan 2015 00:20:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vFGUAhEHUofSZskVk7bx6TDp2d3L5c71sidfxL5zYcE=; b=BwMSXKI7jZlsQP1ONyx+6R2DRnIv1ogW7+0da3bZrsxI/cWzz37+Jtfe9u6KTFDadC N5NLPl2QmOxpfqrSdDzsj3yxs2rtPWv0pKQ18am1kM2UIL2/NYPAoUSBIUXxUz7rPR+B +vNWOn6q5V5le1QNxskey/dyj/JvP5EkJ7MFw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vFGUAhEHUofSZskVk7bx6TDp2d3L5c71sidfxL5zYcE=; b=VoPrz3N5oWoyXVwqf1/llSFnD0IJ2z+tDloH5QNW+kVkJpGqlbL0jVokVVgCEGkWzg QqjHV64ef5Xyv+VTnkws1YetoEtsWbyoh6Yux2BgQv7lL6dLjKkT4Hd7By3ImI2peudv eu9WWTpwfwiWA2hiEJP//ZzAjCKn9B/NdqLIoplF8vfSo1pftCt7c41OOWfs4+hwKvXc ZBeHJdA7FHS4oJmbA5lEovao+5Stq6TeeJHpdZU6J1kWfa+C7BYwO1FnoxBUF3pm38Oa FaJyD0T0QkDDGMUXuhFqZea7XynwXrFkU3IiIu/7ZtkoR8jBlPti8/Xq/GN7o2fwqYar CPpg== X-Gm-Message-State: ALoCoQmxJQVoMPdSHx+aSvwRumN7DqHN9SzzzoAnM6Pz28vYELCJLoLXorOCnc/eACjdr0Xa9scL MIME-Version: 1.0 X-Received: by 10.202.212.66 with SMTP id l63mr1147273oig.117.1422433232685; Wed, 28 Jan 2015 00:20:32 -0800 (PST) Received: by 10.60.84.171 with HTTP; Wed, 28 Jan 2015 00:20:32 -0800 (PST) Received: by 10.60.84.171 with HTTP; Wed, 28 Jan 2015 00:20:32 -0800 (PST) In-Reply-To: References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <015c01d0362f$1f6f6020$4001a8c0@gateway.2wire.net> <54C65580.2080407@ninebynine.org> <84E353AE-D96B-4211-99CB-D08AE17B1B1E@gbiv.com> Date: Wed, 28 Jan 2015 08:20:32 +0000 Message-ID: From: Dave Cridland To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a113cf2888d24ee050db20b5a Archived-At: Cc: Roy Fielding , Graham Klyne , apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-iri-comparison X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 08:20:34 -0000 --001a113cf2888d24ee050db20b5a Content-Type: text/plain; charset=UTF-8 Going all meta for a moment... On 27 Jan 2015 23:01, "Mark Nottingham" wrote: > I'd far prefer that appsawg were shut down and replaced by "mail" and "Web" WGs, the latter taking responsibility for URIs. They'd fight over format stuff, but that mirrors real life... Some of the most interesting discussions have arisen because the audience here is broad enough to observe the uses of URIs outside the traditional web space (ie, HTML). At the risk of sounding a little high and mighty, the web world has a lot to learn from the more conservative mail world about stability and compatibility - and the reverse is undoubtedly true as well. Still, things like DMARC show that the mail world can be screwed over by a few big players just as badly. Luckily those players have self censored themselves from discussions... In any case, unless this list were shockingly busy, I'd rather not hive off discussions into groupthink collectives. Dissension is a fine product of diversity. Dave. --001a113cf2888d24ee050db20b5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Going all meta for a moment...

On 27 Jan 2015 23:01, "Mark Nottingham" <mnot@mnot.net> wrote:
> I'd far prefer that appsawg were shut down and replaced by "m= ail" and "Web" WGs, the latter taking responsibility for URI= s. They'd fight over format stuff, but that mirrors real life...

Some of the most interesting discussions have arisen because= the audience here is broad enough to observe the uses of URIs outside the = traditional web space (ie, HTML). At the risk of sounding a little high and= mighty, the web world has a lot to learn from the more conservative mail w= orld about stability and compatibility - and the reverse is undoubtedly tru= e as well.

Still, things like DMARC show that the mail world can be scr= ewed over by a few big players just as badly. Luckily those players have se= lf censored themselves from discussions...

In any case, unless this list were shockingly busy, I'd = rather not hive off discussions into groupthink collectives. Dissension is = a fine product of diversity.

Dave.

--001a113cf2888d24ee050db20b5a-- From nobody Wed Jan 28 02:54:12 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BEC1A0E10 for ; Wed, 28 Jan 2015 02:54:07 -0800 (PST) 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, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trxRHWQ8u9AJ for ; Wed, 28 Jan 2015 02:54:04 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0755.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::755]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E9E1A0AFE for ; Wed, 28 Jan 2015 02:54:03 -0800 (PST) Received: from pc6 (81.151.167.59) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.1.65.19; Wed, 28 Jan 2015 10:53:39 +0000 Message-ID: <00fa01d03ae8$7cbf9b60$4001a8c0@gateway.2wire.net> From: t.petch To: "Roy T. Fielding" References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <015c01d0362f$1f6f6020$4001a8c0@gateway.2wire.net> <54C65580.2080407@ninebynine.org> <84E353AE-D96B-4211-99CB-D08AE17B1B1E@gbiv.com> Date: Wed, 28 Jan 2015 10:52:13 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB3PR05CA0020.eurprd05.prod.outlook.com (25.160.41.148) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:AMXPR07MB055; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:AMXPR07MB055; X-Forefront-PRVS: 047001DADA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(35754003)(13464003)(40100003)(44716002)(62236002)(81816999)(81686999)(116806002)(122386002)(33646002)(47776003)(19580405001)(62966003)(84392001)(61296003)(87976001)(1556002)(42186005)(50986999)(76176999)(230783001)(23746002)(50466002)(92566002)(93886004)(44736004)(50226001)(86362001)(229853001)(77156002)(15975445007)(1456003)(46102003)(66066001)(19580395003)(77096005)(14496001)(110136001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB055; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jan 2015 10:53:39.7559 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB055 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] IETF lists Re: draft-ietf-iri-comparison X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 10:54:07 -0000 ----- Original Message ----- From: "Roy T. Fielding" To: "David Singer" Cc: "Graham Klyne" ; Sent: Tuesday, January 27, 2015 2:05 AM ....Roy p.s. Am I the only one that finds it incredibly annoying that the APPS area uses this umbrella list for technical discussions about topics for which we still have the original working group mailing list active, archived, and populated with folks still capable of answering these questions? Ya know, "http://lists.w3.org/Archives/Public/uri/" "http://lists.w3.org/Archives/Public/public-iri/" Roy Over the years, almost all the lists I deal with have come under the umbrella of the IETF administration, giving them a consistent look and feel, an adequate set of features, an easy way of reporting when the archiving has collapsed (again), advance notice of many of the enforced changes to my way of working, etc. The result is less time spent on useless admin, more on real work. So separate list, eg arcmedia, fine, under some third party which does things differently or not at all .. thanks but no thanks. Tom Petch _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Wed Jan 28 03:20:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F73B1A1A5C for ; Wed, 28 Jan 2015 03:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsFd_6ruOX7K for ; Wed, 28 Jan 2015 03:19:56 -0800 (PST) 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 6C1B51A0AF7 for ; Wed, 28 Jan 2015 03:19:56 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LkOeR-1XfjCF3V8t-00cMRv; Wed, 28 Jan 2015 12:19:53 +0100 Message-ID: <54C8C5D2.4070602@gmx.de> Date: Wed, 28 Jan 2015 12:19:46 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "t.petch" , "Roy T. Fielding" References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <015c01d0362f$1f6f6020$4001a8c0@gateway.2wire.net> <54C65580.2080407@ninebynine.org> <84E353AE-D96B-4211-99CB-D08AE17B1B1E@gbiv.com> <00fa01d03ae8$7cbf9b60$4001a8c0@gateway.2wire.net> In-Reply-To: <00fa01d03ae8$7cbf9b60$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:2EiDq2+GYEJUsEP2jePzJVfgJkykHWCVfXlwOUpWnX9UzdftZRd yX4I1e97t9saNNgxq+yMJkyZLnbQwjO+J3dlWTsfTOxfyMYMKTKXKOn5DpSq3XgYax+qbLu idMt8LWjQqAbHp7oP4jSoklhmxfmRqm1aZopIcPCZN8nHHafYqFwQbuPe1hsoOi6DsaxMqP xFZPc2rrBPMjuIaFnMFFA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] IETF lists Re: draft-ietf-iri-comparison X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 11:20:09 -0000 On 2015-01-28 11:52, t.petch wrote: > ----- Original Message ----- > From: "Roy T. Fielding" > To: "David Singer" > Cc: "Graham Klyne" ; > Sent: Tuesday, January 27, 2015 2:05 AM > > ....Roy > > p.s. Am I the only one that finds it incredibly annoying that the > APPS area uses this umbrella list for technical discussions about > topics for which we still have the original working group mailing > list active, archived, and populated with folks still capable of > answering these questions? Ya know, > > "http://lists.w3.org/Archives/Public/uri/" > "http://lists.w3.org/Archives/Public/public-iri/" > > > Roy > > Over the years, almost all the lists I deal with have come under the > umbrella of the IETF administration, giving them a consistent look and > feel, an adequate set of features, an easy way of reporting when the > archiving has collapsed (again), advance notice of many of the enforced > changes to my way of working, etc. > > The result is less time spent on useless admin, more on real work. > > So separate list, eg arcmedia, fine, under some third party which does > things differently or not at all .. thanks but no thanks. > ... -1 The W3C lists work just fine, and having things (incl historical discussions) in a single place makes a lot of sense; that's why HTTPbis sticks with that as well. Best regards, Julian From nobody Wed Jan 28 04:32:57 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C60D1A1A2F for ; Wed, 28 Jan 2015 04:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zxu5a_6Z6Dck for ; Wed, 28 Jan 2015 04:32:47 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.228]) by ietfa.amsl.com (Postfix) with ESMTP id 225531A1B26 for ; Wed, 28 Jan 2015 04:32:46 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:5713] helo=rubix) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 1C/E2-22623-DE6D8C45; Wed, 28 Jan 2015 12:32:45 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 1B59B140742; Wed, 28 Jan 2015 07:32:46 -0500 (EST) Message-ID: <54C8D6EC.4030306@intertwingly.net> Date: Wed, 28 Jan 2015 07:32:44 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Mark Nottingham References: <54AEB660.1020701@intertwingly.net> <54C84872.5040902@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 12:32:51 -0000 On 01/28/2015 12:36 AM, Mark Nottingham wrote: > >> On 28 Jan 2015, at 1:24 pm, Sam Ruby wrote: >> >> On 1/27/15 8:53 PM, Mark Nottingham wrote: >>> Hi Sam, >>> >>>> On 9 Jan 2015, at 3:54 am, Sam Ruby wrote: >>>> >>>> Mark cares about valid URIs. He's certainly not alone in that. What he has done is express his interests not merely in high level prose, but in concrete, executable form. Given that he has done that, I can pose some interesting questions. For example, if you consider the process of canonicalizing a href value on an element and stringifying the result, an implementation like Chrome will produce something that will be sent across the wire. I've captured the results here: >>>> >>>> https://raw.githubusercontent.com/webspecs/url/develop/evaluate/useragent-results/chrome >>>> >>>> Given that data and Mark's script, I can produce a list of outputs that Mark doesn't consider valid: >>> >>> [...] >>> >>>> With this data, we can have a discussion as to whether Mark's script should be updated, or Chrome should change, or some spec should change. >>> >>> What I was hoping for was an update of the "valid URI" filter to take this into account at . >>> >>> E.g., that list currently includes test case 63, "https:/example.com/", which is valid according to the generic syntax in RFC3986, but not when you consider the scheme-specific constraints for HTTPS in RFC7230. >>> >>> By filtering out these cases, we can see the places we potentially need to pay attention to in the RFCs. >>> >>> Is that possible? >> >> Since that code runs filters on the browser, it would be easiest for me integrate code written in JavaScript. >> >> Can you review the generated JavaScript? >> >> https://url.spec.whatwg.org/reference-implementation/uri-validate.js >> https://url.spec.whatwg.org/reference-implementation/uri-validate.html > > It looks like a reasonable transcription. I do notice you copied my error: > > return new RegExp("^" + known[scheme] + "(#|$)").test(string) Not a copy: it's actually different. My version checks for a match on the regular expression followed by either a hash mark or the end of the string. > I think it should just be: > > return new RegExp("^" + known[scheme] + "$").test(string) > > ... which brings about another interesting observation -- only http and https define fragments in their syntax; the other schemes do not. I can make that change. >> Also, I would like to discuss where this code should live: >> >> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13635.html > > I want to keep it going in Python, so I'll probably create a separate repo at some point; is it bothersome to just keep the JS in your repo? I'm not proposing changing it from Python. What I have is a script that does the conversion: https://gist.github.com/rubys/b9ccaf304f06cf3e2e88 > If bugs are found in the regex themselves, I'll make sure to notify you (and would appreciate the same). I'd suggest putting them both in the same repository. In any case, later today I'll update my filter to replace the validation check with yours. > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ - Sam Ruby From nobody Wed Jan 28 06:43:07 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618E31A00B6 for ; Wed, 28 Jan 2015 06:43:04 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UACOMrHfgbH2 for ; Wed, 28 Jan 2015 06:43:03 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 3FBC31A0084 for ; Wed, 28 Jan 2015 06:43:03 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2508522E262 for ; Wed, 28 Jan 2015 09:43:01 -0500 (EST) Message-ID: <54C8F576.1040403@seantek.com> Date: Wed, 28 Jan 2015 06:43:02 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <015c01d0362f$1f6f6020$4001a8c0@gateway.2wire.net> <54C65580.2080407@ninebynine.org> <84E353AE-D96B-4211-99CB-D08AE17B1B1E@gbiv.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [apps-discuss] draft-ietf-iri-comparison X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 14:43:04 -0000 On 1/28/2015 12:20 AM, Dave Cridland wrote: > Some of the most interesting discussions have arisen because the > audience here is broad enough to observe the uses of URIs outside the > traditional web space (ie, HTML). +1 Sean From nobody Wed Jan 28 11:24:40 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55C11A0077; Wed, 28 Jan 2015 11:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbFKPw3IwVHl; Wed, 28 Jan 2015 11:24:30 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1701A0072; Wed, 28 Jan 2015 11:24:30 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id k14so22493257wgh.8; Wed, 28 Jan 2015 11:24:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qLZFtoF5cVt6+ZzxYCeEezLlaUEGAnPhhgdRj5HoWa4=; b=eBSgZ8d7iObKcejv1Cwhtg87ROqoFv1jXZMOgywDqJnrouOqrD0OC6xjAVJuUQHwu9 Y2fsFRS/jwL4WIWaLd9gTcyot4XsQrzYCGeRAf7wIk0E4iITCqv8K5bTNYOoL+T+WSX1 SqqRvv+h/2Bin3RR8AnxbvHCu8Q+52v2Hat/7KBdKOFZmNT9h4LgcKlAdlZXaYz+JdPn P6JhP8l9egN85orRR4ezOpzg3bZBTCyNz86C3A8w/M1U0CidkdIuuduu6tjmDu4vwBVm 4X6D0qOvvYlFP1qIaNDIONvNOUJ8fPcR0BC68lQd7ulMTa2GbDDwd11pco2TUk1+qNHj 3vPA== MIME-Version: 1.0 X-Received: by 10.194.78.97 with SMTP id a1mr10600846wjx.104.1422473068741; Wed, 28 Jan 2015 11:24:28 -0800 (PST) Received: by 10.194.236.106 with HTTP; Wed, 28 Jan 2015 11:24:28 -0800 (PST) In-Reply-To: References: Date: Wed, 28 Jan 2015 20:24:28 +0100 Message-ID: From: Daniel Migault To: saag@ietf.org, apps-discuss@ietf.org, ops-area@ietf.org Content-Type: multipart/alternative; boundary=047d7bfcf7d0f70bf1050dbb5141 Archived-At: Cc: Time Zone Data Distribution Service Subject: [apps-discuss] Fwd: WGLC for draft-ietf-tzdist-service-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 19:24:32 -0000 --047d7bfcf7d0f70bf1050dbb5141 Content-Type: text/plain; charset=UTF-8 Dear Friends and Colleagues, Our document describing Time Zone Data Distribution Service [1] is close to be finalized and we would like to proceed to cross area review. We would greatly appreciate to get review by February 11. Best Regards, Daniel and Eliot [1] http://tools.ietf.org/html/draft-ietf-tzdist-service-05 -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7bfcf7d0f70bf1050dbb5141 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Friends and Colleagues,

<= /div>
Our document describing Time Zone Data Distribution Service [1] is c= lose to be finalized and we would like to proceed to cross area review.
We would greatly appreciate to get review by February 11.<= br>
Best Regards,

Daniel and Eliot

[1] http://tools.ietf.org/html/draft-ietf-tzdist-service-05
=

--
Daniel Migault
Orang= e Labs -- Security
+33 6 70 72 69 58
--047d7bfcf7d0f70bf1050dbb5141-- From nobody Wed Jan 28 12:38:31 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560D31AC3A0 for ; Mon, 26 Jan 2015 08:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUIqxuHuobRu for ; Mon, 26 Jan 2015 08:27:39 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76411AC3AE for ; Mon, 26 Jan 2015 08:27:39 -0800 (PST) Received: from Philemon (173-164-94-161-Oregon.hfc.comcastbusiness.net [173.164.94.161]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 235E42CA19; Mon, 26 Jan 2015 08:27:38 -0800 (PST) From: "Jim Schaad" To: "'Bert Greevenbosch'" References: <042b01d031fe$0c7edfc0$257c9f40$@augustcellars.com> <54BDFBF3.9010101@bertgreevenbosch.nl> <031201d035ab$5077e9a0$f167bce0$@augustcellars.com> <54C61737.50203@bertgreevenbosch.nl> In-Reply-To: <54C61737.50203@bertgreevenbosch.nl> Date: Mon, 26 Jan 2015 08:26:53 -0800 Message-ID: <08ad01d03984$e5e9b770$b1bd2650$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08AE_01D03941.D7C93690" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQIkoVtF/wxHHQfQmcTr3uIMbS3ufgHaP14+AafTl2IBhWyhwwKGbqpnm+1XU8A= Archived-At: X-Mailman-Approved-At: Wed, 28 Jan 2015 12:38:28 -0800 Cc: apps-discuss@ietf.org, draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org Subject: Re: [apps-discuss] ??: New round of comments on draft-greevenbosch-appsawg-cbor-cddl-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jan 2015 16:27:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_08AE_01D03941.D7C93690 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Bert Greevenbosch [mailto:ietf@bertgreevenbosch.nl]=20 Sent: Monday, January 26, 2015 2:30 AM To: Jim Schaad Cc: draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org; = apps-discuss@ietf.org Subject: Re: ??: New round of comments on = draft-greevenbosch-appsawg-cbor-cddl-04 =20 Hi Jim, Thank you for your feedback. Please find my response inline, preceded = with "[BG]". Best regards, Bert On 21-01-15 19:51, Jim Schaad wrote: =20 =20 From: Bert Greevenbosch [mailto:ietf@bertgreevenbosch.nl]=20 Sent: Monday, January 19, 2015 10:56 PM To: Jim Schaad Cc: draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org Subject: Re: ??: New round of comments on = draft-greevenbosch-appsawg-cbor-cddl-04 =20 Hi Jim, Thank you for your comments. They are very helpful. Please find my = answers below. B.T.W.,would you mind including the apps-discuss mailing list in this = discussion? It may be good for the chairs and others to see activity on = this draft. 1. You have a length restriction on float, do you see a need for begin = able to do length restrictions on int, tstr and bstr? I don't know if a = restriction based on number of bytes or based on a value range would be = better. It make sense to use the () syntax to specify a length = restriction since you are already using it for float.=20 I started out with such notation, e.g. "int(16)" for a 16-bit integer. = However, there is a difference between ints and floats: for any integer = number, it is easy to find out how much bits are needed. Hence we could = allow some freedom in choosing the number of bits on a per-number basis = on the encoder side. This was a comment from Carsten, and we = subsequently removed the "int(16)" notation. For floats, this is harder, as the number of bits does not depend on the = value of the variable, but on the precision with which we want to = represent that variable. For example, the value 1/3 can be represented = using both a float(16) and a float(32), but the latter representation = would be closer to the real value than the former. [JLS] What I was looking for was a size limitation which might be = helpful. That is the integer that goes here is limited to 16 bits. [BG] Ah yes, that may be helpful. It would mean a slightly different = meaning of "(16)" in "float(16)" and "uint(16)", but I could easily get = used to that. 3. I will reiterate the request for some type of alternate syntax for = types - i.e. TypeA or TypeB I like your earlier proposed notation: price: uint | float(16) and think we can implement this in the next version of the draft. 2. You have removed the union/choice structure from the document. I = highly recommend that this be added back in some form.=20 I think we can use the same solution for (3) as well, as follows: *smallStructure1 { dish: tstr; recipe: tstr; } *smallStructure2 { drink: tstr; price: int; } *BigStructure : { subStructure: smallStructure1 | smallStructure2;=20 } Interesting would be how to distinguish between smallStructure1 and = smallStructure2. Especially in the following case: *smallStructure1 { dish: tstr; recipe: tstr; } *smallStructure2 { drink: tstr; ingredients: tstr; } *BigStructure : { subStructure: smallStructure1 | smallStructure2;=20 } The last may need some more consideration. [JLS] while one could use tags =E2=80=93 is there a reason not to go = back to the world of using an int field to discriminate? [BG] Any way of signalling to the application which of the two = structures is meant is indeed required. This could be through an integer = that contains a field-id, or in other ways e.g. through the semantics of = the rest of the data structure. What I mean is, that it may be obvious = to the application which structure is meant by inspecting earlier = fields. For automatic parsing of such structure, this would be much harder = though. A complex parser could perform "best effort parsing", whereas a = simpler parser could consider ignoring verification of variables with = alternative structures as datatype. (Simple datatypes should be easy to = handle for simple parsers too.) 4. A structure can be folded at the top level into a structure by not = using the '*' operator on a type. Do you want to be able to do the same = type of thing for a map? Not sure about this. Do you have an example? CDDL maps need a CBOR map encoding. A structure, however, does not = necessarily require what I call an "encompassing array". Thus the = encompassing array is signalled by the asterisk, because there is a = choice. [JLS] If one looks at the COSE document that I am working on. One can = define three maps, one each for an EC key, for an RSA key and for a = secret key. One can then define a base key with common fields that are = not algorithm specific. One could then define single map that included = each of the other items into it by reference rather than as sub items. =20 COSE_KEY : map { base_key; rsa_key; ec_key; secret_key } [BG] OK, I see, so you want to define a single base_key, and then only = one of rsa_key, ec_key, secret_key. Something like: map { "base_key": bstr; choice { "rsa_key": bstr; "ec_key" : bstr; "secret_key": bstr; } } (The choice construct doesn't exist in CDDL, I am just thinking here.) With the issue of identifiers above in mind, one could think of = something like a simple switch statement, which only takes primitive = types as input. For example: map { "base_key": bstr; "key_type": uint; switch("key_type") { 0: "rsa_key": bstr; 1: "ec_key": bstr; 2: "secret_key": bstr; } } =20 [JLS} No I was not going to have a switch statement =E2=80=93 I was just = having all of the fields be part of the map. Using field names is = sufficient for distinguishing which set of fields I was looking for. Maybe something to about further. Best regards, Bert 5. I don't understand the last example in section 4.5.1 - You are = combining a structure and a map together into a single item. Would the = syntax "ToString: map(., tstr)" be a better example? This is a map in = this case and that is what you are talking about=20 Yes, indeed this would be better: toString: map( ., tstr ); (Notice the lower case "t" at the beginning, this is a convention I use = for variable names, although it is not mandatory.) Best regards, Bert On 19-01-15 01:59, Sunruinan wrote: Hi Bert=EF=BC=8C I received such email from Jim. Since I can't find it = in appsawg email list, I think this is a system automatic email, is it = right? Can I find some web pages about these comments? As the title of = this email, it means New round of comments. Are these comments has some = relationship with the previous round comments? Thank you in advance for = your reply! Best Regards! Ruinan = -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91 = =E4=BB=B6=E4=BA=BA: Jim Schaad [mailto:ietf@augustcellars.com] =E5=8F=91 = =E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B41=E6=9C=8817=E6=97=A5 10:34 = =E6=94=B6 =E4=BB=B6=E4=BA=BA: = draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org =E4=B8=BB=E9=A2=98: = New round of comments on draft-greevenbosch-appsawg-cbor-cddl-04 Here = comes a new round of comments on the draft. I have tried not hit the = same points again. 1. You have a length restriction on float, do you see = a need for begin able to do length restrictions on int, tstr and bstr? I = don't know if a restriction based on number of bytes or based on a value = range would be better. It make sense to use the () syntax to specify a = length restriction since you are already using it for float. 2. You have = removed the union/choice structure from the document. I highly recommend = that this be added back in some form. 3. I will reiterate the request = for some type of alternate syntax for types - i.e. TypeA or TypeB 4. A = structure can be folded at the top level into a structure by not using = the '*' operator on a type. Do you want to be able to do the same type = of thing for a map? 5. I don't understand the last example in section = 4.5.1 - You are combining a structure and a map together into a single = item. Would the syntax "ToString: map(., tstr)" be a better example? = This is a map in this case and that is what you are talking about Jim .=20 -- Bert Greevenbosch ietf@bertgreevenbosch.nl=20 Best regards, Bert On 20-01-15 07:09, Sunruinan wrote: Hi Jim, Thank you for your comments! Since Bert is original editor of this draft and more familiar with = previous discussion, I forward your comments to his new email address. He can give some answers. =20 Best Regards! Ruinan Sun Huawei =20 -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Jim Schaad [mailto:ietf@augustcellars.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B41=E6=9C=8817=E6=97=A5 = 10:34 =E6=94=B6=E4=BB=B6=E4=BA=BA: = draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org =E4=B8=BB=E9=A2=98: New round of comments on = draft-greevenbosch-appsawg-cbor-cddl-04 =20 Here comes a new round of comments on the draft. I have tried not hit = the same points again. =20 1. You have a length restriction on float, do you see a need for begin = able to do length restrictions on int, tstr and bstr? I don't know if a = restriction based on number of bytes or based on a value range would be = better. It make sense to use the () syntax to specify a length = restriction since you are already using it for float. =20 2. You have removed the union/choice structure from the document. I = highly recommend that this be added back in some form. =20 3. I will reiterate the request for some type of alternate syntax for = types - i.e. TypeA or TypeB =20 4. A structure can be folded at the top level into a structure by not = using the '*' operator on a type. Do you want to be able to do the same type = of thing for a map?=20 =20 5. I don't understand the last example in section 4.5.1 - You are = combining a structure and a map together into a single item. Would the = syntax "ToString: map(., tstr)" be a better example? This is a map in this = case and that is what you are talking about =20 =20 Jim . =20 =20 =20 ------=_NextPart_000_08AE_01D03941.D7C93690 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Bert Greevenbosch [mailto:ietf@bertgreevenbosch.nl] =
Sent: Monday, January 26, 2015 2:30 AM
To: Jim = Schaad
Cc: = draft-greevenbosch-appsawg-cbor-cddl@tools.ietf.org; = apps-discuss@ietf.org
Subject: Re: ??: New round of comments = on = draft-greevenbosch-appsawg-cbor-cddl-04

=

 

Hi Jim,

Thank you for your = feedback. Please find my response inline, preceded with = "[BG]".

Best = regards,
Bert

On = 21-01-15 19:51, Jim Schaad wrote:

 

 

From: Bert Greevenbosch [mailto:ietf@bertgreevenbosch.nl<= /a>]
Sent: Monday, January 19, 2015 10:56 PM
To: = Jim Schaad
Cc: draft= -greevenbosch-appsawg-cbor-cddl@tools.ietf.org
Subject: = Re: ??: New round of comments on = draft-greevenbosch-appsawg-cbor-cddl-04

=

 

Hi Jim,

Thank you for your = comments. They are very helpful. Please find my answers = below.

B.T.W.,would you mind including the apps-discuss mailing = list in this discussion? It may be good for the chairs and others to see = activity on this draft.

1. = You have a length restriction on float, do you see a need for begin able = to do length restrictions on int, tstr and bstr? I don't know if a = restriction based on number of bytes or based on a value range would be = better. It make sense to use the () syntax to specify a length = restriction since you are already using it for float.

I = started out with such notation, e.g. "int(16)" for a 16-bit = integer. However, there is a difference between ints and floats: for any = integer number, it is easy to find out how much bits are needed. Hence = we could allow some freedom in choosing the number of bits on a = per-number basis on the encoder side. This was a comment from Carsten, = and we subsequently removed the "int(16)" notation.

For = floats, this is harder, as the number of bits does not depend on the = value of the variable, but on the precision with which we want to = represent that variable. For example, the value 1/3 can be represented = using both a float(16) and a float(32), but the latter representation = would be closer to the real value than the former.

[JLS] What I was looking = for was a size limitation which might be helpful.  That is the = integer that goes here is limited to 16 = bits.

[BG] Ah yes, that may be helpful. It would mean a = slightly different meaning of "(16)" in "float(16)" = and "uint(16)", but I could easily get used to = that.


3. I will reiterate the request for some type = of alternate syntax for types - i.e. TypeA or TypeB

I like = your earlier proposed notation:

price: uint | float(16)

and think we can implement this in the next version of = the draft.

2. You have removed the union/choice structure from = the document. I highly recommend that this be added back in some form. =

I think we can use the same solution for (3) as well, as = follows:

*smallStructure1 = {
   dish: tstr;
   recipe: = tstr;
}

*smallStructure2 {
   drink: = tstr;
   price: int;
}

*BigStructure : = {
   subStructure: smallStructure1 | smallStructure2; =
}

Interesting would be how to = distinguish between smallStructure1 and smallStructure2. Especially in = the following case:

*smallStructure1 = {
   dish: tstr;
   recipe: = tstr;
}

*smallStructure2 {
   drink: = tstr;
   ingredients: tstr;
}

*BigStructure : = {
   subStructure: smallStructure1 | smallStructure2; =
}

The last may need some more = consideration.

[JLS] while one could use tags =E2=80=93 is there a reason not to go = back to the world of using an int field to = discriminate?

[BG] = Any way of signalling to the application which of the two structures is = meant is indeed required. This could be through an integer that contains = a field-id, or in other ways e.g. through the semantics of the rest of = the data structure. What I mean is, that it may be obvious to the = application which structure is meant by inspecting earlier = fields.

For automatic parsing of such structure, this would be = much harder though. A complex parser could perform "best effort = parsing", whereas a simpler parser could consider ignoring = verification of variables with alternative structures as datatype. = (Simple datatypes should be easy to handle for simple parsers = too.)



4. A structure can be folded at = the top level into a structure by not using the '*' operator on a type. = Do you want to be able to do the same type of thing for a = map?

Not sure about this. Do you have an example?

CDDL = maps need a CBOR map encoding. A structure, however, does not = necessarily require what I call an "encompassing array". Thus = the encompassing array is signalled by the asterisk, because there is a = choice.

[JLS]  If one looks at the COSE document that I am working on. =  One can define three maps, one each for an EC key, for an RSA key = and for a secret key.  One can then define a base key with common = fields that are not algorithm specific.  One could then = define  single map that included each of the other items into it by = reference rather than as sub items.

 

COSE_KEY : map { base_key; rsa_key; ec_key; secret_key = }

[BG] OK, I see, = so you want to define a single base_key, and then only one of rsa_key, = ec_key, secret_key. Something like:

map {
  = "base_key": bstr;
  choice {
    = "rsa_key": bstr;
    "ec_key" : = bstr;
    "secret_key": bstr;
  = }
}

(The choice construct doesn't exist in CDDL, I am just = thinking here.)

With the issue of identifiers above in mind, one = could think of something like a simple switch statement, which only = takes primitive types as input. For example:

map {
  = "base_key": bstr;
  "key_type": = uint;
  switch("key_type") {
    0: = "rsa_key": bstr;
    1: "ec_key": = bstr;
    2: "secret_key": bstr;
  = }
}

 

[JLS} No I was not going to have a switch statement =E2=80=93 I was = just having all of the fields be part of the map.=C2=A0 Using field = names is sufficient for distinguishing which set of fields I was looking = for.



Maybe something = to about further.

Best = regards,
Bert




5. I don't understand the = last example in section 4.5.1 - You are combining a structure and a map = together into a single item. Would the syntax "ToString: map(., = tstr)" be a better example? This is a map in this case and that is = what you are talking about

Yes, indeed this would be = better:

toString: map( ., tstr = );

(Notice the lower case "t" at = the beginning, this is a convention I use for variable names, although = it is not mandatory.)

Best = regards,
Bert


On = 19-01-15 01:59, Sunruinan wrote:

Hi = Bert=EF=BC=8C I = received such email from Jim. Since I can't find it in appsawg email = list, I think this is a system automatic email, is it right? Can I find = some web pages about these comments? As the title of this email, it = means New round of comments. Are these comments has some relationship = with the previous round comments? Thank you in advance for your reply! = Best Regards! Ruinan -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB= =B6----- =E5=8F=91 = =E4=BB=B6=E4=BA=BA: Jim Schaad [mailto:ietf@augustcellars.com]= =E5=8F=91 = =E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B41=E6=9C=8817=E6=97=A5 10:34 =E6=94=B6 =E4=BB=B6=E4=BA=BA: draft= -greevenbosch-appsawg-cbor-cddl@tools.ietf.org =E4=B8=BB=E9=A2=98: New round of = comments on draft-greevenbosch-appsawg-cbor-cddl-04 Here comes a new = round of comments on the draft. I have tried not hit the same points = again. 1. You have a length restriction on float, do you see a need for = begin able to do length restrictions on int, tstr and bstr? I don't know = if a restriction based on number of bytes or based on a value range = would be better. It make sense to use the () syntax to specify a length = restriction since you are already using it for float. 2. You have = removed the union/choice structure from the document. I highly recommend = that this be added back in some form. 3. I will reiterate the request = for some type of alternate syntax for types - i.e. TypeA or TypeB 4. A = structure can be folded at the top level into a structure by not using = the '*' operator on a type. Do you want to be able to do the same type = of thing for a map? 5. I don't understand the last example in section = 4.5.1 - You are combining a structure and a map together into a single = item. Would the syntax "ToString: map(., tstr)" be a better = example? This is a map in this case and that is what you are talking = about Jim .


-- Bert = Greevenbosch ietf@bertgreevenbosch.nl =



Best = regards,
Bert


On = 20-01-15 07:09, Sunruinan wrote:

Hi =
Jim,
Thank you for your =
comments!
Since Bert is original editor of this =
draft and more familiar with previous discussion, I forward your =
comments to his new email address.
He can give some =
answers.
 
Best =
Regards!
Ruinan =
Sun
Huawei
 
-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6=
-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: Jim =
Schaad [mailto:ietf@augustcellars.com]=
 
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=
: 2015=E5=B9=B41=E6=9C=8817=E6=97=A5 =
10:34
=E6=94=B6=E4=BB=B6=E4=BA=BA: draft=
-greevenbosch-appsawg-cbor-cddl@tools.ietf.org
<=
span style=3D'font-family:"MS Gothic"'>=E4=B8=BB=E9=A2=98: New round of comments on =
draft-greevenbosch-appsawg-cbor-cddl-04
 <=
/o:p>
Here comes a new round of comments on the draft.  I =
have tried not hit the same points =
again.
 
1. You have a =
length restriction on float, do you see a need for begin able to do =
length restrictions on int, tstr and bstr?  I don't know if a =
restriction based on number of bytes or based on a value range would be =
better.  It make sense to use the () syntax to specify a length =
restriction since you are already using it for =
float.
 
2. You have =
removed the union/choice structure from the document.  I highly =
recommend that this be added back in some =
form.
 
3. I will =
reiterate the request for some type of alternate syntax for =
types
- i.e. TypeA or =
TypeB
 
4. A structure =
can be folded at the top level into a structure by not =
using
the '*' operator on a type.   Do =
you want to be able to do the same type of
thing =
for a map? 
 
5. I don't =
understand the last example in section 4.5.1 - You are combining a =
structure and a map together into a single item.  Would the =
syntax
"ToString: map(., tstr)" be a =
better example?  This is a map in this case and that is what you =
are talking =
about
 
 <=
/pre>
Jim
.
 

 

 

------=_NextPart_000_08AE_01D03941.D7C93690-- From nobody Wed Jan 28 13:05:32 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140131A039B for ; Wed, 28 Jan 2015 13:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxBLEZC7od9g for ; Wed, 28 Jan 2015 13:05:27 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCD91A005C for ; Wed, 28 Jan 2015 13:05:18 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 5187720082329; Wed, 28 Jan 2015 13:05:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=9WY1pjJI7A70wc gx7GNeJQaHmTs=; b=zAFXPjZlZ+xQhzT/PsltTFZ604T7muC+I4rJuKnBJHIOxZ ZAf+lgw41cKLSO6xkptVqUG9+Bzt9w6ZeozuD5vRSAyIGhrzIZETTiAZL2o0AIgp Erw9O0mSPn7AqYqMpGv+yyp1FgLlnY+audKph/cWN3RYFN1doAGjgvHED8adU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id E651320046912; Wed, 28 Jan 2015 13:05:17 -0800 (PST) Date: Wed, 28 Jan 2015 15:05:17 -0600 From: Nico Williams To: Mark Nottingham Message-ID: <20150128210512.GE3110@localhost> References: <54AEB660.1020701@intertwingly.net> <54C84872.5040902@intertwingly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 21:05:28 -0000 On Wed, Jan 28, 2015 at 04:36:20PM +1100, Mark Nottingham wrote: > ... which brings about another interesting observation -- only http > and https define fragments in their syntax; the other schemes do not. But STD66 describes fragments. Nico -- From nobody Wed Jan 28 13:15:10 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F631A1AA7 for ; Wed, 28 Jan 2015 13:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5Vyfp4xQGDy for ; Wed, 28 Jan 2015 13:15:04 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 C7BDD1A1AB1 for ; Wed, 28 Jan 2015 13:14:37 -0800 (PST) Received: from [192.168.2.175] ([93.217.85.143]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MCLx3-1YP8W139fd-0096LC; Wed, 28 Jan 2015 22:14:32 +0100 Message-ID: <54C95132.2060402@gmx.de> Date: Wed, 28 Jan 2015 22:14:26 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Mark Nottingham , Sam Ruby References: <54AEB660.1020701@intertwingly.net> <54C84872.5040902@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:jjRK17Y1vfVO8u+UoCsCNbYAhHxuGPQM7ajlOnpnYtLPF0lFOqU s5Po6HuiiADu2zKM3bQtbWWEQRSCZexsfQ0yhFaZAP+8aQEdnz/PDaZKb7glt54fC+WPOwu RweP93uPQV7rZYlUpFHlRHAkn7Upf7zXVtp13YqcNq7x5bXkqfdBLn7nFAVQ90gzyK75YiG eubLZy3r+1WWZVH4yjTEA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 21:15:07 -0000 On 2015-01-28 06:36, Mark Nottingham wrote: > >> On 28 Jan 2015, at 1:24 pm, Sam Ruby wrote: >> >> On 1/27/15 8:53 PM, Mark Nottingham wrote: >>> Hi Sam, >>> >>>> On 9 Jan 2015, at 3:54 am, Sam Ruby wrote: >>>> >>>> Mark cares about valid URIs. He's certainly not alone in that. What he has done is express his interests not merely in high level prose, but in concrete, executable form. Given that he has done that, I can pose some interesting questions. For example, if you consider the process of canonicalizing a href value on an element and stringifying the result, an implementation like Chrome will produce something that will be sent across the wire. I've captured the results here: >>>> >>>> https://raw.githubusercontent.com/webspecs/url/develop/evaluate/useragent-results/chrome >>>> >>>> Given that data and Mark's script, I can produce a list of outputs that Mark doesn't consider valid: >>> >>> [...] >>> >>>> With this data, we can have a discussion as to whether Mark's script should be updated, or Chrome should change, or some spec should change. >>> >>> What I was hoping for was an update of the "valid URI" filter to take this into account at . >>> >>> E.g., that list currently includes test case 63, "https:/example.com/", which is valid according to the generic syntax in RFC3986, but not when you consider the scheme-specific constraints for HTTPS in RFC7230. >>> >>> By filtering out these cases, we can see the places we potentially need to pay attention to in the RFCs. >>> >>> Is that possible? >> >> Since that code runs filters on the browser, it would be easiest for me integrate code written in JavaScript. >> >> Can you review the generated JavaScript? >> >> https://url.spec.whatwg.org/reference-implementation/uri-validate.js >> https://url.spec.whatwg.org/reference-implementation/uri-validate.html > > It looks like a reasonable transcription. I do notice you copied my error: > > return new RegExp("^" + known[scheme] + "(#|$)").test(string) > > I think it should just be: > > return new RegExp("^" + known[scheme] + "$").test(string) > > ... which brings about another interesting observation -- only http and https define fragments in their syntax; the other schemes do not. > ... It's because you asked for that in , and apparently were successful in convincing Roy. (I still disagree with this outcome :-) Best regards, Julian From nobody Wed Jan 28 13:40:31 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684FC1A1A00 for ; Wed, 28 Jan 2015 13:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lfjxjZahNst for ; Wed, 28 Jan 2015 13:40:28 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 845B01A038B for ; Wed, 28 Jan 2015 13:40:28 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 29A276B0070; Wed, 28 Jan 2015 13:40:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=kC4kUrPRxVG61wKGgJ0e5g+oWu0=; b=ffAde0ZO9Z8RZM+VtOvVKNrRMKbq 5ssrenZ9aJlSz7HyRu2skIXyNGVgovi3wvduqbdPOFQQuOIHtR+XNkOMe48dT2Y7 RiDWiuFXzVTfS+lhNgmbYZ1m71zsKAl6OdgBWrN65c4O8N1th105RQjqtWtH2zrq dbmnUAa/kibDbMo= Received: from [192.168.1.12] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id F2C0A6B0059; Wed, 28 Jan 2015 13:40:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <54C95132.2060402@gmx.de> Date: Wed, 28 Jan 2015 13:40:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <154ABFBB-AB8C-447A-89A3-D1746EFBF1C6@gbiv.com> References: <54AEB660.1020701@intertwingly.net> <54C84872.5040902@intertwingly.net> <54C95132.2060402@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1283) Archived-At: Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 21:40:29 -0000 On Jan 28, 2015, at 1:14 PM, Julian Reschke wrote: > On 2015-01-28 06:36, Mark Nottingham wrote: >> ... which brings about another interesting observation -- only http = and https define fragments in their syntax; the other schemes do not. >> ... >=20 > It's because you asked for that in = , = and apparently were successful in convincing Roy. It is a very very very old debate regarding whether the fragment is part of a URI or something attached to the end of a URI, but that was = resolved in RFC3986 (since the only thing that really matters here is that a = fragment is going to be parsed as such regardless of the scheme). HTTP was merely updated to reflect what STD66 calls a URI. ....Roy= From nobody Wed Jan 28 13:51:11 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741751A037F for ; Wed, 28 Jan 2015 13:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iU0dnLAqIYoM for ; Wed, 28 Jan 2015 13:51:08 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.225]) by ietfa.amsl.com (Postfix) with ESMTP id DE8C41A012D for ; Wed, 28 Jan 2015 13:51:07 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:23839] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 74/A7-26647-AC959C45; Wed, 28 Jan 2015 21:51:07 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id AF83A140AF3; Wed, 28 Jan 2015 16:51:07 -0500 (EST) Message-ID: <54C959C9.2090002@intertwingly.net> Date: Wed, 28 Jan 2015 16:51:05 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Roy T. Fielding" , Julian Reschke References: <54AEB660.1020701@intertwingly.net> <54C84872.5040902@intertwingly.net> <54C95132.2060402@gmx.de> <154ABFBB-AB8C-447A-89A3-D1746EFBF1C6@gbiv.com> In-Reply-To: <154ABFBB-AB8C-447A-89A3-D1746EFBF1C6@gbiv.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 21:51:09 -0000 On 01/28/2015 04:40 PM, Roy T. Fielding wrote: > On Jan 28, 2015, at 1:14 PM, Julian Reschke wrote: >> On 2015-01-28 06:36, Mark Nottingham wrote: >>> ... which brings about another interesting observation -- only http and https define fragments in their syntax; the other schemes do not. >>> ... >> >> It's because you asked for that in , and apparently were successful in convincing Roy. > > It is a very very very old debate regarding whether the fragment is part > of a URI or something attached to the end of a URI, but that was resolved > in RFC3986 (since the only thing that really matters here is that a fragment > is going to be parsed as such regardless of the scheme). > > HTTP was merely updated to reflect what STD66 calls a URI. Based on this discussion, I am gathering that the correct way to validate a URI with a known scheme is as follows: return new RegExp("^" + known[scheme] + "($|#" + fragment + ")").test(string) Anybody care to confirm or deny? The full script is available here: https://url.spec.whatwg.org/reference-implementation/uri-validate.js The function in question is at the bottom of this script. > ....Roy - Sam Ruby From nobody Wed Jan 28 13:56:34 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EE21A039B for ; Wed, 28 Jan 2015 13:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fM2ysyZCyEha for ; Wed, 28 Jan 2015 13:56:25 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 1C2421A0398 for ; Wed, 28 Jan 2015 13:56:25 -0800 (PST) Received: from [192.168.2.175] ([93.217.85.143]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LrvBu-1XY8bT2INa-013gBY; Wed, 28 Jan 2015 22:56:13 +0100 Message-ID: <54C95AF7.6030703@gmx.de> Date: Wed, 28 Jan 2015 22:56:07 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Roy T. Fielding" References: <54AEB660.1020701@intertwingly.net> <54C84872.5040902@intertwingly.net> <54C95132.2060402@gmx.de> <154ABFBB-AB8C-447A-89A3-D1746EFBF1C6@gbiv.com> In-Reply-To: <154ABFBB-AB8C-447A-89A3-D1746EFBF1C6@gbiv.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:NofQFp2asuFJnIelDLRbNtmXNDfbcUuu/L9+YKlo5c3lDTvD5FH BLoXbz+bX1AY7MfHL2gLx28TixCPB/ACyV8XU/qvdgfp2L1P7I46D4HAEmaTv4aE32T/TpZ 0AacWbUGLKFnrEwamusedGYxb1QbbKYjJLOr2/92HbTE0DmFWN+DK15QuxMVKcB3IeJcDRb /EXh/qp4hgrHBL5T2TSvg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 21:56:27 -0000 On 2015-01-28 22:40, Roy T. Fielding wrote: > On Jan 28, 2015, at 1:14 PM, Julian Reschke wrote: >> On 2015-01-28 06:36, Mark Nottingham wrote: >>> ... which brings about another interesting observation -- only http and https define fragments in their syntax; the other schemes do not. >>> ... >> >> It's because you asked for that in , and apparently were successful in convincing Roy. > > It is a very very very old debate regarding whether the fragment is part > of a URI or something attached to the end of a URI, but that was resolved > in RFC3986 (since the only thing that really matters here is that a fragment > is going to be parsed as such regardless of the scheme). > > HTTP was merely updated to reflect what STD66 calls a URI. I agree that the fragment is part of the URI; the question, as far as I understand, is whether the *scheme* definition should include the fragment, given the fact that you can attach a fragment to any URI anyway. Best regards, Julian From nobody Wed Jan 28 14:07:21 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D21F1A0358 for ; Wed, 28 Jan 2015 14:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgBsBBVFPxlW for ; Wed, 28 Jan 2015 14:07:07 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 822091A032D for ; Wed, 28 Jan 2015 14:07:06 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 2B6052AC06E; Wed, 28 Jan 2015 14:07:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=SYCHelxrOMye05kJYdK4IMuYH+8=; b=mUn0pH2vTo2xs5qUGALJokS9VSs0 kKvnmbghkCbeylWczDO80sZ909zs4/ZNVsgm5HlpEy6RAxe/kIANAnftRVc1uq8V SI+3f6PVMqO81sFjt0ljA5POO0gJ8GgBGqBPwpiAnVNg3QQNZb5bqSDjg0juzUXH bLDAJHfFKJWA2ns= Received: from [192.168.1.12] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id E12152AC06A; Wed, 28 Jan 2015 14:07:05 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <54C95AF7.6030703@gmx.de> Date: Wed, 28 Jan 2015 14:06:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <837DAA83-546E-425A-AD13-003F743B54A9@gbiv.com> References: <54AEB660.1020701@intertwingly.net> <54C84872.5040902@intertwingly.net> <54C95132.2060402@gmx.de> <154ABFBB-AB8C-447A-89A3-D1746EFBF1C6@gbiv.com> <54C95AF7.6030703@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1283) Archived-At: Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 22:07:14 -0000 On Jan 28, 2015, at 1:56 PM, Julian Reschke wrote: > On 2015-01-28 22:40, Roy T. Fielding wrote: >> On Jan 28, 2015, at 1:14 PM, Julian Reschke wrote: >>> On 2015-01-28 06:36, Mark Nottingham wrote: >>>> ... which brings about another interesting observation -- only http = and https define fragments in their syntax; the other schemes do not. >>>> ... >>>=20 >>> It's because you asked for that in = , = and apparently were successful in convincing Roy. >>=20 >> It is a very very very old debate regarding whether the fragment is = part >> of a URI or something attached to the end of a URI, but that was = resolved >> in RFC3986 (since the only thing that really matters here is that a = fragment >> is going to be parsed as such regardless of the scheme). >>=20 >> HTTP was merely updated to reflect what STD66 calls a URI. >=20 > I agree that the fragment is part of the URI; the question, as far as = I understand, is whether the *scheme* definition should include the = fragment, given the fact that you can attach a fragment to any URI = anyway. The answer is "no". http://tools.ietf.org/html/rfc3986#section-4.3 I don't know how I got beaten into submission on that for RFC7230. ....Roy From nobody Wed Jan 28 14:54:43 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C171A1B82 for ; Wed, 28 Jan 2015 14:54:41 -0800 (PST) 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 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 65MqRYxzKy8z for ; Wed, 28 Jan 2015 14:54:39 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 141031A1B7A for ; Wed, 28 Jan 2015 14:54:39 -0800 (PST) Received: from [192.168.1.83] (unknown [118.209.44.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9C72022E261; Wed, 28 Jan 2015 17:54:32 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Mark Nottingham In-Reply-To: <837DAA83-546E-425A-AD13-003F743B54A9@gbiv.com> Date: Thu, 29 Jan 2015 09:54:28 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <0FC6548B-1BC7-43C1-B421-6174F70D14D8@mnot.net> References: <54AEB660.1020701@intertwingly.net> <54C84872.5040902@intertwingly.net> <54C95132.2060402@gmx.de> <154ABFBB-AB8C-447A-89A3-D1746EFBF1C6@gbiv.com> <54C95AF7.6030703@gmx.de> <837DAA83-546E-425A-AD13-003F743B54A9@gbiv.com> To: Roy Fielding X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "Julian F. Reschke" , IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 22:54:41 -0000 On 29 Jan 2015, at 9:06 am, Roy T. Fielding wrote: >=20 > On Jan 28, 2015, at 1:56 PM, Julian Reschke wrote: >> On 2015-01-28 22:40, Roy T. Fielding wrote: >>> On Jan 28, 2015, at 1:14 PM, Julian Reschke wrote: >>>> On 2015-01-28 06:36, Mark Nottingham wrote: >>>>> ... which brings about another interesting observation -- only = http and https define fragments in their syntax; the other schemes do = not. >>>>> ... >>>>=20 >>>> It's because you asked for that in = , = and apparently were successful in convincing Roy. >>>=20 >>> It is a very very very old debate regarding whether the fragment is = part >>> of a URI or something attached to the end of a URI, but that was = resolved >>> in RFC3986 (since the only thing that really matters here is that a = fragment >>> is going to be parsed as such regardless of the scheme). >>>=20 >>> HTTP was merely updated to reflect what STD66 calls a URI. >>=20 >> I agree that the fragment is part of the URI; the question, as far as = I understand, is whether the *scheme* definition should include the = fragment, given the fact that you can attach a fragment to any URI = anyway. >=20 > The answer is "no". http://tools.ietf.org/html/rfc3986#section-4.3 >=20 > I don't know how I got beaten into submission on that for RFC7230. I followed the e-mail discussion, resulting issue to the ultimate = commit: I wouldn't call it a beating -- you didn't seem to need much convincing = at all :) That aside, it looks like we need an errata here... It does look like draft-ietf-appsawg-uri-scheme-reg clarifies this, = which is gratifying. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Jan 28 15:06:51 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAA51A0056 for ; Wed, 28 Jan 2015 15:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8-I0q7MfMWN for ; Wed, 28 Jan 2015 15:06:48 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D94BA1A1BF6 for ; Wed, 28 Jan 2015 15:06:48 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 9DACF1DE05D; Wed, 28 Jan 2015 15:06:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=wR4W5XA1mQyvsH Rx+M201j6br3Q=; b=sXKQMUxHT2BXJ5G/4m92FRoCGAh4UWu8mj8BTcCuFUa2Xq gxSDWVxY5pT/9+YlPGMpjcN71vooCeuREDDdh/Nd/YRrHTFkUyuoUO0moKU7M0sS 2RifOQNK7jFwWTTsCEn2reTiUUVUf62puGKsIkTs28FpM7pD5XMW5AKYlqqVU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPA id 44FD01DE005; Wed, 28 Jan 2015 15:06:48 -0800 (PST) Date: Wed, 28 Jan 2015 17:06:47 -0600 From: Nico Williams To: Mark Nottingham Message-ID: <20150128230643.GH3110@localhost> References: <54AEB660.1020701@intertwingly.net> <54C84872.5040902@intertwingly.net> <54C95132.2060402@gmx.de> <154ABFBB-AB8C-447A-89A3-D1746EFBF1C6@gbiv.com> <54C95AF7.6030703@gmx.de> <837DAA83-546E-425A-AD13-003F743B54A9@gbiv.com> <0FC6548B-1BC7-43C1-B421-6174F70D14D8@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0FC6548B-1BC7-43C1-B421-6174F70D14D8@mnot.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "Julian F. Reschke" , Roy Fielding , IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 23:06:50 -0000 On Thu, Jan 29, 2015 at 09:54:28AM +1100, Mark Nottingham wrote: > On 29 Jan 2015, at 9:06 am, Roy T. Fielding wrote: > > I don't know how I got beaten into submission on that for RFC7230. Not that RFC7230 updates STD 66 anyways, so this looks like: > I followed the e-mail discussion, resulting issue to the ultimate commit: > > > I wouldn't call it a beating -- you didn't seem to need much convincing at all :) > > That aside, it looks like we need an errata here... an erratum. Nico -- From nobody Wed Jan 28 15:08:40 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0E71A1BFC for ; Wed, 28 Jan 2015 15:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6vrGO-rB7_D for ; Wed, 28 Jan 2015 15:08:34 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0E31A1B91 for ; Wed, 28 Jan 2015 15:08:34 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id B680520078714; Wed, 28 Jan 2015 15:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=o7Bm3p9YiiY0Z7 N98rFsj1o5o1o=; b=aBHAl8F/PpMkcKxTBcZw6SJZbmbhZQrtACfFzj/59Ocirb 8Cvqtrg856MqalbzMY9YVFBFCrwIQCgU4GtCdcIE0qAQ6iZ9J0VpchkpIhoe/D/S eOu4keFl8VJ9ABBWSpCMlELAdAkAITwGmmPce50QJD5oMg0aFbMD7O2UZUKEw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id 3B6D52007870D; Wed, 28 Jan 2015 15:08:33 -0800 (PST) Date: Wed, 28 Jan 2015 17:08:32 -0600 From: Nico Williams To: Sam Ruby Message-ID: <20150128230828.GI3110@localhost> References: <54AEB660.1020701@intertwingly.net> <54C84872.5040902@intertwingly.net> <54C95132.2060402@gmx.de> <154ABFBB-AB8C-447A-89A3-D1746EFBF1C6@gbiv.com> <54C959C9.2090002@intertwingly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54C959C9.2090002@intertwingly.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Julian Reschke , "Roy T. Fielding" , Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 23:08:37 -0000 On Wed, Jan 28, 2015 at 04:51:05PM -0500, Sam Ruby wrote: > > > On 01/28/2015 04:40 PM, Roy T. Fielding wrote: > >On Jan 28, 2015, at 1:14 PM, Julian Reschke wrote: > >>On 2015-01-28 06:36, Mark Nottingham wrote: > >>>... which brings about another interesting observation -- only http and https define fragments in their syntax; the other schemes do not. > >>>... > >> > >>It's because you asked for that in , and apparently were successful in convincing Roy. > > > >It is a very very very old debate regarding whether the fragment is part > >of a URI or something attached to the end of a URI, but that was resolved > >in RFC3986 (since the only thing that really matters here is that a fragment > >is going to be parsed as such regardless of the scheme). > > > >HTTP was merely updated to reflect what STD66 calls a URI. > > Based on this discussion, I am gathering that the correct way to > validate a URI with a known scheme is as follows: > > return new RegExp("^" + known[scheme] + "($|#" + fragment + > ")").test(string) > > Anybody care to confirm or deny? For dereferenceable URI schemes that looks right to me. It's not really right for mailto: URIs (which aren't dereferenceable). I suppose data: URIs could have fragments. Nico -- From nobody Wed Jan 28 15:59:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15ACD1A8784 for ; Wed, 28 Jan 2015 15:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.028 X-Spam-Level: X-Spam-Status: No, score=-1.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlGXLJazCTdh for ; Wed, 28 Jan 2015 15:59:18 -0800 (PST) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA671A854D for ; Wed, 28 Jan 2015 15:59:18 -0800 (PST) Received: by mail-qg0-f46.google.com with SMTP id i50so21364974qgf.5 for ; Wed, 28 Jan 2015 15:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=RTsKTor2Q+K8Y2HhpPqHX2PwIEE6x6u1bWIBhFgsLQA=; b=G7R1MWVTofF/Ai1O1yW2R7Vr8l4Gymz8xolr4UUugGo3rws3Je7CfT7DElneGl4rDq bN8xHVjmPSn1fhMu9Nhx9BSEVmcN8irfPC3cZFBXGB+GiLGK51VEfLMrwjNpYRFXaV86 r/4lzneYQCKui66N41eF4yRLiz9ed6gmJSovHo3zhLlDfDy6vfeooqh0F2W0rq3hm7Hy RD16lUjtVYkDm0dl71FVAWLca4bNPQrUtwShCst0214QXUeBtm5twAV4SttXHH2xkfZM yPVBYBIa0Y+HDtHFxlTgCGfvi5zBU+LFx83LWbziEKZCD+tSmX7c7lb+yMjF/DmN658W 8nPA== MIME-Version: 1.0 X-Received: by 10.140.35.114 with SMTP id m105mr17681792qgm.79.1422489557819; Wed, 28 Jan 2015 15:59:17 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.105.75 with HTTP; Wed, 28 Jan 2015 15:59:17 -0800 (PST) In-Reply-To: <54C95AF7.6030703@gmx.de> References: <54AEB660.1020701@intertwingly.net> <54C84872.5040902@intertwingly.net> <54C95132.2060402@gmx.de> <154ABFBB-AB8C-447A-89A3-D1746EFBF1C6@gbiv.com> <54C95AF7.6030703@gmx.de> Date: Thu, 29 Jan 2015 09:59:17 +1000 X-Google-Sender-Auth: QtnnpdgGAzl04RpQax2VS-pNeQg Message-ID: From: Matthew Kerwin To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Roy T. Fielding" , Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jan 2015 23:59:20 -0000 On 29/01/2015, Julian Reschke wrote: > > I agree that the fragment is part of the URI; the question, as far as I > understand, is whether the *scheme* definition should include the > fragment, given the fact that you can attach a fragment to any URI anyway. > The answer to this affects what I write in the 'file' scheme draft. I was advised early on to not mention fragments (which I took as "disallow by omission") because, while it's easy to define syntax, the scheme also has to define semantics, and fragment semantics are tied to content type, and dereferenced 'file' URIs don't have a well-defined content type. Whether or not I mention it comes back to the definition and intended use-case of RFC 3986; if it defines an 'abstract' syntax - in the POO sense - then there's no such thing as a universal parser (i.e. It's impossible to parse a URI with an unknown scheme). If it defines a low-level structure, then any URI can be parsed, but the individual components can't be validated without deferring to scheme-specific machinery. If the former and I don't include the fragment in 'file', it isn't allowed. If the latter, I just leave a hole in the spec. Cheers -- Matthew Kerwin http://matthew.kerwin.net.au/ From nobody Wed Jan 28 16:23:29 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5F71A88D4 for ; Wed, 28 Jan 2015 16:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omqxGf2ocJzN for ; Wed, 28 Jan 2015 16:23:25 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0053.outbound.protection.outlook.com [207.46.100.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5A721A88B2 for ; Wed, 28 Jan 2015 16:23:12 -0800 (PST) Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0959.namprd02.prod.outlook.com (25.160.216.27) with Microsoft SMTP Server (TLS) id 15.1.65.19; Thu, 29 Jan 2015 00:23:11 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) by DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) with mapi id 15.01.0065.013; Thu, 29 Jan 2015 00:23:11 +0000 From: Larry Masinter To: Matthew Kerwin , "julian.reschke@gmx.de" Thread-Topic: [apps-discuss] Fun with URLs and regex Thread-Index: AQHQKsH3fKm+oZQcQU+UGfBvMHQS95y1SJCAgAELpgCAAB3uAIAectsAgAAIrACAADWBAIABBhoAgAAHRYCAAARggIAAImqAgAACm+A= Date: Thu, 29 Jan 2015 00:23:10 +0000 Message-ID: References: <54AEB660.1020701@intertwingly.net> <54C84872.5040902@intertwingly.net> <54C95132.2060402@gmx.de> <154ABFBB-AB8C-447A-89A3-D1746EFBF1C6@gbiv.com> <54C95AF7.6030703@gmx.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] authentication-results: kerwin.net.au; dkim=none (message not signed) header.d=none;kerwin.net.au; dmarc=none action=none header.from=adobe.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DM2PR0201MB0959; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB0959; x-forefront-prvs: 0471B73328 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(66066001)(33656002)(122556002)(2656002)(87936001)(54356999)(76576001)(2501002)(92566002)(46102003)(93886004)(77156002)(76176999)(50986999)(15975445007)(62966003)(106116001)(102836002)(1720100001)(74316001)(99286002)(54206007)(40100003)(86362001)(19580395003)(2950100001)(2900100001)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0959; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2015 00:23:10.8742 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB0959 Archived-At: Cc: "Roy T. Fielding" , Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jan 2015 00:23:27 -0000 PiBUaGUgYW5zd2VyIHRvIHRoaXMgYWZmZWN0cyB3aGF0IEkgd3JpdGUgaW4gdGhlICdmaWxlJyBz Y2hlbWUgZHJhZnQuIEkNCj4gd2FzIGFkdmlzZWQgZWFybHkgb24gdG8gbm90IG1lbnRpb24gZnJh Z21lbnRzICh3aGljaCBJIHRvb2sgYXMNCj4gImRpc2FsbG93IGJ5IG9taXNzaW9uIikgYmVjYXVz ZSwgd2hpbGUgaXQncyBlYXN5IHRvIGRlZmluZSBzeW50YXgsIHRoZQ0KPiBzY2hlbWUgYWxzbyBo YXMgdG8gZGVmaW5lIHNlbWFudGljcywgYW5kIGZyYWdtZW50IHNlbWFudGljcyBhcmUgdGllZA0K PiB0byBjb250ZW50IHR5cGUsIGFuZCBkZXJlZmVyZW5jZWQgJ2ZpbGUnIFVSSXMgZG9uJ3QgaGF2 ZSBhDQo+IHdlbGwtZGVmaW5lZCBjb250ZW50IHR5cGUuDQoNClRoaXMgbGVhZHMgdG8gdGhlIChj dXJyZW50bHkgYWJhbmRvbmVkKSB3b3JrIG9uIE1JTUUgc25pZmZpbmcNCndoaWNoIGF0dGVtcHRz IHRvIHdlbGwtZGVmaW5lIGEgY29udGVudC10eXBlIGZvciAnZmlsZScgVVJJczoNCg0KaHR0cHM6 Ly9taW1lc25pZmYuc3BlYy53aGF0d2cub3JnLyANCg0KKGJ1ZyBsaXN0IA0KaHR0cHM6Ly93d3cu dzMub3JnL0J1Z3MvUHVibGljL2J1Z2xpc3QuY2dpP2NvbXBvbmVudD1NSU1FJmxpc3RfaWQ9NTEy MjEmcHJvZHVjdD1XSEFUV0cmcmVzb2x1dGlvbj0tLS0pDQoNCmJhc2VkIG9uICh0aGUgYWJhbmRv bmVkKQ0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtd2Vic2VjLW1pbWUt c25pZmYtMDMNCg0KDQpOb3RlIGh0dHBzOi8vd3d3LnczLm9yZy9CdWdzL1B1YmxpYy9zaG93X2J1 Zy5jZ2k/aWQ9MjAwMDMNCiJDbGFyaWZ5IHNjb3BlIG9mIE1JTUUgc25pZmZpbmciIGZyb20gSUVU RiB0cmFja2VyICMxNQ0KDQpCYXNlZCBvbg0KaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cv d2Vic2VjL3RyYWMvdGlja2V0LzE1DQoNCg== From nobody Wed Jan 28 17:25:01 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095A71A8A8D for ; Wed, 28 Jan 2015 17:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8MDO3ecFOrh for ; Wed, 28 Jan 2015 17:24:56 -0800 (PST) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF1A1A8A8C for ; Wed, 28 Jan 2015 17:24:56 -0800 (PST) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id ECD97200D3072; Wed, 28 Jan 2015 17:24:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=Rw01ZeiS8+wkiPbGVaOrZVgTFIg=; b=Nw0RHeAzXiFhvtXsPcivgz8GdWgb pZbIQSmVRdZOonmYpYnKhUUMjH8u/gFW7NmJ/2gGmh5thlwde2Sq/0dljxdKlYGu 14Dtok5WAMs1KU9RMCEVr3LssGBRNBHabDnr3G+TZvOvmRqvmrgVLKwqoc7dtORz LHPSIA/btzF8L0Y= Received: from [192.168.1.12] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id BC03F200D3071; Wed, 28 Jan 2015 17:24:55 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: Date: Wed, 28 Jan 2015 17:24:55 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <54AEB660.1020701@intertwingly.net> <54C84872.5040902@intertwingly.net> <54C95132.2060402@gmx.de> <154ABFBB-AB8C-447A-89A3-D1746EFBF1C6@gbiv.com> <54C95AF7.6030703@gmx.de> To: Matthew Kerwin X-Mailer: Apple Mail (2.1283) Archived-At: Cc: Julian Reschke , Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jan 2015 01:24:57 -0000 On Jan 28, 2015, at 3:59 PM, Matthew Kerwin wrote: > On 29/01/2015, Julian Reschke wrote: >> >> I agree that the fragment is part of the URI; the question, as far as I >> understand, is whether the *scheme* definition should include the >> fragment, given the fact that you can attach a fragment to any URI anyway. >> > > The answer to this affects what I write in the 'file' scheme draft. I > was advised early on to not mention fragments (which I took as > "disallow by omission") because, while it's easy to define syntax, the > scheme also has to define semantics, and fragment semantics are tied > to content type, and dereferenced 'file' URIs don't have a > well-defined content type. > > Whether or not I mention it comes back to the definition and intended > use-case of RFC 3986; if it defines an 'abstract' syntax - in the POO > sense - then there's no such thing as a universal parser (i.e. It's > impossible to parse a URI with an unknown scheme). If it defines a > low-level structure, then any URI can be parsed, but the individual > components can't be validated without deferring to scheme-specific > machinery. > > If the former and I don't include the fragment in 'file', it isn't > allowed. If the latter, I just leave a hole in the spec. It isn't that black and white. The grammar for the scheme is what excludes a fragment. That doesn't prevent the scheme docs from talking about fragments (in reference to RFC3986) and using them within examples. That part of the URI spec was written specifically to address issues created by folks who thought they could redefine the meaning of fragments within individual schemes, or forbid them entirely, when in fact the meaning and use of fragments are independent of scheme. What makes you think that dereferenced files don't have a well-defined content type? The client might not know what it is, but that doesn't mean the content type doesn't exist, and any decision to process the file is basically an assumption of some content type (and its rules for processing fragments). ....Roy From nobody Wed Jan 28 21:14:28 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8491A1BA5 for ; Wed, 28 Jan 2015 21:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXqozGt9AKxU for ; Wed, 28 Jan 2015 21:14:15 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793071A1BAE for ; Wed, 28 Jan 2015 21:14:12 -0800 (PST) Received: by mail-qg0-f42.google.com with SMTP id q107so23952565qgd.1 for ; Wed, 28 Jan 2015 21:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5zAy/iLX20LbM/qY5e/WcToO57fuC/tIr3ENeXoXrBQ=; b=x3BSM8r8hYghYhsw5rwPTZSw/tXjbHOFSCq1LIHr+AhN6GF3qU/UzLHJMqKCht8AM/ Ox6ep07Ozou9ZBh30V8/JpG3Tcw+vivnXd/Yg+mjrYQVAI+rB1Jy5Vzc1GVVrHWKi1xf vxPaoOS8Pug3Y/7TQlDDS/BocPEjE4zWVpVdnTyeAaDyoUomCHjLWlDh/bWPZzXQUEvF 0VOZD6XuzTWV7D6UR5EutF6Owpjau8ImM6I4opcisuGjOZGK4FJ+BIJ9STVxGiGDptFi 3PVEeLqL4zCmM18x4eMNa7J19f22uBllncZ/3D4q7rx6b5MNPZyKS5Sfn4vY2k+cQQy8 5PCQ== MIME-Version: 1.0 X-Received: by 10.140.27.199 with SMTP id 65mr192813qgx.24.1422508451583; Wed, 28 Jan 2015 21:14:11 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.105.75 with HTTP; Wed, 28 Jan 2015 21:14:11 -0800 (PST) In-Reply-To: References: <54AEB660.1020701@intertwingly.net> <54C84872.5040902@intertwingly.net> <54C95132.2060402@gmx.de> <154ABFBB-AB8C-447A-89A3-D1746EFBF1C6@gbiv.com> <54C95AF7.6030703@gmx.de> Date: Thu, 29 Jan 2015 15:14:11 +1000 X-Google-Sender-Auth: vJ7tK5mFSQ1sxvnYMtxoeqBzEVM Message-ID: From: Matthew Kerwin To: "Roy T. Fielding" Content-Type: multipart/alternative; boundary=001a11c15694f27aaa050dc38ef7 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jan 2015 05:14:17 -0000 --001a11c15694f27aaa050dc38ef7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29 January 2015 at 11:24, Roy T. Fielding wrote: > On Jan 28, 2015, at 3:59 PM, Matthew Kerwin wrote: > > > > Whether or not I mention it comes back to the definition and intended > > use-case of RFC 3986; if it defines an 'abstract' syntax - in the POO > > sense - then there's no such thing as a universal parser (i.e. It's > > impossible to parse a URI with an unknown scheme). If it defines a > > low-level structure, then any URI can be parsed, but the individual > > components can't be validated without deferring to scheme-specific > > machinery. > > > > If the former and I don't include the fragment in 'file', it isn't > > allowed. If the latter, I just leave a hole in the spec. > > It isn't that black and white. The grammar for the scheme is what > excludes a fragment. That doesn't prevent the scheme docs from > talking about fragments (in reference to RFC3986) and using them > within examples. > =E2=80=8B > =E2=80=8B > =E2=80=8B > =E2=80=8B > > > =E2=80=8B=E2=80=8B > That part of the URI spec was written specifically to address > issues created by folks who thought they could redefine the meaning > of fragments within individual schemes, or forbid them entirely, > when in fact the meaning and use of fragments are independent of > scheme. > =E2=80=8B > =E2=80=8B > =E2=80=8B=E2=80=8B > Poking around again, I just saw the line "Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications." So yes, I think I now understand where everyone is coming from in the discussion, and I also think I understand RFC 3986 less than I did before. Time for more reading... RFC 3986 "defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier", that's clear enough - it's not an abstract grammar. The twist that I'd missed was that, of the resulting components, not all of them are inputs to the individual schemes; the 'fragment' component feeds into the content handler directly. I'm still suffering a misalignment: RFC 3986 defines the whole generic URI syntax as: URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] and my draft that references it essentially defines (or will soon define) the whole file-URI syntax as: file-URI =3D subset-of-scheme ":" subset-of-hier-part By leaving off the query part, I've either said that a URI with a query part cannot be a 'file' URI, or that a URI that starts with "file:" and has a query part is invalid. Potayto potahto. I don't know what I've said by leaving off the fragment part. According to RFC 3986 I'm not allowed to touch the it, but now I have a collected ABNF for 'file' URIs that doesn't have fragments. I think my way forward is to include the fragment part in the grammar, and then deflect it the way 3986, 7230, etc. do. "The fragment's format and resolution is ... dependent on the media type of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced. ... The [client] MAY either assume a media type of "application/octet-stream" or examine the data to determine its type." Or something to similar effect. Does that seem right to you? How do other representation-retrieving schemes deal with it? =E2=80=8B=E2=80=8B > > What makes you think that dereferenced files don't have a well-defined > content type? The client might not know what it is, but that doesn't > mean the content type doesn't exist, and any decision to process the > file is basically an assumption of some content type (and its rules > for processing fragments). > > Perhaps I s=E2=80=8Bhould have said "well known" instead of "well-defined,"= or that the *means of determining* the content type is not well defined. Back to Sam's library: > Based on this discussion, I am gathering that the correct way to validate a URI with a known scheme is as follows: > > return new RegExp("^" + known[scheme] + "($|#" + fragment + ")").test(string) > > Anybody care to confirm or deny? What with all the reading and thinking I've just done, I suppose that's right. As long as all the known schemes don't have their own #fragment bits (http_URI does). Aesthetically it's strange way to denote an optional fragment, but it gets there in the end. --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11c15694f27aaa050dc38ef7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 29 January 2015 at 11:24, Roy T. Fielding <<= a href=3D"mailto:fielding@gbiv.com" target=3D"_blank">fielding@gbiv.com= > wrote:
On Jan 28, 2015, at = 3:59 PM, Matthew Kerwin wrote:
>
> Whether or not I mention it comes back to the definition and intended<= br> > use-case of RFC 3986; if it defines an 'abstract' syntax - in = the POO
> sense - then there's no such thing as a universal parser (i.e. It&= #39;s
> impossible to parse a URI with an unknown scheme). If it defines a
> low-level structure, then any URI can be parsed, but the individual > components can't be validated without deferring to scheme-specific=
> machinery.
>
> If the former and I don't include the fragment in 'file', = it isn't
> allowed. If the latter, I just leave a hole in the spec.

It isn't that black and white.=C2=A0 The grammar for the sc= heme is what
excludes a fragment.=C2=A0 That doesn't prevent the scheme docs from talking about fragments (in reference to RFC3986) and using them
within examples.
=E2=80=8B
=E2=80=8B
=E2=80=8B
=E2=80=8B


=E2=80=8B=E2=80=8BThat part of the URI spec was written specifically to address
issues = created by folks who thought they could redefine the meaning
of fragment= s within individual schemes, or forbid them entirely,
when in fact the m= eaning and use of fragments are independent of
scheme.
=E2=80=8B
=E2=80=8B
=E2=80=8B=E2=80=8B
=

Poking around again, I just saw the line "Fragment identifi= er semantics are independent of the URI scheme and thus cannot be redefined= by scheme specifications." So yes, I think I now understand where eve= ryone is coming from in the discussion, and I also think I understand RFC 3= 986 less than I did before. Time for more reading...

RFC 3986 "defines a grammar that is a superset of all valid= URIs, allowing an implementation to parse the common components of a URI r= eference without knowing the scheme-specific requirements of every possible= identifier", that's clear enough - it's not an abstract gramm= ar. The twist that I'd missed was that, of the resulting components, no= t all of them are inputs to the individual schemes; the 'fragment' = component feeds into the content handler directly.

=
I'm still suffering a misalignment: RFC 3986 defines the whole= generic URI syntax as:

=C2=A0 =C2=A0 URI = =3D scheme ":" hier-part [ "?" query ] [ "#" = fragment ]

and my draft that references it= essentially defines (or will soon define) the whole file-URI syntax as:

=C2=A0 =C2=A0 file-URI =3D subset-of-scheme = ":" subset-of-hier-part

By lea= ving off the query part, I've either said that a URI with a query part = cannot be a 'file' URI, or that a URI that starts with "file:&= quot; and has a query part is invalid. Potayto potahto.

<= /div>
I don't know what I've said by leaving off the fragme= nt part. According to RFC 3986 I'm not allowed to touch the it, but now= I have a collected ABNF for 'file' URIs that doesn't have frag= ments. I think my way forward is to include the fragment part in the gramma= r, and then deflect it the way 3986, 7230, etc. do. =C2=A0"The fragmen= t's format and resolution is ... dependent on the media type of a poten= tially retrieved representation, even though such a retrieval is only perfo= rmed if the URI is dereferenced. ... The [client] MAY either assume a media= type of "application/octet-stream" or examine the data to determ= ine its type." Or something to similar effect. Does that seem right to= you? How do other representation-retrieving schemes deal with it?

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

What makes you think that dereferenced files = don't have a well-defined
content type?=C2=A0 The client might not k= now what it is, but that doesn't
mean the content type doesn't e= xist, and any decision to process the
file is basically an assumption of= some content type (and its rules
for processing fragments).


Perhaps I s=E2=80=8Bhould have= said "well known" instead of "well-defined," or that t= he *means of determining* the content type is not well defined.
=


Back to Sam's library:= =C2=A0

> Based on th= is discussion, I am gathering that the correct way to validate a URI with a= known scheme is as follows:
>
> =C2=A0 return new RegExp("^" + known[scheme= ] + "($|#" + fragment + ")").test(string)
>
> Anybody care to conf= irm or deny?

<= div class=3D"gmail_default" style=3D"font-family:georgia,serif;color:rgb(7,= 55,99)">What with all the reading and thinking I've just done, I suppos= e that's right. As long as all the known schemes don't have their o= wn #fragment bits (http_URI does).

Aesthe= tically it's strange way to denote an optional fragment, but it gets th= ere in the end.



--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a11c15694f27aaa050dc38ef7-- From nobody Wed Jan 28 21:18:39 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1F41A8BBE for ; Wed, 28 Jan 2015 21:18:35 -0800 (PST) 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 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 NTBCvhX1me1B for ; Wed, 28 Jan 2015 21:18:32 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 9B8171A1BA7 for ; Wed, 28 Jan 2015 21:18:32 -0800 (PST) Received: from [192.168.1.83] (unknown [118.209.44.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4C6F422E260; Thu, 29 Jan 2015 00:18:26 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Mark Nottingham In-Reply-To: Date: Thu, 29 Jan 2015 16:18:22 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54B18B61.8010308@seantek.com> <54B19435.8070401@intertwingly.net> <54B1B211.3050807@seantek.com> <54B1B682.3070609@intertwingly.net> <012001d02d91$6ec42300$4001a8c0@gateway.2wire.net> <54B2781C.4040505@intertwingly.net> <018e01d02dc6$1d03b0a0$4001a8c0@gateway.2wire.net> <54B2CC75.5080900@intertwingly.net> <54B79930.3070009@ninebynine.org> <54B7AEC2.9010109@intertwingly.net> <20150116033032.GD2350@localhost> <015c01d0362f$1f6f6020$4001a8c0@gateway.2wire.net> <54C65580.2080407@ninebynine.org> <84E353AE-D96B-4211-99CB-D08AE17B1B1E@gbiv.com> To: Dave Cridland X-Mailer: Apple Mail (2.1993) Archived-At: Cc: Roy Fielding , Graham Klyne , IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-iri-comparison X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jan 2015 05:18:36 -0000 > On 28 Jan 2015, at 7:20 pm, Dave Cridland wrote: >=20 > Going all meta for a moment... >=20 > On 27 Jan 2015 23:01, "Mark Nottingham" wrote: > > I'd far prefer that appsawg were shut down and replaced by "mail" = and "Web" WGs, the latter taking responsibility for URIs. They'd fight = over format stuff, but that mirrors real life... >=20 > Some of the most interesting discussions have arisen because the = audience here is broad enough to observe the uses of URIs outside the = traditional web space (ie, HTML). At the risk of sounding a little high = and mighty, the web world has a lot to learn from the more conservative = mail world about stability and compatibility - and the reverse is = undoubtedly true as well. >=20 > Still, things like DMARC show that the mail world can be screwed over = by a few big players just as badly. Luckily those players have self = censored themselves from discussions... >=20 > In any case, unless this list were shockingly busy I think we get into that state pretty often on this list... YMMV. > , I'd rather not hive off discussions into groupthink collectives. = Dissension is a fine product of diversity. -- Mark Nottingham https://www.mnot.net/ From nobody Wed Jan 28 23:30:46 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E94A1A8F51 for ; Wed, 28 Jan 2015 23:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7Cm2-sRGsQD for ; Wed, 28 Jan 2015 23:30:38 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 EC8631A8F4E for ; Wed, 28 Jan 2015 23:30:37 -0800 (PST) Received: from [192.168.2.175] ([93.217.85.143]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Mcyxq-1XzcPc1Tik-00IBH2; Thu, 29 Jan 2015 08:30:31 +0100 Message-ID: <54C9E18F.6070009@gmx.de> Date: Thu, 29 Jan 2015 08:30:23 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Nico Williams , Sam Ruby References: <54AEB660.1020701@intertwingly.net> <54C84872.5040902@intertwingly.net> <54C95132.2060402@gmx.de> <154ABFBB-AB8C-447A-89A3-D1746EFBF1C6@gbiv.com> <54C959C9.2090002@intertwingly.net> <20150128230828.GI3110@localhost> In-Reply-To: <20150128230828.GI3110@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:FW/MInrshu5F9r9Il/cfRkZrYIzyiOQw8wIsPY6Bgzn6yW9cCNE lTmxV7qdw4B2KHjlrMnBxNg9IR2gC6/f8Rl1vDd2XqbLkV54mA9iKnluxyWYMq4gTaHIAZo YCEW+R0CoXIlIyJFxB7RwaQggGlBCt542LoB1c2x+SLyMIOhaX1N/3dpyb7Hw6a4DtdnL0L L2WoIIJND1XW8NCczp/dg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "Roy T. Fielding" , Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jan 2015 07:30:41 -0000 On 2015-01-29 00:08, Nico Williams wrote: > ... > For dereferenceable URI schemes that looks right to me. > ... Any non-dereferencable scheme can later become referencable by installing a resolver. > It's not really right for mailto: URIs (which aren't dereferenceable). > > I suppose data: URIs could have fragments. They do. Best regards, Julian From nobody Thu Jan 29 01:10:52 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7017E1A01D8 for ; Thu, 29 Jan 2015 01:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJ6-HgmyqFeU for ; Thu, 29 Jan 2015 01:10:45 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 ED1F21A0102 for ; Thu, 29 Jan 2015 01:10:44 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CC46C22E263 for ; Thu, 29 Jan 2015 04:10:43 -0500 (EST) Message-ID: <54C9F914.4090002@seantek.com> Date: Thu, 29 Jan 2015 01:10:44 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <54AEB660.1020701@intertwingly.net> <54C84872.5040902@intertwingly.net> <54C95132.2060402@gmx.de> <154ABFBB-AB8C-447A-89A3-D1746EFBF1C6@gbiv.com> <54C95AF7.6030703@gmx.de> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080702090703080806090801" Archived-At: Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jan 2015 09:10:47 -0000 This is a multi-part message in MIME format. --------------080702090703080806090801 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 1/28/2015 9:14 PM, Matthew Kerwin wrote: > > I don't know what I've said by leaving off the fragment part.=20 > According to RFC 3986 I'm not allowed to touch the it, but now I have=20 > a collected ABNF for 'file' URIs that doesn't have fragments. I think=20 > my way forward is to include the fragment part in the grammar, and=20 > then deflect it the way 3986, 7230, etc. do. More than anything else, this is probably an artifact of the way that=20 ABNF is written. It is not possible to "subclass" ABNF expressions;=20 however, that is what URI scheme registrations should do. I.e., they=20 should say "this URI scheme subclasses/profiles the following ABNF=20 productions from RFC 3986...scheme =3D "file", hier-part =3D such-and-suc= h=20 restrictions". Something like that. (In the case of file: , there is the = other problem that some things that are not valid per RFC 3986, like the = use of |, you want to say something about anyway, so can be both=20 restrictive and permissive in different ways.) > =E2=80=8B =E2=80=8B > > What makes you think that dereferenced files don't have a well-defi= ned > content type? The client might not know what it is, but that doesn= 't > mean the content type doesn't exist, and any decision to process th= e > file is basically an assumption of some content type (and its rules= > for processing fragments). > > > Perhaps I s=E2=80=8Bhould have said "well known" instead of "well-defin= ed," or=20 > that the *means of determining* the content type is not well defined. > Sounds about right. Sean --------------080702090703080806090801 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 1/28/2015 9:14 PM, Matthew Kerwin wrote:

I don't know what I've said by leaving off the fragment part. According to RFC 3986 I'm not allowed to touch the it, but now I have a collected ABNF for 'file' URIs that doesn't have fragments. I think my way forward is to include the fragment part in the grammar, and then deflect it the way 3986, 7230, etc. do.

More than anything else, this is probably an artifact of the way that ABNF is written. It is not possible to "subclass" ABNF expressions; however, that is what URI scheme registrations should do. I.e., they should say "this URI scheme subclasses/profiles the following ABNF productions from RFC 3986...scheme = "file", hier-part = such-and-such restrictions". Something like that. (In the case of file: , there is the other problem that some things that are not valid per RFC 3986, like the use of |, you want to say something about anyway, so can be both restrictive and permissive in different ways.)

​ ​

What makes you think that dereferenced files don't have a well-defined
content type?  The client might not know what it is, but that doesn't
mean the content type doesn't exist, and any decision to process the
file is basically an assumption of some content type (and its rules
for processing fragments).


Perhaps I s​hould have said "well known" instead of "well-defined," or that the *means of determining* the content type is not well defined.


Sounds about right.

Sean
--------------080702090703080806090801-- From nobody Thu Jan 29 02:50:10 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F0C1A0151 for ; Thu, 29 Jan 2015 02:49:53 -0800 (PST) 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, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDF0h89s7tsJ for ; Thu, 29 Jan 2015 02:49:52 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::797]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85071A01F4 for ; Thu, 29 Jan 2015 02:49:49 -0800 (PST) Received: from pc6 (81.151.167.59) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.65.19; Thu, 29 Jan 2015 10:49:26 +0000 Message-ID: <01f101d03bb1$0eee68e0$4001a8c0@gateway.2wire.net> From: t.petch To: Matthew Kerwin , "Roy T. Fielding" References: <54AEB660.1020701@intertwingly.net> <54C84872.5040902@intertwingly.net> <54C95132.2060402@gmx.de> <154ABFBB-AB8C-447A-89A3-D1746EFBF1C6@gbiv.com> <54C95AF7.6030703@gmx.de> Date: Thu, 29 Jan 2015 10:46:09 +0000 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: [81.151.167.59] X-ClientProxiedBy: DB3PR05CA0031.eurprd05.prod.outlook.com (25.160.41.159) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) Authentication-Results: kerwin.net.au; dkim=none (message not signed) header.d=none;kerwin.net.au; dmarc=none action=none header.from=btconnect.com; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB3PR07MB060; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DB3PR07MB060; X-Forefront-PRVS: 0471B73328 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(13464003)(24454002)(377454003)(1456003)(92566002)(93886004)(44736004)(76176999)(81686999)(81816999)(50226001)(47776003)(66066001)(42186005)(77096005)(50466002)(116806002)(50986999)(33646002)(77156002)(15975445007)(62966003)(40100003)(122386002)(84392001)(19580405001)(23676002)(14496001)(61296003)(46102003)(62236002)(44716002)(86362001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2015 10:49:26.0223 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jan 2015 10:49:54 -0000 ----- Original Message ----- From: "Matthew Kerwin" To: "Roy T. Fielding" Cc: "IETF Apps Discuss" Sent: Thursday, January 29, 2015 5:14 AM On 29 January 2015 at 11:24, Roy T. Fielding wrote: > > It isn't that black and white. The grammar for the scheme is what > excludes a fragment. That doesn't prevent the scheme docs from > talking about fragments (in reference to RFC3986) and using them > within examples. > That part of the URI spec was written specifically to address > issues created by folks who thought they could redefine the meaning > of fragments within individual schemes, or forbid them entirely, > when in fact the meaning and use of fragments are independent of > scheme. Poking around again, I just saw the line "Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications." So yes, I think I now understand where everyone is coming from in the discussion, and I also think I understand RFC 3986 less than I did before. Time for more reading... RFC 3986 "defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier", that's clear enough - it's not an abstract grammar. The twist that I'd missed was that, of the resulting components, not all of them are inputs to the individual schemes; the 'fragment' component feeds into the content handler directly. I'm still suffering a misalignment: RFC 3986 defines the whole generic URI syntax as: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] and my draft that references it essentially defines (or will soon define) the whole file-URI syntax as: file-URI = subset-of-scheme ":" subset-of-hier-part By leaving off the query part, I've either said that a URI with a query part cannot be a 'file' URI, or that a URI that starts with "file:" and has a query part is invalid. Potayto potahto. When I read your I-D, I assumed that you knew what you were doing:-) I can see a use for 'query' but if noone implements it, then better the I-D left it out. But I did have it as a point to pursue, once the bigger issue, to me, of splitting what is valid according to RFC3986 from what is not and seeing that reflected in the I-D (and of course, there is the mini-charter to agree:-( Tom Petch I don't know what I've said by leaving off the fragment part. According to RFC 3986 I'm not allowed to touch the it, but now I have a collected ABNF for 'file' URIs that doesn't have fragments. I think my way forward is to include the fragment part in the grammar, and then deflect it the way 3986, 7230, etc. do. "The fragment's format and resolution is ... dependent on the media type of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced. ... The [client] MAY either assume a media type of "application/octet-stream" or examine the data to determine its type." Or something to similar effect. Does that seem right to you? How do other representation-retrieving schemes deal with it? > > What makes you think that dereferenced files don't have a well-defined > content type? The client might not know what it is, but that doesn't > mean the content type doesn't exist, and any decision to process the > file is basically an assumption of some content type (and its rules > for processing fragments). > > Perhaps I s​hould have said "well known" instead of "well-defined," or that the *means of determining* the content type is not well defined. Back to Sam's library: > Based on this discussion, I am gathering that the correct way to validate a URI with a known scheme is as follows: > > return new RegExp("^" + known[scheme] + "($|#" + fragment + ")").test(string) > > Anybody care to confirm or deny? What with all the reading and thinking I've just done, I suppose that's right. As long as all the known schemes don't have their own #fragment bits (http_URI does). Aesthetically it's strange way to denote an optional fragment, but it gets there in the end. Matthew Kerwin http://matthew.kerwin.net.au/ From nobody Thu Jan 29 07:25:27 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8011A1A9C for ; Thu, 29 Jan 2015 07:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtSRDe3J7FZn for ; Thu, 29 Jan 2015 07:25:19 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.227]) by ietfa.amsl.com (Postfix) with ESMTP id 093811A1AB2 for ; Thu, 29 Jan 2015 07:25:18 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:4361] helo=rubix) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id E3/2F-19792-ED05AC45; Thu, 29 Jan 2015 15:25:18 +0000 Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 22EC5140AEA; Thu, 29 Jan 2015 10:25:19 -0500 (EST) Message-ID: <54CA50DD.50805@intertwingly.net> Date: Thu, 29 Jan 2015 10:25:17 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Mark Nottingham References: <54AEB660.1020701@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jan 2015 15:25:23 -0000 On 01/27/2015 08:53 PM, Mark Nottingham wrote: > > What I was hoping for was an update of the "valid URI" filter to take > this into account at > . > > E.g., that list currently includes test case 63, > "https:/example.com/", which is valid according to the generic syntax > in RFC3986, but not when you consider the scheme-specific constraints > for HTTPS in RFC7230. > > By filtering out these cases, we can see the places we potentially > need to pay attention to in the RFCs. > > Is that possible? Done and deployed. Let me know if you see any problems. For now, I decided to match your Python's script's behavior with respect to fragments and known but non-HTTP schemes. This doesn't affect any of the existing items in the current urltestdata set. - Sam Ruby From nobody Thu Jan 29 13:55:41 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB68C1A8854 for ; Thu, 29 Jan 2015 13:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.427 X-Spam-Level: X-Spam-Status: No, score=-0.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEkSd3NsQeqD for ; Thu, 29 Jan 2015 13:55:37 -0800 (PST) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 818771A884E for ; Thu, 29 Jan 2015 13:55:37 -0800 (PST) Received: by mail-qg0-f53.google.com with SMTP id a108so34885726qge.12 for ; Thu, 29 Jan 2015 13:55:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=qqmkc+dxKDfq7OR9YzYffLWP+zTpUEDjo48Yo0XZsa4=; b=j30bo+CnTvtKB+9uMO10qSCtWOzDcvMyBWCneFZI0nak1M+/Bv9FUMCuVVri3sh8yo X1eEP5C8W/ciqPIAeiz8ZO4TPBF/gNIyKhwPNlwpLj6SmnT+NQzOEaTZDF62R4FloC/I Rijd0NgV9GXN0Qjbr56X0ZJz1q/G0tslVbzVUtWUnI5yX7kA1dCldoq/4GU3OvkK1aCC +M7CzyoDDoLaqhAf9aZTUAEJ8LDUQMplZDBMGWKBA9UTaI1PZqjdL+JmjrnRXmToxf07 +rO1c3ImxWlOEVO5692d1x/QKvnvv3LL6NoAyGSfvXYbzUYujkZ/nob4ytHQzDcxQFzg jzbQ== MIME-Version: 1.0 X-Received: by 10.140.35.114 with SMTP id m105mr2077120qgm.79.1422568536465; Thu, 29 Jan 2015 13:55:36 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.105.75 with HTTP; Thu, 29 Jan 2015 13:55:36 -0800 (PST) Date: Fri, 30 Jan 2015 07:55:36 +1000 X-Google-Sender-Auth: e2CN2k7-Qf3dGRp2-87jBgZBIjU Message-ID: From: Matthew Kerwin To: "t.petch" Content-Type: multipart/alternative; boundary=001a11c003c048e8b7050dd18cd7 Archived-At: Cc: "Roy T. Fielding" , IETF Apps Discuss Subject: [apps-discuss] the URI definition model (was: Fun with URLs and regex) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jan 2015 21:55:40 -0000 --001a11c003c048e8b7050dd18cd7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29 January 2015 at 20:46, t.petch wrote: > ----- Original Message ----- > From: "Matthew Kerwin" > To: "Roy T. Fielding" > Cc: "IETF Apps Discuss" > Sent: Thursday, January 29, 2015 5:14 AM > > > I'm still suffering a misalignment: RFC 3986 defines the whole generic > URI > syntax as: > > URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] > > and my draft that references it essentially defines (or will soon > define) > the whole file-URI syntax as: > > file-URI =3D subset-of-scheme ":" subset-of-hier-part > > By leaving off the query part, I've either said that a URI with a query > part cannot be a 'file' URI, or that a URI that starts with "file:" and > has > a query part is invalid. Potayto potahto. > > > > When I read your I-D, I assumed that you knew what you were doing:-) I > can see a use for 'query' but if noone implements it, then better the > I-D left it out. But I did have it as a point to pursue, once the > bigger issue, to me, of splitting what is valid according to RFC3986 > from what is not and seeing that reflected in the I-D (and of course, > there is the mini-charter to agree:-( > > Tom Petch > > > =E2=80=8B=E2=80=8B > > > Ouch ;) To be honest, I think I thought I knew more than I really did. I'd like to think that, as I've discovered holes in my knowledge I've also filled them. Also in my defense, I've not had enough sleep the past week. Part of my problem is that I'm somewhere between a software engineer and a code hacker, so while I appreciate and take advantage of patterns and frameworks, I can usually get by without. In the case of a URI scheme, as Sean said earlier, our document model (write the ABNF) and the URI definition model (define a subset of RFC 3986) don't line up. Because the patterns don't work, I've gone with the approach of developing prototypes that swing back and forth until they focus on the (local?) maximal solution= . Having (at least in my mind, and in local incomplete drafts) resolved the issue of "c|/", and having some way forward for UNC, the remaining fuzzy parts are the query and fragment. Nobody uses queries, so there's no point adding them in. Fragments are currently out, because I was advised early on to leave them out. The fuzziness is how to do it while remaining compatible with both the document and definition models. What I've seen, having looked at other schemes written or revised since RFC 3986, is that they all seem to dance around the relationship with RFC 3986. 'dns' keeps the subtleties implicit, 'acct' only says it borrows syntactic elements, 'stun' goes out of its way to say RFC 3986 doesn't apply, 'geo' doesn't even mention it, etc. Maybe that just means I'm overthinking it. --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11c003c048e8b7050dd18cd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 29 January 2015 at 20:46, t.petch <ietfc@btconnect.com&g= t; = wrote:
----- Original Message -----
From: "Matthew Kerwin" <matthew@kerwin.net.au>
To: "Roy T. Fielding" <fi= elding@gbiv.com>
Cc: "IETF Apps Discuss" <apps-discuss@ietf.org>
Sent: Thursday, January 29, 2015 5:14 AM
<= br>
I'm still suffering a misalignment: RFC 3986 defines the whole generic<= br> URI
syntax as:

=C2=A0 =C2=A0 URI =3D scheme ":" hier-part [ "?" query = ] [ "#" fragment ]

and my draft that references it essentially defines (or will soon
define)
the whole file-URI syntax as:

=C2=A0 =C2=A0 file-URI =3D subset-of-scheme ":" subset-of-hier-pa= rt

By leaving off the query part, I've either said that a URI with a query=
part cannot be a 'file' URI, or that a URI that starts with "f= ile:" and
has
a query part is invalid. Potayto potahto.

<tp>

When I read your I-D, I assumed that you knew what you were doing:-)=C2=A0 = I
can see a use for 'query' but if noone implements it, then better t= he
I-D left it out.=C2=A0 But I did have it as a point to pursue, once the
bigger issue, to me, of splitting what is valid according to RFC3986
from what is not and seeing that reflected in the I-D (and of course,
there is the mini-charter to agree:-(

Tom Petch

</tp>
=E2=80=8B=E2=80=8B



=
Ouch ;) To be honest, I think I thought I knew more than I really = did. I'd like to think that, as I've discovered holes in my knowled= ge I've also filled them. Also in my defense, I've not had enough s= leep the past week.

Part of my problem is = that I'm somewhere between a software engineer and a code hacker, so wh= ile I appreciate and take advantage of patterns and frameworks, I can usual= ly get by without. In the case of a URI scheme, as Sean said earlier, our d= ocument model (write the ABNF) and the URI definition model (define a subse= t of RFC 3986) don't line up. Because the patterns don't work, I= 9;ve gone with the approach of developing prototypes that swing back and fo= rth until they focus on the (local?) maximal solution.

Having (at least in my mind, and in local incomplete drafts) r= esolved the issue of "c|/", and having some way forward for UNC, = the remaining fuzzy parts are the query and fragment. Nobody uses queries, = so there's no point adding them in. Fragments are currently out, becaus= e I was advised early on to leave them out. The fuzziness is how to do it w= hile remaining compatible with both the document and definition models.

What I've seen, having looked at ot= her schemes written or revised since RFC 3986, is that they all seem to dan= ce around the relationship with RFC 3986. 'dns' keeps the subtletie= s implicit, 'acct' only says it borrows syntactic elements, 'st= un' goes out of its way to say RFC 3986 doesn't apply, 'geo'= ; doesn't even mention it, etc. Maybe that just means I'm overthink= ing it.


--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.= au/
--001a11c003c048e8b7050dd18cd7-- From nobody Thu Jan 29 15:49:20 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62351A1AB8 for ; Thu, 29 Jan 2015 15:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlAkoKIliLjw for ; Thu, 29 Jan 2015 15:49:17 -0800 (PST) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.231]) by ietfa.amsl.com (Postfix) with ESMTP id 360F81A00D4 for ; Thu, 29 Jan 2015 15:49:16 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:15927] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 4F/4F-17738-BF6CAC45; Thu, 29 Jan 2015 23:49:16 +0000 Received: from [192.168.1.115] (cpe-098-027-051-253.nc.res.rr.com [98.27.51.253]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 755721401E4; Thu, 29 Jan 2015 18:49:16 -0500 (EST) Message-ID: <54CAC6FA.3000902@intertwingly.net> Date: Thu, 29 Jan 2015 18:49:14 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Matthew Kerwin References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] the URI definition model (was: Fun with URLs and regex) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jan 2015 23:49:18 -0000 On 01/29/2015 04:55 PM, Matthew Kerwin wrote: > > Having (at least in my mind, and in local incomplete drafts) resolved > the issue of "c|/", and having some way forward for UNC, the remaining > fuzzy parts are the query and fragment. Nobody uses queries, so there's > no point adding them in. Fragments are currently out, because I was > advised early on to leave them out. The fuzziness is how to do it while > remaining compatible with both the document and definition models. Permit me to provide a use case for both queries and fragments? In a recent discussion with Tim Berners-Lee, he described a use case for file: URIs, namely developing an HTML application locally (using only relative references), and being able to push that code to a server and have it "just work" when served over HTTP. HTML applications may include stylesheets and scripts. Scripts, when running, may do interesting things based on the query and fragment. The fragment, in particular, is routinely (ab)used by so-called "Single Page Applications". - Sam Ruby From nobody Fri Jan 30 02:29:28 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14CF1A8AB8 for ; Fri, 30 Jan 2015 02:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.56 X-Spam-Level: * X-Spam-Status: No, score=1.56 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqsG3kKCAOuP for ; Fri, 30 Jan 2015 02:29:25 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 595021A8AB7 for ; Fri, 30 Jan 2015 02:29:25 -0800 (PST) Received: from netb ([89.204.138.242]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lm7MT-1Xho4S1Mg5-00Zi1z; Fri, 30 Jan 2015 11:29:12 +0100 From: Bjoern Hoehrmann To: Sam Ruby Date: Fri, 30 Jan 2015 11:29:06 +0100 Message-ID: References: <54CAC6FA.3000902@intertwingly.net> In-Reply-To: <54CAC6FA.3000902@intertwingly.net> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:D8+zuOeNlStRqix7JUG0Dl57ZQqumE4MMlaSZKVD/3P9tA4Ozhl OxtB855R8HPf9YvaVDvsn891EnkPPvH3Pjy039YSJud62qCtUXgLYfgKhoo8ynsdVZYmpez EQNgL8YwUYwgG6QDKK3ceug9nAXKSRxG5hoH/pB7A7HdLxmsb+Api4ZT7xsa0NfVCxTKwNG UrMfkZZNAWracW4WyzYFA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] the URI definition model (was: Fun with URLs and regex) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jan 2015 10:29:27 -0000 * Sam Ruby wrote: >Permit me to provide a use case for both queries and fragments? > >In a recent discussion with Tim Berners-Lee, he described a use case for >file: URIs, namely developing an HTML application locally (using only >relative references), and being able to push that code to a server and >have it "just work" when served over HTTP. > >HTML applications may include stylesheets and scripts. Scripts, when >running, may do interesting things based on the query and fragment. The >fragment, in particular, is routinely (ab)used by so-called "Single Page >Applications". You can always use fragment identifiers regardless of the scheme used. As for query strings, I would not be surprised if question marks are interpreted as path data in many implementations. Either way, the use case above was a valid one a decade ago, but nowadays it is so often necessary, and much easier than in the past, to actually use `http` or in fact `https` in the near future, that `file://` is not a plausible way to develop, starting with the inability to use `XMLHttpRequest` on `file://` in some browsers. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de D-10243 Berlin PGP Pub. KeyID: 0xA4357E78 http://www.bjoernsworld.de Available for hire in Berlin (early 2015) http://www.websitedev.de/ From nobody Fri Jan 30 15:51:29 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13191A87DF for ; Fri, 30 Jan 2015 15:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4SJfFFwdD5w for ; Fri, 30 Jan 2015 15:51:26 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::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 0AB701A877A for ; Fri, 30 Jan 2015 15:51:25 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id h11so5938304wiw.0 for ; Fri, 30 Jan 2015 15:51:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=SpBekIKC8KT+aeiyho0xHa9QuIERp9A+bgGODVl4ZuU=; b=qQDRMtHzyjJNg7JIZvwdB4KO8M1Gjm2+eIIVCbnJAqEgStPUc66gOGxiXxJorNr8Lk JfSmQ2p5hFeSvOdeTWr1iDLvSNYa24l5NS9BKJggwOJMv7peAhD+KL0vDMGUWzcBC9dz +ECwGnGCjaum/gBXoRZlGOyg6wtkt2CAGK3gaGbjMdldyIZ8vXHbzW4KXOKnkr4hDSB7 6kNdwVvzKk/OZxCzEOBugLPkp/OuIgXLvsNKbDwTJOUWJ1Ja/gYT8MYtEmXgnFYU8N1P XrbrF4fWo02SrF5mbK6R2MYiYojqLrhSmD+cmmBamvIQLIbUfLw/cYmepIFlE9Q4lE9B e+SA== MIME-Version: 1.0 X-Received: by 10.194.86.135 with SMTP id p7mr16955891wjz.89.1422661883601; Fri, 30 Jan 2015 15:51:23 -0800 (PST) Received: by 10.27.85.157 with HTTP; Fri, 30 Jan 2015 15:51:23 -0800 (PST) In-Reply-To: References: Date: Fri, 30 Jan 2015 15:51:23 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e0102e498352a71050de74876 Archived-At: Subject: Re: [apps-discuss] Call For Adoption: draft-seantek-text-markdown-use-cases X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jan 2015 23:51:27 -0000 --089e0102e498352a71050de74876 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 9, 2015 at 12:16 PM, Murray S. Kucherawy wrote: > This note starts a Call For Adoption for > draft-seantek-text-markdown-use-cases. This work was split from > draft-ietf-appsawg-text-markdown which is already undergoing processing > through APPSAWG. > > Note that a Call For Adoption only accepts the document as a first version > for development by the working group. The working group can change it as > it wishes subject to our usual consensus process. > > Please reply with support or objection on this thread by January 23, 2015. > There was exactly one reply on this thread. However, since the WG pushed the author into splitting the main document in this way, we presume that silence means there is consensus to accept the document. Thus the author has been asked to submit it as an APPSAWG item, and we assume it will appear shortly. The document pair will have the same milestone, namely April 2015. Interested participants, please review and comment on both documents soon. There's certainly nothing wrong with us being done with them early. Either way, we need to be able to gauge that there's consensus to publish and that there has been adequate review before we can proceed. -MSK, APPSAWG co-chair --089e0102e498352a71050de74876 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jan 9, 2015 at 12:16 PM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
This note starts a Call For Adoption for draft-seantek-text-markdown-use-cases.=C2=A0 This work was split from = draft-ietf-appsawg-text-markdown which is already undergoing processing thr= ough APPSAWG.

Note that a Call For Adoption only accepts the documen= t as a first version for development by the working group.=C2=A0 The workin= g group can change it as it wishes subject to our usual consensus process.<= br>
Please reply with support or objection on this thread by January 23,= 2015.

There was exactly on= e reply on this thread.=C2=A0 However, since the WG pushed the author into = splitting the main document in this way, we presume that silence means ther= e is consensus to accept the document.=C2=A0 Thus the author has been asked= to submit it as an APPSAWG item, and we assume it will appear shortly.
=
The document pair will have the same milestone, namely April= 2015.=C2=A0 Interested participants, please review and comment on both doc= uments soon.=C2=A0 There's certainly nothing wrong with us being done w= ith them early.=C2=A0 Either way, we need to be able to gauge that there= 9;s consensus to publish and that there has been adequate review before we = can proceed.

-MSK, APPSAWG co-chair

=C2=A0
--089e0102e498352a71050de74876-- From nobody Fri Jan 30 17:03:35 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC671A87F1 for ; Fri, 30 Jan 2015 17:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fTxHh6H2jID for ; Fri, 30 Jan 2015 17:03:30 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 5FC0A1A87E3 for ; Fri, 30 Jan 2015 17:03:30 -0800 (PST) Received: from netb ([89.204.130.253]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Ls7MZ-1XX3cB027r-013uVm; Sat, 31 Jan 2015 02:03:25 +0100 From: Bjoern Hoehrmann To: Matthew Kerwin Date: Sat, 31 Jan 2015 02:03:23 +0100 Message-ID: <3q9ocahuoib4jefhviph72eb7luve7fbna@hive.bjoern.hoehrmann.de> References: <54AEB660.1020701@intertwingly.net> <54C84872.5040902@intertwingly.net> <54C95132.2060402@gmx.de> <154ABFBB-AB8C-447A-89A3-D1746EFBF1C6@gbiv.com> <54C95AF7.6030703@gmx.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:hAlgBZRqJ2DK6cVtwMKs9/jN2H6oCCfW1vetq+crcS+Pu09zstp xyHP77CXYe8K4RBrzO8QyS9ZRC7RC7okamAJ3ylWmB1BKc/S0BbZG+sh6zEYzr5BftqN3pG gk34YtcvIPq8y51J5gMFT3PP3p7yjTqmWdXvRm+80LDffbEWkqu85bMPtvXt4kWnCA3cKim EGZLayE44mOiIxi1wDoDg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fun with URLs and regex X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jan 2015 01:03:33 -0000 * Matthew Kerwin wrote: >I'm still suffering a misalignment: RFC 3986 defines the whole generic URI >syntax as: > > URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] > >and my draft that references it essentially defines (or will soon define) >the whole file-URI syntax as: > > file-URI = subset-of-scheme ":" subset-of-hier-part Think of this as URI = scheme ":" scheme-specific-part [ "#" fragment ] And the logic is: if $scheme is 'file' then whatever is matched by `scheme-specific-part` must also match such and such. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de D-10243 Berlin PGP Pub. KeyID: 0xA4357E78 http://www.bjoernsworld.de Available for hire in Berlin (early 2015) http://www.websitedev.de/ From nobody Fri Jan 30 23:37:04 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FCB1A88AD for ; Fri, 30 Jan 2015 23:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdFk7c1Sdnye for ; Fri, 30 Jan 2015 23:36:50 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 0C7FA1A88BD for ; Fri, 30 Jan 2015 23:36:49 -0800 (PST) Received: from netb ([89.204.130.253]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M4kfR-1XRzeK1EFB-00yur9; Sat, 31 Jan 2015 08:36:47 +0100 From: Bjoern Hoehrmann To: Larry Masinter Date: Sat, 31 Jan 2015 08:36:44 +0100 Message-ID: References: <54B9B78F.3060000@intertwingly.net> <54BB2AB3.5090805@intertwingly.net> <54BBC640.5000607@intertwingly.net> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:OU12r1b8nKTRd8LJIsBYh0G69fnFuQ7tTWwBXSZHNqfkQe2/GiZ mdsPZhW5HsYH8xfTclTu0zgd8Y9z5w/7dBkYo5QKzEzvK6QptYIHG+439D5KrIdHIVS/zku WdQxXJGJ1voUCIiexdYlamCDcdcP6Pi1TuYlK/VmA4JuhmkcjHK+ghVO47iBu8BJxhLBN61 POnLkSksMj13Fo88ztp5Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jan 2015 07:36:54 -0000 * Larry Masinter wrote: >> The primary role of a URI parser is to simply decide if a given >> string is or is not a valid URI. A parser can only be >> RFC3986-compliant in the extent to which it correctly makes >> this determination in accordance with RFC3986. > >I disagree with both these sentences, at least as I understand the >terms "primary role", "parser", "valid", "compliant". > >The primary role of a parser http://en.wikipedia.org/wiki/Parsing#Parser >is to take input data and give a structural representation of the input, >while checking for correct syntax in the process. > >Deciding validity is the role of a http://en.wikipedia.org/wiki/Validator. > >RFC 3986 mainly defines conformance for URIs, and I don't >find any 2119-MUST/MAY/SHOULD for parsers, so >any parser that accepts valid-per-3986 URI input and parses >it successfully could be "conforming", even if also accepts invalid >input. Parsers are based on a language and "parse" input given to them, i.e. p = new Parser(language); result = p.parse(input); If it is not possible to tell from `result` whether `input` is a member of `language` then `p` is not a "`language` parser". To illustrate, the `language` might be `XML`, and `p` could be any of these functions: * while (true) {} * return true; * return true if is_xml(input) or true; * return true if is_xml(input) or is_json(input) or true; In none of these cases would `p` be an "XML parser". And it would not suddenly become one if, in the last example, `or true` were removed. -- Bjrn Hhrmann mailto:bjoern@hoehrmann.de http://bjoern.hoehrmann.de D-10243 Berlin PGP Pub. KeyID: 0xA4357E78 http://www.bjoernsworld.de Available for hire in Berlin (early 2015) http://www.websitedev.de/ From nobody Sat Jan 31 16:31:23 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818FD1A1BE0 for ; Sat, 31 Jan 2015 16:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SA6NkCkV6mVw for ; Sat, 31 Jan 2015 16:31:19 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0089.outbound.protection.outlook.com [65.55.169.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 302341A039C for ; Sat, 31 Jan 2015 16:31:19 -0800 (PST) Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) with Microsoft SMTP Server (TLS) id 15.1.65.19; Sun, 1 Feb 2015 00:31:16 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) by DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) with mapi id 15.01.0065.013; Sun, 1 Feb 2015 00:31:16 +0000 From: Larry Masinter To: Bjoern Hoehrmann Thread-Topic: [apps-discuss] Scope of RFC3986 and successor - what is a URI? Thread-Index: AQHQMK/BbmNYRMhSwEGw8Ys6JgInPJzBF8kAgAAGVICAAAr/AIAAG5asgAAEooCAAAkQgIAAA94AgAA70ACAAB+YgIAAFYKQgAA0mYCAABAxgIABeKuAgAGoDQCAABJigIAAFm7wgACjAQCAABVEQIAT4i8AgAEUTUA= Date: Sun, 1 Feb 2015 00:31:16 +0000 Message-ID: References: <54B9B78F.3060000@intertwingly.net> <54BB2AB3.5090805@intertwingly.net> <54BBC640.5000607@intertwingly.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] authentication-results: gmx.net; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB0960; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB0960; x-forefront-prvs: 04740D25F1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(51704005)(24454002)(13464003)(33656002)(2950100001)(19580405001)(92566002)(2900100001)(16601075003)(87936001)(54206007)(2656002)(46102003)(86362001)(106116001)(76176999)(54356999)(54606007)(50986999)(99286002)(66066001)(587094005)(122556002)(102836002)(15975445007)(110136001)(62966003)(77156002)(93886004)(76576001)(74316001)(18886065003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0960; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2015 00:31:16.0987 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB0960 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 00:31:22 -0000 SSBkb24ndCB0aGluayB0aGVyZSdzIG11Y2ggcG9pbnQgaW4gYXJndWluZyBhYm91dCB0aGUgbWVh bmluZyBvZiBhIHdvcmQgbGlrZSAicGFyc2VyIi4gQ2xlYXJseSB0aGVyZSBhcmUgZGlmZmVyZW50 IG1lYW5pbmdzIGluIHVzZS4gIFlvdSBzYXkNCg0KPiBJZiBpdCBpcyBub3QgcG9zc2libGUgdG8g dGVsbCBmcm9tIGByZXN1bHRgIHdoZXRoZXIgYGlucHV0YCBpcyBhIG1lbWJlcg0KPiBvZiBgbGFu Z3VhZ2VgIHRoZW4gYHBgIGlzIG5vdCBhICJgbGFuZ3VhZ2VgIHBhcnNlciIuDQoNCkJ1dCB0aGlz IGRlZmluaXRpb24gaGFzIG1hbnkgY291bnRlci1leGFtcGxlcywgbGFuZ3VhZ2VzIHdoZXJlIGNv bmZvcm1pbmcgcGFyc2VycyBmb3IgdGhhdCBsYW5ndWFnZSBkbyBub3QgdXN1YWxseSwgb3IgZXZl ciwgc2lnbmFsIHZhbGlkaXR5IGVycm9ycy4gU3RhcnQgd2l0aCBIVE1MNS4gSW4gZmFjdCwgZm9y IG1vc3QgbWltZSB0eXBlcywgbW9zdCBwYXJzZXJzIGFyZSBtb3JlIGZvcmdpdmluZyB0aGFuIHN0 cmljdC4NCg0KQnV0IHdoZXRoZXIgb3Igbm90IGEgcGFyc2VyIGNoZWNrcyB2YWxpZGl0eSwgaXQg aXMgcmFyZSB0aGF0ICJ0aGUgUFJJTUFSWSByb2xlIG9mIGEgVVJJIHBhcnNlciBpcyB0byBTSU1Q TFkgIERFQ0lERSAgcGFyc2VyIGlzIHRvIHNpbXBseSBkZWNpZGUgaWYgYSBnaXZlbiBzdHJpbmcg aXMgb3IgaXMgbm90IGEgdmFsaWQgVVJJIiAoZW1waGFzaXMgbWluZSkuIFRoZSBwcmltYXJ5IHJv bGUgb2YgYSBwYXJzZXIgaXMgdG8gYmUgdGhlIGZpcnN0IHN0YWdlIG9mICJQYXJzZSBhbmQgaW50 ZXJwcmV0Ii4gVmFsaWRpdHkgY2hlY2tpbmcgKHNvIHlvdSBkb24ndCBzdHVmZiBpbnZhbGlkIGRh dGEgdG8gdGhlIGludGVycHJldGVyKSBpcyBhIG5pY2UtdG8taGF2ZS4gDQoNCg0KDQoNCiJBIHBh cnNlciBjYW4gb25seSBiZSBSRkMzOTg2LWNvbXBsaWFudCBpbiB0aGUgZXh0ZW50IHRvIHdoaWNo IGl0IGNvcnJlY3RseSBtYWtlcyB0aGlzIGRldGVybWluYXRpb24gaW4gYWNjb3JkYW5jZSB3aXRo IFJGQzM5ODYiDQoNCkp1c3QgdG8gbWFrZSBzdXJlIHdlJ3JlIHVzaW5nIHRoZSBzYW1lIHZvY2Fi dWxhcnk6DQoNCldlIHVzdWFsbHkgdGFsayBhYm91dCAiY29uZm9ybWFuY2UiIGFuZCBub3QgImNv bXBsaWFuY2UiLCBJIHRoaW5rLiBBIHNwZWNpZmljYXRpb24gaGFzIGEgc2NvcGUgYW5kIGRlZmlu ZXMgcm9sZXMsIGFuZCBjb25mb3JtYW5jZSByZXF1aXJlbWVudHMgZm9yIGFnZW50cyB0aGF0IGZp bGwgdGhvc2Ugcm9sZXMuIFdpdGggYSBsYW5ndWFnZSBvciBwcm90b2NvbCBlbGVtZW50IGtpbmQg b2YgZGVmaW5pdGlvbiwgdGhlIHJvbGVzIHVzdWFsbHkgaW5jbHVkZSAid3JpdGVyIiwgInJlYWRl ciIsICJ2YWxpZGF0b3IiLiBBIHJlYWRlciBkb2VzIHBhcnNpbmcgKHRoZSBwYXJzZXIgcGFydCkg YW5kIGludGVycHJldGluZyAodGhlIHBhcnQgdGhhdCBkb2VzIHNvbWV0aGluZyB3aXRoIHRoZSBw YXJzZWQgY29tcG9uZW50cyB0aGF0IGFyZSB0aGUgcmVzdWx0IG9mIHBhcnNpbmcuDQoNCklmIHlv dSBhZ3JlZSB3aXRoIHRob3NlIGRlZmluaXRpb25zLCB0aGVuIGl0IGlzIHJlYXNvbmFibGUgdG8g bm90IHJlcXVpcmUgY29uZm9ybWluZyByZWFkZXJzIHRvIG5vdCBiZSAibGliZXJhbCBpbiB3aGF0 IHRoZXkgYWNjZXB0IiwgYW5kIFJGQyAzOTg2IG1ha2VzIG5vIGV4cGxpY2l0IGNvbmZvcm1hbmNl IHJlcXVpcmVtZW50IGZvciBwYXJzZXJzIHVzZWQgYnkgcmVhZGVycyBvZiB0aGUgVVJJIHByb3Rv Y29sIGVsZW1lbnQuDQoNCkxhcnJ5DQotLQ0KaHR0cDovL2xhcnJ5Lm1hc2ludGVyLm5ldA0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJqb2VybiBIb2Vocm1hbm4gW21h aWx0bzpkZXJob2VybWlAZ214Lm5ldF0NCj4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDMwLCAyMDE1 IDExOjM3IFBNDQo+IFRvOiBMYXJyeSBNYXNpbnRlcg0KPiBDYzogU2FtIFJ1Ynk7IGFwcHMtZGlz Y3Vzc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gU2NvcGUgb2YgUkZD Mzk4NiBhbmQgc3VjY2Vzc29yIC0gd2hhdCBpcyBhDQo+IFVSST8NCj4gDQo+ICogTGFycnkgTWFz aW50ZXIgd3JvdGU6DQo+ID4+ICAgICAgICAgVGhlIHByaW1hcnkgcm9sZSBvZiBhIFVSSSBwYXJz ZXIgaXMgdG8gc2ltcGx5IGRlY2lkZSBpZiBhIGdpdmVuDQo+ID4+ICAgICAgICAgc3RyaW5nIGlz IG9yIGlzIG5vdCBhIHZhbGlkIFVSSS4gIEEgcGFyc2VyIGNhbiBvbmx5IGJlDQo+ID4+ICAgICAg ICAgUkZDMzk4Ni1jb21wbGlhbnQgaW4gdGhlIGV4dGVudCB0byB3aGljaCBpdCBjb3JyZWN0bHkg bWFrZXMNCj4gPj4gICAgICAgICB0aGlzIGRldGVybWluYXRpb24gaW4gYWNjb3JkYW5jZSB3aXRo IFJGQzM5ODYuDQo+ID4NCj4gPkkgZGlzYWdyZWUgd2l0aCBib3RoIHRoZXNlIHNlbnRlbmNlcywg YXQgbGVhc3QgYXMgSSB1bmRlcnN0YW5kIHRoZQ0KPiA+dGVybXMgInByaW1hcnkgcm9sZSIsICJw YXJzZXIiLCAidmFsaWQiLCAiY29tcGxpYW50Ii4NCj4gPg0KPiA+VGhlIHByaW1hcnkgcm9sZSBv ZiBhIHBhcnNlcg0KPiBodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL1BhcnNpbmcjUGFyc2Vy DQo+ID5pcyB0byB0YWtlIGlucHV0IGRhdGEgYW5kIGdpdmUgYSBzdHJ1Y3R1cmFsIHJlcHJlc2Vu dGF0aW9uIG9mIHRoZSBpbnB1dCwNCj4gPndoaWxlIGNoZWNraW5nIGZvciBjb3JyZWN0IHN5bnRh eCBpbiB0aGUgcHJvY2Vzcy4NCj4gPg0KPiA+RGVjaWRpbmcgdmFsaWRpdHkgaXMgdGhlIHJvbGUg b2YgYSBodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL1ZhbGlkYXRvci4NCj4gPg0KPiA+UkZD IDM5ODYgbWFpbmx5IGRlZmluZXMgY29uZm9ybWFuY2UgZm9yIFVSSXMsIGFuZCBJIGRvbid0DQo+ ID5maW5kIGFueSAyMTE5LU1VU1QvTUFZL1NIT1VMRCBmb3IgcGFyc2Vycywgc28NCj4gPmFueSBw YXJzZXIgdGhhdCBhY2NlcHRzIHZhbGlkLXBlci0zOTg2IFVSSSBpbnB1dCBhbmQgcGFyc2VzDQo+ ID5pdCBzdWNjZXNzZnVsbHkgY291bGQgYmUgImNvbmZvcm1pbmciLCAgZXZlbiBpZiBhbHNvIGFj Y2VwdHMgaW52YWxpZA0KPiA+aW5wdXQuDQo+IA0KPiBQYXJzZXJzIGFyZSBiYXNlZCBvbiBhIGxh bmd1YWdlIGFuZCAicGFyc2UiIGlucHV0IGdpdmVuIHRvIHRoZW0sIGkuZS4NCj4gDQo+ICAgcCA9 IG5ldyBQYXJzZXIobGFuZ3VhZ2UpOw0KPiAgIHJlc3VsdCA9IHAucGFyc2UoaW5wdXQpOw0KPiAN Cj4gSWYgaXQgaXMgbm90IHBvc3NpYmxlIHRvIHRlbGwgZnJvbSBgcmVzdWx0YCB3aGV0aGVyIGBp bnB1dGAgaXMgYSBtZW1iZXINCj4gb2YgYGxhbmd1YWdlYCB0aGVuIGBwYCBpcyBub3QgYSAiYGxh bmd1YWdlYCBwYXJzZXIiLiBUbyBpbGx1c3RyYXRlLCB0aGUNCj4gYGxhbmd1YWdlYCBtaWdodCBi ZSBgWE1MYCwgYW5kIGBwYCBjb3VsZCBiZSBhbnkgb2YgdGhlc2UgZnVuY3Rpb25zOg0KPiANCj4g ICAqIHdoaWxlICh0cnVlKSB7fQ0KPiAgICogcmV0dXJuIHRydWU7DQo+ICAgKiByZXR1cm4gdHJ1 ZSBpZiBpc194bWwoaW5wdXQpIG9yIHRydWU7DQo+ICAgKiByZXR1cm4gdHJ1ZSBpZiBpc194bWwo aW5wdXQpIG9yIGlzX2pzb24oaW5wdXQpIG9yIHRydWU7DQo+IA0KPiBJbiBub25lIG9mIHRoZXNl IGNhc2VzIHdvdWxkIGBwYCBiZSBhbiAiWE1MIHBhcnNlciIuIEFuZCBpdCB3b3VsZCBub3QNCj4g c3VkZGVubHkgYmVjb21lIG9uZSBpZiwgaW4gdGhlIGxhc3QgZXhhbXBsZSwgYG9yIHRydWVgIHdl cmUgcmVtb3ZlZC4NCj4gLS0NCj4gQmrDtnJuIEjDtmhybWFubiDCtyBtYWlsdG86YmpvZXJuQGhv ZWhybWFubi5kZSDCtw0KPiBodHRwOi8vYmpvZXJuLmhvZWhybWFubi5kZQ0KPiBELTEwMjQzIEJl cmxpbiDCtyBQR1AgUHViLiBLZXlJRDogMHhBNDM1N0U3OCDCtw0KPiBodHRwOi8vd3d3LmJqb2Vy bnN3b3JsZC5kZQ0KPiAgQXZhaWxhYmxlIGZvciBoaXJlIGluIEJlcmxpbiAoZWFybHkgMjAxNSkg IMK3IGh0dHA6Ly93d3cud2Vic2l0ZWRldi5kZS8NCg==