From nobody Mon Dec 1 08:10:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619651A6EEC for ; Mon, 1 Dec 2014 08:09: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, 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 tVSPuCmCPeUd for ; Mon, 1 Dec 2014 08:09:50 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE351A6F0D for ; Mon, 1 Dec 2014 08:09:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 7E9484E0354; Mon, 1 Dec 2014 11:09:48 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmYeBM55Hlt4; Mon, 1 Dec 2014 11:09:48 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id EFAA44E034A; Mon, 1 Dec 2014 11:09:46 -0500 (EST) Date: Mon, 01 Dec 2014 11:09:38 -0500 From: Cyrus Daboo To: Mark Nottingham Message-ID: <3CB2CD6CAE75ED3194EFFFFC@caldav.corp.apple.com> In-Reply-To: <68CDCC24-7A32-4B41-BBE7-428998D2D4C7@mnot.net> References: <68CDCC24-7A32-4B41-BBE7-428998D2D4C7@mnot.net> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=2400 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6hu6OFKeJF9LkUNCD5X2Y8dGolQ Cc: IETF Apps Discuss Subject: Re: [apps-discuss] ietf-appsawg-http-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2014 16:09:56 -0000 Hi Mark, --On November 23, 2014 at 2:33:51 PM +1100 Mark Nottingham =20 wrote: >> I recently added a normative reference to ietf-appsawg-http-problem in >> draft-ietf-tzdist-service-03. I know the chairs of TZDIST are keen to >> complete work on that draft and send it to the IESG, but of course we >> will want ietf-appsawg-http-problem to progress too. So what is the >> status of that draft in appsawg? I did not that Murray had asked for a >> shepherd - if none has been assigned I am happy to volunteer to do that >> to help move it along. > > I think Alexey is shepherding. OK, good. I would like to see this draft move along so as not to block=20 progress of tzdist. >> However, I do have one issue with the current draft: the TZDIST protocol >> is primarily a non-human HTTP protocol. tzdist defines its own set of >> error codes (e.g., "invalid-start", "tzid-not-found", etc) to better >> identify problems in requests. However, http-problem only defines a >> "type" member that is a URI that references a "human-readable" resource. > > Well, that=E2=80=99s a guideline. A bit of text that allows = machine-readable > responses too =E2=80=94 whether that be HTML micro data or another format = via > conneg =E2=80=94 might help. > > All of that said, what=E2=80=99s your use case for a machine readable = response? > Fetching the error resources at runtime seems like a bad practice, as > it=E2=80=99s going to cause load on the server, as well as more chances = for > failure... Right - I don't think there is a need to have a "fetchable" URI as the=20 error code, but rather a "token" defined by the protocol specification that = clearly identifies the type of the error. I would be OK with using=20 something other than an HTTP URI in "type" (instead of inventing the=20 "error-code" member as I did) - but then the question is what is an=20 appropriate error code to use? I guess we could define=20 "urn:ietf:tzdist:error-code:" as a prefix for error code URIs which can=20 appear as values in the problem report "type" member. >> As a result I added an "error-code" member for the tzdist specific >> codes. I wonder if it makes sense to include that in http-problem to >> cover similar use cases? > > That seems like an anti-pattern; having two identifiers for the same > thing leads to problems. Agreed - but then we need to decide what form an "error code" will take=20 when used in the "type" member. --=20 Cyrus Daboo From nobody Mon Dec 1 08:56:40 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FAC1A6FFC for ; Mon, 1 Dec 2014 08:56:38 -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 cl019gpHcGDp for ; Mon, 1 Dec 2014 08:56:37 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001: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 EF4851A6FEC for ; Mon, 1 Dec 2014 08:56:36 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id rd18so9768789iec.29 for ; Mon, 01 Dec 2014 08:56:36 -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=3Oxh3Lr+y9gesQLetMNjwv7dbSouvByb8SOvEP+Wcew=; b=sCfHsJzPvzquBht3ml5O7+HhpwYnQM9+QeyMaMCCmBvwN7OP8h4zr1i1MESGxL/IaQ 7GIB2vOJRlioaAWmTWPGgaJE3cj4V2tHYi27Y80rQkyR8w3WIKA/veDTUkoh1Jazg4u4 JLowgCLXiMM4SwvRogIHARaAKvVaNbOa9EfgX18HPz7fJNRZKHmE0mmo38l1fQLbw8vY 80XieZiuB37pKwYBjvMJEf6+5WSmPLdnHPWMp0zb8d2gxtVEdJikpRL2Y7wtZufwNX4S rm2Ula/ePuZ5b4OslsBRqjgHmdNysRgBUt3d2M0aKJiUmmIGyrAWuWjm3FeSz32mO2BL 2dSw== MIME-Version: 1.0 X-Received: by 10.107.5.76 with SMTP id 73mr16391421iof.74.1417452996120; Mon, 01 Dec 2014 08:56:36 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.173.83 with HTTP; Mon, 1 Dec 2014 08:56:36 -0800 (PST) In-Reply-To: <20141201163841.9953.4710.idtracker@ietfa.amsl.com> References: <20141201163841.9953.4710.idtracker@ietfa.amsl.com> Date: Mon, 1 Dec 2014 11:56:36 -0500 X-Google-Sender-Auth: IH5kZF5Yiv2BgWcb_XcHDjIR5ks Message-ID: From: Barry Leiba To: HTTP Working Group , "apps-discuss@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/2X3foIXwUfvWYd8z4daD100FPio Subject: [apps-discuss] Fwd: Last Call: (HTTP Status Code 308 (Permanent Redirect) to Proposed Standard (from Experimental)) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2014 16:56:38 -0000 Please note the following last call. As it says there, please send any comments to (not to the http or apps-discuss list). Barry ---------- Forwarded message ---------- From: The IESG Date: Mon, Dec 1, 2014 at 11:38 AM Subject: Last Call: (HTTP Status Code 308 (Permanent Redirect) to Proposed Standard (from Experimental)) To: IETF-Announce Cc: iesg@ietf.org The IESG has received a request from the Internet Engineering Steering Group WG (iesg) to consider the following document: - 'HTTP Status Code 308 (Permanent Redirect) to Proposed Standard' from Experimental The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-12-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In 2012, when RFC 7238 was approved, we went for Experimental because it was, indeed, an experiment. Since then, it has been implemented in Firefox and Chrome, and Safari already supported it due to their default handling of 3xx + Location. The experiment is, therefore, over, and was a success. This action moves RFC 7238 to the Standards Track, as Proposed Standard. The file can be obtained via http://datatracker.ietf.org/doc/status-change-http-status-code-308-ps/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/status-change-http-status-code-308-ps/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Dec 1 11:27:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965001A899D for ; Mon, 1 Dec 2014 11:27:40 -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 v_7wPXyCPaHZ for ; Mon, 1 Dec 2014 11:27:38 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5829D1A8994 for ; Mon, 1 Dec 2014 11:27:38 -0800 (PST) Received: from [192.168.1.83] (unknown [118.209.194.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5CC2E50A84; Mon, 1 Dec 2014 14:27:33 -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: <3CB2CD6CAE75ED3194EFFFFC@caldav.corp.apple.com> Date: Tue, 2 Dec 2014 06:27:30 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <01D6D6E4-744A-41A5-BE69-38848514F70C@mnot.net> References: <68CDCC24-7A32-4B41-BBE7-428998D2D4C7@mnot.net> <3CB2CD6CAE75ED3194EFFFFC@caldav.corp.apple.com> To: Cyrus Daboo X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iSGYG8IW_5h5s1c5JGAu-TrTCrk Cc: IETF Apps Discuss Subject: Re: [apps-discuss] ietf-appsawg-http-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2014 19:27:40 -0000 > On 2 Dec 2014, at 3:09 am, Cyrus Daboo wrote: >=20 > Hi Mark, >=20 > --On November 23, 2014 at 2:33:51 PM +1100 Mark Nottingham = wrote: >=20 >>> I recently added a normative reference to ietf-appsawg-http-problem = in >>> draft-ietf-tzdist-service-03. I know the chairs of TZDIST are keen = to >>> complete work on that draft and send it to the IESG, but of course = we >>> will want ietf-appsawg-http-problem to progress too. So what is the >>> status of that draft in appsawg? I did not that Murray had asked for = a >>> shepherd - if none has been assigned I am happy to volunteer to do = that >>> to help move it along. >>=20 >> I think Alexey is shepherding. >=20 > OK, good. I would like to see this draft move along so as not to block = progress of tzdist. AIUI we're getting close to WGLC.=20 >>> However, I do have one issue with the current draft: the TZDIST = protocol >>> is primarily a non-human HTTP protocol. tzdist defines its own set = of >>> error codes (e.g., "invalid-start", "tzid-not-found", etc) to better >>> identify problems in requests. However, http-problem only defines a >>> "type" member that is a URI that references a "human-readable" = resource. >>=20 >> Well, that=E2=80=99s a guideline. A bit of text that allows = machine-readable >> responses too =E2=80=94 whether that be HTML micro data or another = format via >> conneg =E2=80=94 might help. >>=20 >> All of that said, what=E2=80=99s your use case for a machine readable = response? >> Fetching the error resources at runtime seems like a bad practice, as >> it=E2=80=99s going to cause load on the server, as well as more = chances for >> failure... >=20 > Right - I don't think there is a need to have a "fetchable" URI as the = error code, but rather a "token" defined by the protocol specification = that clearly identifies the type of the error. I would be OK with using = something other than an HTTP URI in "type" (instead of inventing the = "error-code" member as I did) - but then the question is what is an = appropriate error code to use? I guess we could define = "urn:ietf:tzdist:error-code:" as a prefix for error code URIs which can = appear as values in the problem report "type" member. That would work, if you're uncomfortable using a HTTP URI (it's common = practice to use them for identifiers *without* being fetchable; making = them fetchable after the fact if need be is considered a feature). >>> As a result I added an "error-code" member for the tzdist specific >>> codes. I wonder if it makes sense to include that in http-problem to >>> cover similar use cases? >>=20 >> That seems like an anti-pattern; having two identifiers for the same >> thing leads to problems. >=20 > Agreed - but then we need to decide what form an "error code" will = take when used in the "type" member. >=20 > --=20 > Cyrus Daboo >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Dec 2 09:00:12 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B921A1EF9; Tue, 2 Dec 2014 09:00:03 -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 fBvCWI98X_bg; Tue, 2 Dec 2014 08:59:56 -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 6AE5E1A1DFA; Tue, 2 Dec 2014 08:59:56 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id k14so17341006wgh.24 for ; Tue, 02 Dec 2014 08:59:55 -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:cc:content-type; bh=HDQ+B7JktLkI1GE4+qvkl8g2EtAtnzZbAT3yAAbdbrk=; b=ykti1KjdZThtq1yaeND3SoBTcGfnWPp0I/d8Qaj0eBfpAWx8cU9dYLJku2u3pwLfqE EYOBOwxFuxkulC27gz9bOx8aHE9m+OZp5W8u0kBT8RkxZDC3xW1cwV39FlObX+qoHnIA 6hYtScgijlKFHWzgiX9UacRp59hm2Lug2TywTbv4rFTYJ3CvscrZeX+5UyMJm8gMM9m/ JcZaf4s1CjIq4kI486V+qIGaggis8Q7oEOl81ubQmfc1oId3bYnrT1RD+ev1/+xmJ0Nk cJc50rN1z31Fm8r0lcMqi/6G30rfzDQZIzHhaBjlfjcv6mWuC1FiJ+wTW/m+i6Hv17+J c5zg== MIME-Version: 1.0 X-Received: by 10.180.211.201 with SMTP id ne9mr6705805wic.30.1417539595162; Tue, 02 Dec 2014 08:59:55 -0800 (PST) Received: by 10.27.76.134 with HTTP; Tue, 2 Dec 2014 08:59:55 -0800 (PST) Date: Tue, 2 Dec 2014 08:59:55 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss , dnsop@ietf.org Content-Type: multipart/alternative; boundary=001a11c266d60659bd05093ea85a Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3RCSaLJUABVjy5gtDW9az7udHAA Cc: "dbound@ietf.org" Subject: [apps-discuss] Proposed charter for DBOUND WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2014 17:00:04 -0000 --001a11c266d60659bd05093ea85a Content-Type: text/plain; charset=UTF-8 Colleagues, Below is a proposed charter for a working group we're calling DBOUND, which is seeking to solve the problem of finding a way to identify administrative/organizational boundaries in the domain namespace. We'd like to get some feedback from outside the team of people that's been working on it. For the sake of tracking the feedback, please reply only to apps-discuss@ietf.org with any comments you may have. -MSK, APPSAWG co-chair dbound charter Various Internet protocols and applications require some mechanism for determining whether two domain names are related. A popular example is the need to determine whether example.com and foo.example.com, or evenexample.net, are subject to the same administrative control. To humans, the answer to this may be obvious. However, the Domain Name System (DNS), which is the service that handles domain name queries, does not provide the ability to mark these sorts of relationships. This makes it impossible to discern relationships algorithmically. For example, the right answer is not always "compare the rightmost two labels". The particular issue is that applications and organizations impose policies and procedures that create additional structure in their use of domain names. This creates many possible relationships that are not evident in the names themselves or in the operational, public representation of the names. Prior solutions for identifying relationships between domain names have sought to use the DNS namespace and protocol to extract that information when it isn't actually there; the concept of an administrative boundary is by definition not present in the DNS. Relying on the DNS to divine administrative structure thus renders such solutions unreliable and unnecessarily constrained. For example, confirming or dismissing a relationship between two domain names based on the existence of a zone cut or common ancestry is often unfounded, and the notion of an upward "tree walk" as a search mechanism is considered unacceptable. For the purposes of this work, domain names are approached as identifiers used by organizations and services, independent of underlying protocols or mechanisms. Specifically, the work will not propose any changes to DNS protocols except the possible creation of new resource record types (RRTYPES). Furthermore, we define an "organizational domain" to be a name that is at the top of an administrative hierarchy, defining transition from one "outside" administrative authority to another that is "inside" the organization. Currently, the most well known solution in existence is the Public Suffix List (PSL). The PSL is maintained by a Web browser producer and is kept current by volunteers on a best-effort basis. It contains a list of points in the hierarchical namespace at which registrations take place, and is used to identify the boundary between so-called "public" names (below which registrations can occur) and the private names (i.e., organizational names) below them. When this list is inaccurate, it exposes a deviation from reality that degrades service to some and can be exploited by others. Being the de facto resource, and lacking a more comprehensive, alternative solution for relationship identification, the functionality of the PSL has often been misused to accomplish means beyond its capabilities. For example, there is no way to confirm the relationship between two domain names, only signal that there is or is not a public boundary between the two. Additionally, there are questions about the scalability, central management, and third-party management of the PSL as it currently exists. In terms of specific use cases: Within the realm of email, there is a desire to link an arbitrary fully-qualified domain name (FQDN) to the organizational domain name (at some point in the namespace above it), in order to identify a deterministic location where some sort of statement of policy regarding that FQDN can be found. With respect to the web, there is a similar need to identify relationships between different FQDNs, currently accomplished by comparing ancestries. However, there is also desire to reliably identify relationships outside of the realm and constraints of the namespace tree. Previous work such as Author Domain Signing Practices (ADSP; RFC5617), and current work such as DMARC (draft-kucherawy-dmarc-base), would certainly benefit from having this capability. The DBOUND working group will develop one or more solutions to this family of problems. If possible, a unified solution will be developed. However, the working group may discover that the email, web, equivalence, and possibly other problems require independent solutions, in which case the working group will follow that path. The solutions may or may not involve changes to the DNS, such as creation of new resource record types; in any case, all such changes will be incremental only. This working group will not seek to amend the consuming protocols themselves (i.e., any web or mail standards) without rechartering, and only after completion of the base work. Any such work undertaken in parallel will eeed to be done as individual or independent submissions, or in another working group. Milestones: - TBD Co-chairs: - TBD --001a11c266d60659bd05093ea85a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

Below is a propose= d charter for a working group we're calling DBOUND, which is seeking to= solve the problem of finding a way to identify administrative/organization= al boundaries in the domain namespace.=C2=A0 We'd like to get some feed= back from outside the team of people that's been working on it.

=
For the sake of tracking the feedback, please reply only to apps-discuss@ietf.org with any commen= ts you may have.

-MSK, APPSAWG co-chair

dbound cha=
rter

Various Internet protocols and applications require some mechanism for
determining whether two domain names are related.  A popular example is
the need to determine whether example.com and foo.example.com, or even
example.net, are subject to the same adm=
inistrative control.  To humans,
the answer to this may be obvious.  However, the Domain Name System (DNS),
which is the service that handles domain name queries, does not provide
the ability to mark these sorts of relationships.  This makes it
impossible to discern relationships algorithmically.  For example, the
right answer is not always "compare the rightmost two labels".

The particular issue is that applications and organizations impose
policies and procedures that create additional structure in their use of
domain names.  This creates many possible relationships that are not
evident in the names themselves or in the operational, public
representation of the names.

Prior solutions for identifying relationships between domain names
have sought to use the DNS namespace and protocol to extract that
information when it isn't actually there; the concept of an administrat=
ive
boundary is by definition not present in the DNS.  Relying on the DNS to=20
divine administrative structure thus renders such solutions unreliable and
unnecessarily constrained.  For example, confirming or dismissing a
relationship between two domain names based on the existence of a zone
cut or common ancestry is often unfounded, and the notion of an upward
"tree walk" as a search mechanism is considered unacceptable.

For the purposes of this work, domain names are approached as identifiers
used by organizations and services, independent of underlying protocols
or mechanisms.  Specifically, the work will not propose any changes to
DNS protocols except the possible creation of new resource record types
(RRTYPES).  Furthermore, we define an "organizational domain" to =
be a
name that is at the top of an administrative hierarchy, defining transition
from one "outside" administrative authority to another that is &q=
uot;inside" the
organization.

Currently, the most well known solution in existence is the Public Suffix
List (PSL).  The PSL is maintained by a Web browser producer and is kept
current by volunteers on a best-effort basis.  It contains a list of points
in the hierarchical namespace at which registrations take place, and is
used to identify the boundary between so-called "public" names (b=
elow which
registrations can occur) and the private names (i.e., organizational names)
below them.  When this list is inaccurate, it exposes a deviation from
reality that degrades service to some and can be exploited by others.  Bein=
g
the de facto resource, and lacking a more comprehensive, alternative soluti=
on
for relationship identification, the functionality of the PSL has often bee=
n
misused to accomplish means beyond its capabilities.  For example, there
is no way to confirm the relationship between two domain names, only
signal that there is or is not a public boundary between the two.
Additionally, there are questions about the scalability, central management=
,
and third-party management of the PSL as it currently exists.

In terms of specific use cases: Within the realm of email, there is a
desire to link an arbitrary fully-qualified domain name (FQDN) to the
organizational domain name (at some point in the namespace above it),
in order to identify a deterministic location where some sort of statement
of policy regarding that FQDN can be found.  With respect to the
web, there is a similar need to identify relationships between different
FQDNs, currently accomplished by comparing ancestries.  However, there
is also desire to reliably identify relationships outside of the realm
and constraints of the namespace tree.

Previous work such as Author Domain Signing Practices (ADSP; RFC5617), and
current work such as DMARC (draft-kucherawy-dmarc-base), would certainly
benefit from having this capability.

The DBOUND working group will develop one or more solutions to this family
of problems.  If possible, a unified solution will be developed.  However,
the working group may discover that the email, web, equivalence, and
possibly other problems require independent solutions, in which case the
working group will follow that path.  The solutions may or may not involve
changes to the DNS, such as creation of new resource record types; in any
case, all such changes will be incremental only.

This working group will not seek to amend the consuming protocols themselve=
s
(i.e., any web or mail standards) without rechartering, and only after
completion of the base work.  Any such work undertaken in parallel will
eeed to be done as individual or independent submissions, or in another
working group.

Milestones:
- TBD

Co-chairs:
- TBD

--001a11c266d60659bd05093ea85a-- From nobody Tue Dec 2 13:04:00 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F041A8723; Tue, 2 Dec 2014 13:03: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 6tHq38v97Yaf; Tue, 2 Dec 2014 13:03:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A08EE1A8721; Tue, 2 Dec 2014 13:03:48 -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.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141202210348.12678.14831.idtracker@ietfa.amsl.com> Date: Tue, 02 Dec 2014 13:03:48 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/gWJk9dzG7sVCsZ4CUm3q5Bt_DGM Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-multipart-form-data-07.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: Tue, 02 Dec 2014 21:03:52 -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 : Returning Values from Forms: multipart/form-data Author : Larry Masinter Filename : draft-ietf-appsawg-multipart-form-data-07.txt Pages : 12 Date : 2014-12-02 Abstract: This specification (re)defines the multipart/form-data Internet Media Type, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. It replaces RFC 2388. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-multipart-form-data-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-multipart-form-data-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 2 18:11:21 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFBA1A8941 for ; Tue, 2 Dec 2014 18:11: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] 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 kH6M-3Mtzeyy for ; Tue, 2 Dec 2014 18:10:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 396541A894C for ; Tue, 2 Dec 2014 18:10:46 -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.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141203021046.24341.55424.idtracker@ietfa.amsl.com> Date: Tue, 02 Dec 2014 18:10:46 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6YICOKV_a9-loUpCZiX_KDIAgrw 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: Wed, 03 Dec 2014 02:11:14 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-multipart-form-data", set due date to December 2014 from October 2014. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Tue Dec 2 23:13:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CB01A00B0 for ; Tue, 2 Dec 2014 23:13:05 -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 o89Af5fq7TuI for ; Tue, 2 Dec 2014 23:13:04 -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 0ADA21A0092 for ; Tue, 2 Dec 2014 23:13:04 -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 6F4AD32E534; Wed, 3 Dec 2014 16:12:19 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 2d67_7ae8_c2d53f0f_a7db_451e_99c1_603c6a942366; Wed, 03 Dec 2014 16:12:18 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id C9EF2C0008; Wed, 3 Dec 2014 16:12:18 +0900 (JST) Message-ID: <547EB7D1.3050607@it.aoyama.ac.jp> Date: Wed, 03 Dec 2014 16:12:17 +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" , IETF Apps Discuss References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/krBzDWXO8eYPkrNLID8KudAoz_Y Cc: "www-tag@w3.org" Subject: Re: [apps-discuss] Proposed charter for DBOUND WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 07:13:06 -0000 Hello Murray, Just a few points after a quick read-through. On 2014/12/03 01:59, Murray S. Kucherawy wrote: > Colleagues, > > Below is a proposed charter for a working group we're calling DBOUND, which > is seeking to solve the problem of finding a way to identify > administrative/organizational boundaries in the domain namespace. We'd > like to get some feedback from outside the team of people that's been > working on it. > > For the sake of tracking the feedback, please reply only to > apps-discuss@ietf.org with any comments you may have. I suggest to send this also to public-ietf-w3c@w3.org (W3C/IETF coordination list) and to www-tag@w3.org (W3C TAG public list), and to get the attention of people from the WHATWG. > -MSK, APPSAWG co-chair > > dbound charter The charter is extremely long. I suggest trying to shorten it. I'm sure it's possible. > Various Internet protocols and applications require some mechanism for > determining whether two domain names are related. A popular example is > the need to determine whether example.com and foo.example.com, or > evenexample.net, are subject to the same administrative control. To > humans, > the answer to this may be obvious. However, the Domain Name System (DNS), > which is the service that handles domain name queries, does not provide > the ability to mark these sorts of relationships. This makes it > impossible to discern relationships algorithmically. For example, the > right answer is not always "compare the rightmost two labels". > > The particular issue is that applications and organizations impose > policies and procedures that create additional structure in their use of > domain names. This creates many possible relationships that are not > evident in the names themselves or in the operational, public > representation of the names. > > Prior solutions for identifying relationships between domain names > have sought to use the DNS namespace and protocol to extract that > information when it isn't actually there; the concept of an administrative > boundary is by definition not present in the DNS. Relying on the DNS to > divine administrative structure thus renders such solutions unreliable and > unnecessarily constrained. For example, confirming or dismissing a > relationship between two domain names based on the existence of a zone > cut or common ancestry is often unfounded, and the notion of an upward > "tree walk" as a search mechanism is considered unacceptable. > > For the purposes of this work, domain names are approached as identifiers > used by organizations and services, independent of underlying protocols > or mechanisms. Specifically, the work will not propose any changes to > DNS protocols except the possible creation of new resource record types > (RRTYPES). Furthermore, we define an "organizational domain" to be a > name that is at the top of an administrative hierarchy, defining transition > from one "outside" administrative authority to another that is "inside" the > organization. > > Currently, the most well known solution in existence is the Public Suffix > List (PSL). The PSL is maintained by a Web browser producer and is kept > current by volunteers on a best-effort basis. It contains a list of points > in the hierarchical namespace at which registrations take place, and is > used to identify the boundary between so-called "public" names (below which > registrations can occur) and the private names (i.e., organizational names) > below them. When this list is inaccurate, it exposes a deviation from > reality that degrades service to some and can be exploited by others. Being > the de facto resource, and lacking a more comprehensive, alternative solution > for relationship identification, the functionality of the PSL has often been > misused to accomplish means beyond its capabilities. For example, there > is no way to confirm the relationship between two domain names, only > signal that there is or is not a public boundary between the two. > Additionally, there are questions about the scalability, central management, > and third-party management of the PSL as it currently exists. > > In terms of specific use cases: Within the realm of email, there is a > desire to link an arbitrary fully-qualified domain name (FQDN) to the > organizational domain name (at some point in the namespace above it), > in order to identify a deterministic location where some sort of statement > of policy regarding that FQDN can be found. With respect to the > web, there is a similar need to identify relationships between different > FQDNs, currently accomplished by comparing ancestries. However, there > is also desire to reliably identify relationships outside of the realm > and constraints of the namespace tree. > > Previous work such as Author Domain Signing Practices (ADSP; RFC5617), and > current work such as DMARC (draft-kucherawy-dmarc-base), would certainly > benefit from having this capability. > > The DBOUND working group will develop one or more solutions to this family > of problems. If possible, a unified solution will be developed. However, > the working group may discover that the email, web, equivalence, and What is 'equivalence' here? The word isn't used elsewhere. > possibly other problems require independent solutions, in which case the > working group will follow that path. The solutions may or may not involve > changes to the DNS, such as creation of new resource record types; in any > case, all such changes will be incremental only. This looks like it conflicts with a previous sentence, namely: > Specifically, the work will not propose any changes to > DNS protocols except the possible creation of new resource record types > (RRTYPES). If you write things only once, the charter gets shorter, and there are less conflicts :-). > This working group will not seek to amend the consuming protocols themselves > (i.e., any web or mail standards) without rechartering, and only after > completion of the base work. Any such work undertaken in parallel will > eeed to be done as individual or independent submissions, or in another 'eeed' -> 'need' Regards, Martin. > working group. > > Milestones: > - TBD > > Co-chairs: > - TBD > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Wed Dec 3 07:21:22 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5FD1A1B7C for ; Wed, 3 Dec 2014 07:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, 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 YccuiPpwEayq for ; Wed, 3 Dec 2014 07:21:17 -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 E06A21A1B8B for ; Wed, 3 Dec 2014 07:20:57 -0800 (PST) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sB3FKqcD002111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 3 Dec 2014 07:20:55 -0800 Message-ID: <547F2A4D.7030207@dcrocker.net> Date: Wed, 03 Dec 2014 07:20:45 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , "Murray S. Kucherawy" , IETF Apps Discuss References: <547EB7D1.3050607@it.aoyama.ac.jp> In-Reply-To: <547EB7D1.3050607@it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 03 Dec 2014 07:20:56 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/6OEPQW9em9Fsxzmjr6TDV_Cv064 Cc: "www-tag@w3.org" Subject: Re: [apps-discuss] Proposed charter for DBOUND WG 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: Wed, 03 Dec 2014 15:21:20 -0000 On 12/2/2014 11:12 PM, "Martin J. Dürst" wrote: > The charter is extremely long. I suggest trying to shorten it. I'm sure > it's possible. I'll claim to be one of the folk responsible for causing it to be longer than one might light. And I believe there's been significant effort to make the charter as short as possible, while still doing its job. Some IETF working groups cover topics that are already reasonably well-understood by the general Internet technical population; this permits a relatively terse charter. Others efforts are not so lucky. The technology might be new or obscure. The problem might not be generally recognized yet. The goal or expected solution might not be intuitive. When a planned activity falls into this latter camp, I believe a charter should explain the topic and tasks well enough to give the 'general Internet technical population' a clear understanding of problem and goal. That is, it needs to contain the precis of a tutorial. Unfortunately, that takes verbiage. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Dec 3 08:01:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3F41A6F87 for ; Wed, 3 Dec 2014 08:01:29 -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 WtJLUHu5_SXt for ; Wed, 3 Dec 2014 08:01:27 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003: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 069F11A1BAD for ; Wed, 3 Dec 2014 08:00:16 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id uy5so11802027obc.32 for ; Wed, 03 Dec 2014 08:00:15 -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=hRudLwV9GAJyVgJZqT25dLDRTmd5XfpcQYtC9oLO73M=; b=VTa+Z6cH1dNJRElFeRwIrHzpqhoZY1gRWCjqV7N+CI+OrE74+DNATv8FvutrgwGQTC 50txthPJE0WMvWDH1LzSBY3nyBgu3jXtadfl5XLSMpzCR2F9N90EemVOd31/O2PIxXRX MU8pUPlyq7qdd4srnQsEBldlqxIkSl+JY+eNk= 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=hRudLwV9GAJyVgJZqT25dLDRTmd5XfpcQYtC9oLO73M=; b=HvxfkiHIXJ9l6XGDkBzd6GgUV1E1ZGkT62DWpBFeGPVmolx4+LpSR6ZVOFfQlBcvYG 0eLBbxoQENah5z1pIpAMKgrnSQJvyey0SIm/U/CUq/XXSevNKTp2niuvDtqvhSlbBHnF R6e2D3mUgsebrWA1x4K0kBoNQUNxo7hqKSVnHKc6C1N2PL5bVugolaQrrbtqX92YFdBJ qw8/Ltm1NsuQI0vqR1DW7wi/co8KDmi+YWo2yYMRhRNmNoSnfUViudtDmueuNCTC9d+G s2oy1h7tJBFbLFdxwSUrt5S0xXlnebED5Psukjcz/V0OOBOUHMktfkTuw8nD+Rvm3Atg sBDw== X-Gm-Message-State: ALoCoQlTZOSiA6B/N7PiidgcY9oJVKJBeHWBcXmJcVfnEO/baKBtS7+9iHDLhbUL/wm5X4bMQyPy MIME-Version: 1.0 X-Received: by 10.60.103.115 with SMTP id fv19mr3608491oeb.46.1417622415286; Wed, 03 Dec 2014 08:00:15 -0800 (PST) Received: by 10.60.227.199 with HTTP; Wed, 3 Dec 2014 08:00:15 -0800 (PST) In-Reply-To: <547EB7D1.3050607@it.aoyama.ac.jp> References: <547EB7D1.3050607@it.aoyama.ac.jp> Date: Wed, 3 Dec 2014 16:00:15 +0000 Message-ID: From: Dave Cridland To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=089e0116024e7d3843050951f0d8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/SAXIFeakdIvx4HCXp1EMWz4XWxc Cc: "www-tag@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] Proposed charter for DBOUND WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 16:01:30 -0000 --089e0116024e7d3843050951f0d8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3 December 2014 at 07:12, "Martin J. D=C3=BCrst" wrote: > The charter is extremely long. I suggest trying to shorten it. I'm sure > it's possible. > I agree - much of the charter is, I think, a problem statement. I can never remember if we "do" problem statements. But I'm not convinced that the charter cannot be cut considerably if there's a problem statement to refer to for much of the detail. --089e0116024e7d3843050951f0d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 3= December 2014 at 07:12, "Martin J. D=C3=BCrst" <duerst@it.= aoyama.ac.jp> wrote:
The ch= arter is extremely long. I suggest trying to shorten it. I'm sure it= 9;s possible.

I agree - much of the cha= rter is, I think, a problem statement. I can never remember if we "do&= quot; problem statements. But I'm not convinced that the charter cannot= be cut considerably if there's a problem statement to refer to for muc= h of the detail.
--089e0116024e7d3843050951f0d8-- From nobody Wed Dec 3 14:47:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1F21A8844 for ; Wed, 3 Dec 2014 14:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 ASaV9wxmC4LP for ; Wed, 3 Dec 2014 14:46:59 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DA591A882E for ; Wed, 3 Dec 2014 14:46:59 -0800 (PST) Received: from [192.168.1.83] (unknown [118.209.94.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 22B3A50A87; Wed, 3 Dec 2014 17:46:54 -0500 (EST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Mark Nottingham In-Reply-To: <547EB7D1.3050607@it.aoyama.ac.jp> Date: Thu, 4 Dec 2014 09:46:49 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <547EB7D1.3050607@it.aoyama.ac.jp> To: =?utf-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-8tJCfSDnCKqGJh5LrllHUdoQLU Cc: "www-tag@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] Proposed charter for DBOUND WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: IETF Apps Discuss List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 22:47:03 -0000 Hey Martin, While I'm sure that this is interesting to TAG folks, I don't think that = cross-posting IETF charter comments to the list is helpful. Could folks = please modify CC: lines on responses accordingly? Also, if you want to get the attention of WHATWG people, the most direct = way to do that is on their IRC / list / etc. Cheers, > On 3 Dec 2014, at 6:12 pm, Martin J. D=C3=BCrst = wrote: >=20 > Hello Murray, >=20 > Just a few points after a quick read-through. >=20 > On 2014/12/03 01:59, Murray S. Kucherawy wrote: >> Colleagues, >>=20 >> Below is a proposed charter for a working group we're calling DBOUND, = which >> is seeking to solve the problem of finding a way to identify >> administrative/organizational boundaries in the domain namespace. = We'd >> like to get some feedback from outside the team of people that's been >> working on it. >>=20 >> For the sake of tracking the feedback, please reply only to >> apps-discuss@ietf.org with any comments you may have. >=20 > I suggest to send this also to public-ietf-w3c@w3.org (W3C/IETF = coordination list) and to www-tag@w3.org (W3C TAG public list), and to = get the attention of people from the WHATWG. >=20 >> -MSK, APPSAWG co-chair >>=20 >> dbound charter >=20 > The charter is extremely long. I suggest trying to shorten it. I'm = sure it's possible. >=20 >> Various Internet protocols and applications require some mechanism = for >> determining whether two domain names are related. A popular example = is >> the need to determine whether example.com and foo.example.com, or >> evenexample.net, are subject to the same administrative control. To >> humans, >> the answer to this may be obvious. However, the Domain Name System = (DNS), >> which is the service that handles domain name queries, does not = provide >> the ability to mark these sorts of relationships. This makes it >> impossible to discern relationships algorithmically. For example, = the >> right answer is not always "compare the rightmost two labels". >>=20 >> The particular issue is that applications and organizations impose >> policies and procedures that create additional structure in their use = of >> domain names. This creates many possible relationships that are not >> evident in the names themselves or in the operational, public >> representation of the names. >>=20 >> Prior solutions for identifying relationships between domain names >> have sought to use the DNS namespace and protocol to extract that >> information when it isn't actually there; the concept of an = administrative >> boundary is by definition not present in the DNS. Relying on the DNS = to >> divine administrative structure thus renders such solutions = unreliable and >> unnecessarily constrained. For example, confirming or dismissing a >> relationship between two domain names based on the existence of a = zone >> cut or common ancestry is often unfounded, and the notion of an = upward >> "tree walk" as a search mechanism is considered unacceptable. >>=20 >> For the purposes of this work, domain names are approached as = identifiers >> used by organizations and services, independent of underlying = protocols >> or mechanisms. Specifically, the work will not propose any changes = to >> DNS protocols except the possible creation of new resource record = types >> (RRTYPES). Furthermore, we define an "organizational domain" to be a >> name that is at the top of an administrative hierarchy, defining = transition >> from one "outside" administrative authority to another that is = "inside" the >> organization. >>=20 >> Currently, the most well known solution in existence is the Public = Suffix >> List (PSL). The PSL is maintained by a Web browser producer and is = kept >> current by volunteers on a best-effort basis. It contains a list of = points >> in the hierarchical namespace at which registrations take place, and = is >> used to identify the boundary between so-called "public" names (below = which >> registrations can occur) and the private names (i.e., organizational = names) >> below them. When this list is inaccurate, it exposes a deviation = from >> reality that degrades service to some and can be exploited by others. = Being >> the de facto resource, and lacking a more comprehensive, alternative = solution >> for relationship identification, the functionality of the PSL has = often been >> misused to accomplish means beyond its capabilities. For example, = there >> is no way to confirm the relationship between two domain names, only >> signal that there is or is not a public boundary between the two. >> Additionally, there are questions about the scalability, central = management, >> and third-party management of the PSL as it currently exists. >>=20 >> In terms of specific use cases: Within the realm of email, there is a >> desire to link an arbitrary fully-qualified domain name (FQDN) to the >> organizational domain name (at some point in the namespace above it), >> in order to identify a deterministic location where some sort of = statement >> of policy regarding that FQDN can be found. With respect to the >> web, there is a similar need to identify relationships between = different >> FQDNs, currently accomplished by comparing ancestries. However, = there >> is also desire to reliably identify relationships outside of the = realm >> and constraints of the namespace tree. >>=20 >> Previous work such as Author Domain Signing Practices (ADSP; = RFC5617), and >> current work such as DMARC (draft-kucherawy-dmarc-base), would = certainly >> benefit from having this capability. >>=20 >> The DBOUND working group will develop one or more solutions to this = family >> of problems. If possible, a unified solution will be developed. = However, >> the working group may discover that the email, web, equivalence, and >=20 > What is 'equivalence' here? The word isn't used elsewhere. >=20 >=20 >> possibly other problems require independent solutions, in which case = the >> working group will follow that path. The solutions may or may not = involve >> changes to the DNS, such as creation of new resource record types; in = any >> case, all such changes will be incremental only. >=20 > This looks like it conflicts with a previous sentence, namely: > > Specifically, the work will not propose any changes to > > DNS protocols except the possible creation of new resource record = types > > (RRTYPES). >=20 > If you write things only once, the charter gets shorter, and there are = less conflicts :-). >=20 >> This working group will not seek to amend the consuming protocols = themselves >> (i.e., any web or mail standards) without rechartering, and only = after >> completion of the base work. Any such work undertaken in parallel = will >> eeed to be done as individual or independent submissions, or in = another >=20 > 'eeed' -> 'need' >=20 > Regards, Martin. >=20 >> working group. >>=20 >> Milestones: >> - TBD >>=20 >> Co-chairs: >> - TBD >>=20 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Wed Dec 3 20:45:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF40C1A0049 for ; Wed, 3 Dec 2014 20:38:59 -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 62wxOIQAEo1E for ; Wed, 3 Dec 2014 20:38:56 -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 53CC11A0035 for ; Wed, 3 Dec 2014 20:38:43 -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 BA22532E4F6 for ; Thu, 4 Dec 2014 13:37:58 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 4a43_5bd7_df01f6a8_220f_42a7_aa30_aa55ad2589f3; Thu, 04 Dec 2014 13:37:58 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 3831BC0007 for ; Thu, 4 Dec 2014 13:37:58 +0900 (JST) Message-ID: <547FE524.5010407@it.aoyama.ac.jp> Date: Thu, 04 Dec 2014 13:37:56 +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: IETF Apps Discuss References: <547EB7D1.3050607@it.aoyama.ac.jp> 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/2spqGBRyT7rro5Lbe4E9hNalq_k Subject: Re: [apps-discuss] Proposed charter for DBOUND WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 04:39:00 -0000 Hello Mark, Just in private: On 2014/12/04 07:46, Mark Nottingham wrote: > Hey Martin, > > While I'm sure that this is interesting to TAG folks, I don't think tha= t cross-posting IETF charter comments to the list is helpful. Sorry, I didn't intend to do that. I'm not sure why the TAG got cc'ed, I=20 think it was because I was trying to verify the address but forgot to=20 delete it once I had copied it to the text of the message. Could folks please modify CC: lines on responses accordingly? > > Also, if you want to get the attention of WHATWG people, the most direc= t way to do that is on their IRC / list / etc. My suggestion was just to get the attention of the WHATWG people, not to=20 get that through the TAG. I think that should be clear from what I=20 wrote, but maybe it wasn't. Or maybe that's how you interpreted my text,=20 and you are just giving advice on how to do it? Regards, Martin. > Cheers, > > >> On 3 Dec 2014, at 6:12 pm, Martin J. D=C3=BCrst wrote: >> >> Hello Murray, >> >> Just a few points after a quick read-through. >> >> On 2014/12/03 01:59, Murray S. Kucherawy wrote: >>> Colleagues, >>> >>> Below is a proposed charter for a working group we're calling DBOUND,= which >>> is seeking to solve the problem of finding a way to identify >>> administrative/organizational boundaries in the domain namespace. We= 'd >>> like to get some feedback from outside the team of people that's been >>> working on it. >>> >>> For the sake of tracking the feedback, please reply only to >>> apps-discuss@ietf.org with any comments you may have. >> >> I suggest to send this also to public-ietf-w3c@w3.org (W3C/IETF coordi= nation list) and to www-tag@w3.org (W3C TAG public list), and to get the = attention of people from the WHATWG. >> >>> -MSK, APPSAWG co-chair >>> >>> dbound charter >> >> The charter is extremely long. I suggest trying to shorten it. I'm sur= e it's possible. >> >>> Various Internet protocols and applications require some mechanism fo= r >>> determining whether two domain names are related. A popular example = is >>> the need to determine whether example.com and foo.example.com, or >>> evenexample.net, are subject to the same administrative control. To >>> humans, >>> the answer to this may be obvious. However, the Domain Name System (= DNS), >>> which is the service that handles domain name queries, does not provi= de >>> the ability to mark these sorts of relationships. This makes it >>> impossible to discern relationships algorithmically. For example, th= e >>> right answer is not always "compare the rightmost two labels". >>> >>> The particular issue is that applications and organizations impose >>> policies and procedures that create additional structure in their use= of >>> domain names. This creates many possible relationships that are not >>> evident in the names themselves or in the operational, public >>> representation of the names. >>> >>> Prior solutions for identifying relationships between domain names >>> have sought to use the DNS namespace and protocol to extract that >>> information when it isn't actually there; the concept of an administr= ative >>> boundary is by definition not present in the DNS. Relying on the DNS= to >>> divine administrative structure thus renders such solutions unreliabl= e and >>> unnecessarily constrained. For example, confirming or dismissing a >>> relationship between two domain names based on the existence of a zon= e >>> cut or common ancestry is often unfounded, and the notion of an upwar= d >>> "tree walk" as a search mechanism is considered unacceptable. >>> >>> For the purposes of this work, domain names are approached as identif= iers >>> used by organizations and services, independent of underlying protoco= ls >>> or mechanisms. Specifically, the work will not propose any changes t= o >>> DNS protocols except the possible creation of new resource record typ= es >>> (RRTYPES). Furthermore, we define an "organizational domain" to be a >>> name that is at the top of an administrative hierarchy, defining tran= sition >>> from one "outside" administrative authority to another that is "insid= e" the >>> organization. >>> >>> Currently, the most well known solution in existence is the Public Su= ffix >>> List (PSL). The PSL is maintained by a Web browser producer and is k= ept >>> current by volunteers on a best-effort basis. It contains a list of = points >>> in the hierarchical namespace at which registrations take place, and = is >>> used to identify the boundary between so-called "public" names (below= which >>> registrations can occur) and the private names (i.e., organizational = names) >>> below them. When this list is inaccurate, it exposes a deviation fro= m >>> reality that degrades service to some and can be exploited by others.= Being >>> the de facto resource, and lacking a more comprehensive, alternative = solution >>> for relationship identification, the functionality of the PSL has oft= en been >>> misused to accomplish means beyond its capabilities. For example, th= ere >>> is no way to confirm the relationship between two domain names, only >>> signal that there is or is not a public boundary between the two. >>> Additionally, there are questions about the scalability, central mana= gement, >>> and third-party management of the PSL as it currently exists. >>> >>> In terms of specific use cases: Within the realm of email, there is a >>> desire to link an arbitrary fully-qualified domain name (FQDN) to the >>> organizational domain name (at some point in the namespace above it), >>> in order to identify a deterministic location where some sort of stat= ement >>> of policy regarding that FQDN can be found. With respect to the >>> web, there is a similar need to identify relationships between differ= ent >>> FQDNs, currently accomplished by comparing ancestries. However, ther= e >>> is also desire to reliably identify relationships outside of the real= m >>> and constraints of the namespace tree. >>> >>> Previous work such as Author Domain Signing Practices (ADSP; RFC5617)= , and >>> current work such as DMARC (draft-kucherawy-dmarc-base), would certai= nly >>> benefit from having this capability. >>> >>> The DBOUND working group will develop one or more solutions to this f= amily >>> of problems. If possible, a unified solution will be developed. How= ever, >>> the working group may discover that the email, web, equivalence, and >> >> What is 'equivalence' here? The word isn't used elsewhere. >> >> >>> possibly other problems require independent solutions, in which case = the >>> working group will follow that path. The solutions may or may not in= volve >>> changes to the DNS, such as creation of new resource record types; in= any >>> case, all such changes will be incremental only. >> >> This looks like it conflicts with a previous sentence, namely: >>> Specifically, the work will not propose any changes to >>> DNS protocols except the possible creation of new resource record typ= es >>> (RRTYPES). >> >> If you write things only once, the charter gets shorter, and there are= less conflicts :-). >> >>> This working group will not seek to amend the consuming protocols the= mselves >>> (i.e., any web or mail standards) without rechartering, and only afte= r >>> completion of the base work. Any such work undertaken in parallel wi= ll >>> eeed to be done as individual or independent submissions, or in anoth= er >> >> 'eeed' -> 'need' >> >> Regards, Martin. >> >>> working group. >>> >>> Milestones: >>> - TBD >>> >>> Co-chairs: >>> - TBD >>> >>> >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >> > > -- > Mark Nottingham https://www.mnot.net/ > > From nobody Thu Dec 4 14:36:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC9B1A6FEA; Thu, 4 Dec 2014 14:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.908 X-Spam-Level: X-Spam-Status: No, score=0.908 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=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 1OAb8j8HQteL; Thu, 4 Dec 2014 14:36:49 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A003F1A1A75; Thu, 4 Dec 2014 14:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Mime-Version:To:Date:Message-Id:Subject:Content-Type:From; bh=gX7P3KddcYJ3cdX7W95Cs02aumDQKWDTg1dMwVw/Ap8=; b=JWiGcVa2ndTD9L+qAzvjcSObZiAnHxU+s7xGOp6w+Kdv3MAYPWw5Z0vVVrZ+eYHd14eMRwzmNU2ELBXpEz/hv5tmlAu/ooqgNNRagzys4sHtfLyU20Oe0JEmALHte0aNZY6Ks290TjCOxQCZ98jxNGt3DpAdDJLsENvpDVvPRTI=; Received: from ip68-100-74-115.dc.dc.cox.net ([68.100.74.115]:63100 helo=[192.168.15.119]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Xwf0m-0000MY-Ey; Thu, 04 Dec 2014 14:36:43 -0800 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_EB9BF876-81A6-43FF-956C-79EB100DC5CC"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Date: Thu, 4 Dec 2014 17:36:37 -0500 To: lemonade@ietf.org, IETF Apps Discuss Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/OhIdTmhcAm_Za4un-GRmmCU61Ww Subject: [apps-discuss] Forward Without Download X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 22:36:50 -0000 --Apple-Mail=_EB9BF876-81A6-43FF-956C-79EB100DC5CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Has anyone implemented and deployed BURL/CATENATE? I looked at = , but = half the companies are gone. I am curious as I=E2=80=99d like to do a = security study on forward without download. While on the topic, does anyone want me to update the Lemonade Plans = page with current information? Lastly, I copied apps-discuss because I doubt anyone cares about the = lemonade list anymore. I am leaning towards shutting it down and having = whatever discussion needs to happen on the apps-discuss list. If you = think that=E2=80=99s a daft idea, feel free to respond on the lemonade = list.= --Apple-Mail=_EB9BF876-81A6-43FF-956C-79EB100DC5CC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQpjCCBUAw ggQooAMCAQICEQCuNx1clInO3pDdx/tx5ymMMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNDEwMDgwMDAwMDBaFw0xNTEwMDgyMzU5NTla MCsxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0HJR1ciLrHT/CjRECPUsdCrORWwHwf9AA9jE6tX8y8sqqrnY jPw4YtahKkLP+3VLXEjTWLi9nl0ISFtrZ+sq27HUuPmaiNtjqWgCjyPjfUi5PEDiJE3CSR8CK8Z6 iLO09oNTlSLY6qmKxVB4MEp8rRvOYTDk4nC2wCgMRzpUXE8q44d8LPYSe1V1o4eSSRXby2gxrTMw F/RLKGeSyB2ekee0c68FMZmfPR8kp43jM0SlZqgXLkf8ATTF9BxeznwqTC7GxXRJJi30d9dNQIl1 4M7J0c3kY7VpAHFXCh/KuNki0e6LKnhJrMXzVvou1OqCgI0xbCQJbMkjm8hXXxYU7wIDAQABo4IB 8DCCAewwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFK1jQ8667Bo+ kfpdpUC1bTmlMzGLMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYD VR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0 aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUF BzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20wDQYJKoZIhvcNAQELBQAD ggEBAGYB/MbhzXClCc4fPctp4HBusRbgGt05ngOvKLih3vUY4xSG6FV+5BaRt5/MvnnIATlf/dxt GBmeX3X124irtI2EIkd7xEStZlrSzDm3eIv0wW3DeKY8V9BlTKSmPO6sXl1qU8WJoNZvXOhs52do Y4CTURs4uuttjbuEH3PQ32lO8M5lPqMnvj/qhGxh2Sg7mRop2kGitqLB6HHqGyh1t32SY16wWvPT ovhq/38sPFamVK0FOC68LGxeKYD4KOf6GQkteQkQG+uqCEdpi4k2EwTtK43bVbeZ1rSzPMC5HRln m+qPgE7ZWxBQlvdd5sQtBUz5Dl5lqj9kQ3YQz6XFNAMwggV0MIIEXKADAgECAhAnZu5W60nzjqvX cKL8hN4iMA0GCSqGSIb3DQEBDAUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBB QjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRy dXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcNMjAwNTMwMTA0ODM4WjCBhTEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCR6FSS0gpW sawNJN3Fz0RndJkrN6N9I3AAcbxT38T6KhKPS38QVr2fcHK3YX/JSw8Xpz3jsARh7v8Rl8f0hj4K +j5c+ZPmNHrZFGvnnLOFoIJ6dq9xkNfs/Q36nGz637CC9BR++b7Epi9Pf5l/tfxnQ3K9DADWietr LNPtj5gcFKt+5eNu/Nio5JIk2kNrYrhV/erBvGy2i/MOjZrkm2xpmfh4SDBF1a3hDTxFYPwyllEn vGfDyi62a+pGx8cgoLEfZd5ICLqkTqnyg0Y3hOvozIFIQ2dOciqbXL1MGyiKXCJ7tKuY2e7gUYPD CUZObT6Z+pUX2nwzV0E8jVHtC7ZcryxjGt9XyD+86V3Em69FmeKjWiS0uqlWPc9vqv9JWL7wqP/0 uK3pN/u6uPQLOvnoQ0IeidiEyxPx2bvhiWC4jChWrBQdnArncevPDt09qZahSL0896+1DSJMwBGB 7FY79tOi4lu3sgQiUpWAk2nojkxl8ZEDLXB0AuqLZxUpaVICu9ffUGpVRr+goyhhf3DQw6KqLCGq R84onAZFdr+CGCe01a60y1Dma/RMhnEw6abfFobg2P9A3fvQQoh/ozM6LlweQRGBY84YcWsr7KaK tzFcOmpH4MN5WdYgGq/yapiqcrxXStJLnbsQ/LBMQeXtHT1eKJ2czL+zUdqnR+WEUwIDAQABo4H0 MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBS7r34CPfqm8TyE jq3uOJjs2TIy1DAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYG BFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0 RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29j c3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAQEAZL+D8V+ahdDNuKEpVw3oWvfR6T7y dgRu8VJwux48/00NdGrMgYIl08OgKl1M9bqLoW3EVAl1x+MnDl2EeTdAE3f1tKwc0DurFxLW7zQY fivpedOrV0UMryj60NvlUJWIu9+FV2l9kthSynOBvxzz5rhuZhEFsx6ULX+RlZJZ8UzOo5FxTHxH DDsLGfahsWyGPlyqxC6Cy/kHlrpITZDylMipc6LrBnsjnd6i801Vn3phRZgYaMdeQGsj9Xl674y1 a4u3b0b0e/E9SwTYk4BZWuBBJB2yjxVgWEfb725G/RX12V+as9vYuORAs82XOa6Fux2OvNyHm9Gm 7/E7bxA4bzCCBeYwggPOoAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQPTRI 5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivlJTRENf+R KwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG9qrxpZxyb4o4 yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66nJN/VCJv5ym6 Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCCATgwHwYDVR0j BBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzoHz0rcUhexIvA MA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBM BgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9j cnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyP omsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y 78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxl pZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaa SOGTTFB+E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I3 1gnMrwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9h z9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5 PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJU mpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTKTlL8 YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIDujCCA7YCAQEwga0wgZcx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEArjcdXJSJzt6Q3cf7cecpjDAJ BgUrDgMCGgUAoIIB4TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0x NDEyMDQyMjM2MzdaMCMGCSqGSIb3DQEJBDEWBBSgO2ay5f3PMSS3yV+WO3kNguENHTCBvgYJKwYB BAGCNxAEMYGwMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAK43 HVyUic7ekN3H+3HnKYwwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIRAK43HVyUic7ekN3H+3HnKYwwDQYJKoZIhvcNAQEBBQAEggEA Ahn55srSFM6PoUyuRWE4c/d/8y3dhZigOAkTeZ7mSKiJBBvARO89Qd9VLks42PG6hLFZ8g4grvQu KkbCLLJga+YmwZdKuasBPGgogWmoOrRQVNa5lCz3OTtAb715kwELKrVaxiiHNwfPr6zTG+cwhm0o hGZ1XzPzB18bL7OYTrPIwe2BOyqp6l/I5fEHr4IyV2EO8XLEg/om+H9Gsavmrxn0CBkcm0IORQwO UDWlErcQZVeKUsZpmirkOh2XSIxiODsF43IZsGuMuhhvaBnO7pfJGvosm1HCtp9oDsw3DKEv4YEy Gq1v9owPs/3BigLXbmhIcL9JB0qeOd6Y4l++kAAAAAAAAA== --Apple-Mail=_EB9BF876-81A6-43FF-956C-79EB100DC5CC-- From nobody Thu Dec 4 16:36:50 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D187F1A1BFB; Thu, 4 Dec 2014 16:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.388 X-Spam-Level: X-Spam-Status: No, score=0.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TOOL=2.3, 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 GkcfdTJ81H12; Thu, 4 Dec 2014 16:36:42 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id C533D1A1B8B; Thu, 4 Dec 2014 16:36:42 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 621B7181CF4; Thu, 4 Dec 2014 16:36:07 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20141205003607.621B7181CF4@rfc-editor.org> Date: Thu, 4 Dec 2014 16:36:07 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wuLvw2cwn8NXxClYqsZs4TzmuXk Cc: drafts-update-ref@iana.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] RFC 7410 on A Property Types Registry for the Authentication-Results Header Field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 00:36:44 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7410 Title: A Property Types Registry for the Authentication-Results Header Field Author: M. Kucherawy Status: Standards Track Stream: IETF Date: December 2014 Mailbox: superuser@gmail.com Pages: 5 Characters: 9957 Updates: RFC7001 I-D Tag: draft-ietf-appsawg-authres-ptypes-registry-04.txt URL: https://www.rfc-editor.org/rfc/rfc7410.txt This document updates RFC 7001 by creating a registry for property types in the Authentication-Results header field, used in email authentication work, rather than limiting participants to using the original, small set of fixed values. This document is a product of the Applications Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Dec 4 17:59:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E131A8BBF; Thu, 4 Dec 2014 17:59:13 -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, 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 F-BWQw19vFMJ; Thu, 4 Dec 2014 17:59:10 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC5FB1A6EE0; Thu, 4 Dec 2014 17:59:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 150585394A7; Thu, 4 Dec 2014 20:59:07 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlHiz6l8_2dw; Thu, 4 Dec 2014 20:59:06 -0500 (EST) Received: from [10.0.1.25] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id E44B253949B; Thu, 4 Dec 2014 20:59:05 -0500 (EST) Date: Thu, 04 Dec 2014 20:59:02 -0500 From: Cyrus Daboo To: Eric Burger , lemonade@ietf.org, IETF Apps Discuss Message-ID: <7275BF0E7BDCBE7687DD9245@cyrus.local> In-Reply-To: References: X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=1083 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/fy7TY1DozIZa4HMlQCu5AKf9CWQ Subject: Re: [apps-discuss] Forward Without Download X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 01:59:14 -0000 Hi Eric, --On December 4, 2014 at 5:36:37 PM -0500 Eric Burger=20 wrote: > Has anyone implemented and deployed BURL/CATENATE? I looked at > , but > half the companies are gone. I am curious as I=E2=80=99d like to do a = security > study on forward without download. > > While on the topic, does anyone want me to update the Lemonade Plans page > with current information? > > Lastly, I copied apps-discuss because I doubt anyone cares about the > lemonade list anymore. I am leaning towards shutting it down and having > whatever discussion needs to happen on the apps-discuss list. If you > think that=E2=80=99s a daft idea, feel free to respond on the lemonade = list. Try imapext instead of lemonade - there are ongoing IMAP discussions there: List-Id: Discussion of IMAP extensions List-Archive: List-Subscribe: , --=20 Cyrus Daboo From nobody Fri Dec 5 00:25:13 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7B21A88EF; Fri, 5 Dec 2014 00:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.185 X-Spam-Level: X-Spam-Status: No, score=0.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 x-5cSG2AIVQy; Fri, 5 Dec 2014 00:25:08 -0800 (PST) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E65B1A0121; Fri, 5 Dec 2014 00:25:06 -0800 (PST) Received: from klara.student.utwente.nl ([130.89.162.218]:65402 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1XwoCD-0000Jt-V9; Fri, 05 Dec 2014 09:25:04 +0100 Message-ID: <54816B82.7030702@rename-it.nl> Date: Fri, 05 Dec 2014 09:23:30 +0100 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Eric Burger , lemonade@ietf.org, IETF Apps Discuss References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XCM06OK_PL08qvx62xpgIQ-xywc Subject: Re: [apps-discuss] Forward Without Download X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 08:25:10 -0000 Hi Eric, On 12/4/2014 11:36 PM, Eric Burger wrote: > Has anyone implemented and deployed BURL/CATENATE? I looked at , but half the c= ompanies are gone. I am curious as I=92d like to do a security study on f= orward without download. > While on the topic, does anyone want me to update the Lemonade Plans pa= ge with current information? For the IMAP side you can look at the IMAP wiki: http://www.imapwiki.org/Specs . I've kept this matrix up to date with information I could find online. Support for BURL is less easy. I know the following: Oracle supports it in their product: https://wikis.oracle.com/display/CommSuite/Messaging+Server+Lemonade+Prof= ile+1+Support+in+Unified+Configuration#MessagingServerLemonadeProfile1Sup= portinUnifiedConfiguration-SupportforBURL Isode supports it in their product: http://www.isode.com/products/m-switch-conformance.html For Postfix I've heard some rumors that Wietse was looking into it, but I grepped for BURL in the latest source code I could find and found nothi= ng. Exim doesn't support BURL at all. I myself have created most of the CATENATE and URLAUTH support for Dovecot. In addition to that, I've made an SMTP submission frontend (proxy) for Dovecot that adds BURL support to any SMTP server. It will be available for version v2.3, but I have no idea when that will be released. Regards, Stephan. From nobody Fri Dec 5 03:44:00 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCAF1ACE27; Fri, 5 Dec 2014 03:43:56 -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 rjtPw8ROe2zR; Fri, 5 Dec 2014 03:43:55 -0800 (PST) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 77EC11ACE48; Fri, 5 Dec 2014 03:43:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1417779834; d=isode.com; s=selector; i=@isode.com; bh=HEsjc0AyDkl1PFNM9fCojUVKqdbylX3MW9aw29m7Upo=; 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=QKAtB8wXsEAkd5QltNieLxyH94XcqzOMPzTMUX4Tbr/trqYlmZ88XAPSGDgSc4LYcFMnOf eN274sc80y5NXVeJyU9lLjDk+1VKqVL71S94dvJnJK7nESAxGBbZRmSXoVIJcQxes9/7mb pjLfnVw8ybwhETy39xJAqvnouLFCzSc=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 5 Dec 2014 11:43:53 +0000 Message-ID: <548199D5.3080006@isode.com> Date: Fri, 05 Dec 2014 11:41:09 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 To: Eric Burger , lemonade@ietf.org, IETF Apps Discuss References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/U-H1M3BuMZrU0J3Ugw8D3vfikXU Subject: Re: [apps-discuss] [lemonade] Forward Without Download X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 11:43:57 -0000 On 04/12/2014 22:36, Eric Burger wrote: > Has anyone implemented and deployed BURL/CATENATE? I looked at , but half the compani= es are gone. I am curious as I=92d like to do a security study on forward wi= thout download. In addition to what Stephan has mentioned: Isode is adding support for=20 CATENATE/BURL to our Android email client in the next 3 months. From nobody Sun Dec 7 14:41:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0471A1A42 for ; Sun, 7 Dec 2014 14:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 TGmRB7rDKzHQ for ; Sun, 7 Dec 2014 14:41:01 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id A23331A1A1E for ; Sun, 7 Dec 2014 14:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1417992060; d=isode.com; s=selector; i=@isode.com; bh=xDGO/w5Kbwgqmgn1pKz4HF59OZoyBVYvDiLm+bxig10=; 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=g//HsS7RUOR5ykj0GHCsVr7hIqCSEEj28i5hjanU53s74/thES8QmQ1BFn9NMTdFSwI34s RD1iUZ2FiRluDHDv3+dGA/bUtMm3tBb+pno67d9b4hIBEEj/sVj1YV3zr5JjtT+xMC3xHN 1fRysNLR7nfHAx78egJHVJC6OZOvPv4=; Received: from [192.168.0.12] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id for ; Sun, 7 Dec 2014 22:41:00 +0000 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov Message-Id: <8D25F56B-EEEC-4858-9905-999DA0C6D52F@isode.com> Date: Sun, 7 Dec 2014 22:44:10 +0000 To: "apps-discuss@ietf.org" X-Mailer: iPad Mail (12B435) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-8C03773D-6B0F-4A55-A0EC-D0FF19168FC6 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XmJYtnmI-Nmeg6EBTVGxQUJT6lU Subject: [apps-discuss] WGLC on draft-ietf-appsawg-http-problem-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: Sun, 07 Dec 2014 22:41:02 -0000 --Apple-Mail-8C03773D-6B0F-4A55-A0EC-D0FF19168FC6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable This message starts 2 weeks WGLC on draft-ietf-appsawg-http-problem-00 (Prob= lem Details for HTTP APIs). Please review and send your comments to the mail= ing list by December 21st, or state that the document is ready for publicati= on. Alexey, as APPSAWG co-chair --Apple-Mail-8C03773D-6B0F-4A55-A0EC-D0FF19168FC6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit This message starts 2 weeks WGLC on draft-ietf-appsawg-http-problem-00 (Problem Details for HTTP APIs). Please review and send your comments to the mailing list by December 21st, or state that the document is ready for publication.

Alexey,
as APPSAWG co-chair

--Apple-Mail-8C03773D-6B0F-4A55-A0EC-D0FF19168FC6-- From nobody Sun Dec 7 23:42:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D611A6FEF for ; Sun, 7 Dec 2014 23:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, J_CHICKENPOX_36=0.6, 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 MpTLOpgul6e9 for ; Sun, 7 Dec 2014 23:42: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 44FE41A6FF2 for ; Sun, 7 Dec 2014 23:42:01 -0800 (PST) Received: from [192.168.2.160] ([93.217.103.122]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LcBin-1XWHUR1iKb-00jWFi; Mon, 08 Dec 2014 08:41:42 +0100 Message-ID: <54855632.6080801@gmx.de> Date: Mon, 08 Dec 2014 08:41: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: Alexey Melnikov , "apps-discuss@ietf.org" References: <8D25F56B-EEEC-4858-9905-999DA0C6D52F@isode.com> In-Reply-To: <8D25F56B-EEEC-4858-9905-999DA0C6D52F@isode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:kEnQFmRcO11z9D0LGKexLP2p3TobUwIvANMe3Pr1cNUJVQZJ982 5U9ZLiGxZoTKZEk+qRrP/+DCrnr3nS6qxn3GmtgDzwE8eGHqwUCbA1DVQxszfzp4PPQKhQZ MZOOqyXTXPKbPgLNy1H8f/iKXy7MhOVo8KHvw8y9UxnTF69GKICJYhsGwQSUE2i+GNigKbM 6IqmslhWOUoIsF/Y6xs8A== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XwyA6D-FfcG5-U9_urUhZYJaYwU Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-http-problem-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, 08 Dec 2014 07:42:07 -0000 Hi, below some feedback. Not in the spec: 1) The spec doesn't mention that this sort of duplicates earlier work done in WebDAV; see 2) The spec talks about using Accept to instruct the server whether to return problem details or HTML. Maybe it would be worthwhile to mention that if you use XML, you could *always* send problem details, and then use to instruct the UA to convert to HTML; that would get rid of the conneg complexity. In the spec: > The data model for problem details is a JSON [RFC7159] object; when > formatted as a JSON document, it uses the "application/problem+json" > media type. Appendix A defines how to express them in an equivalent > XML format, which uses the "application/problem+xml" media type. Why is this an appendix? > A problem's type URI SHOULD resolve to HTML > [W3C.REC-html401-19991224] documentation that explains how to resolve > the problem. Not sure why we need to mandate HTML here. If the ref is updated to HTML5 it would at least allow XHTML as well. > If such additional members are defined, their names SHOULD start with > a letter (ALPHA, as per [RFC5234]) and SHOULD consist of characters > from ALPHA, DIGIT, and "_" (so that it can be serialized in formats > other than JSON), and SHOULD be three characters or longer. DIGIT should ref RFC5234 as well, optimally point readers directly to Appendix B.1. > The OPTIONAL RELAX NG schema [ISO-19757-2] for the XML format is: What does "OPTIONAL" mean here? The schema doesn't seem optional at all; lacking it, you wouldn't even know what XML namespace to use. > default namespace ns = "urn:ietf:rfc:XXXX" This needs to state that it will be updated based on the assigned RFC number. > start = problem > > problem = > element problem { > ( element type { xsd:anyURI }? > & element title { xsd:string }? > & element detail { xsd:string }? > & element status { xsd:positiveInteger }? > & element instance { xsd:anyURI }? ), > anyNsElement > } > > anyNsElement = > ( element ns:* { anyNsElement | text } > | attribute * { text })* > > The media type for this format is "application/problem+xml". > Extension arrays and objects can be serialized into the XML format by > considering an element containing a child or children to represent an > object, except for elements that contain only child element(s) named > 'i', which are considered arrays. For example, an alternate version > of the example above would appear in XML as: This is written like guidance, but it's normative, right? > HTTP/1.1 403 Forbidden > Content-Type: application/problem+xml > Content-Language: en > > > > http://example.com/probs/out-of-credit > You do not have enough credit. > Your current balance is 30, but that costs 50. > > http://example.net/account/12345/msgs/abc > It would be good to point out that due to the type definitions in the schema, the whitespace inside is ignorable. Editorial nits: > Abstract > > This document defines a "problem detail" as a way to carry machine- > readable details of errors in a HTTP response, to avoid the need to > invent new error response formats for HTTP APIs. s/invent/define/ maybe? > Note to Readers > > This draft should be discussed on the apps-discuss mailing list [1]. add "to be removed by RFC Editor..." > 1. Introduction > > > HTTP [RFC7230] status codes are sometimes not sufficient to convey > enough information about an error to be helpful. While humans behind > Web browsers can be informed about the nature of the problem with an > HTML [W3C.REC-html401-19991224] response body, non-human consumers of > so-called "HTTP APIs" are usually not. You probably want to cite HTML5 now. Also, consider shortening the reference name to "HTML". > This specification defines simple JSON [RFC7159] and XML > [W3C.REC-xml-20081126] document formats to suit this purpose. They > are designed to be reused by HTTP APIs, which can identify distinct > "problem types" specific to their needs. ...and to "XML". > Additionally, problems can contain other information, such as a URI > that identifies the specific occurrence of the problem (effectively > giving an identifier to the concept "The time Joe didn't have enough > credit last Thursday"), which may be useful for support or forensic > purposes. s/may/can/ > 3.1. Problem Details Object Members > > > A problem details object MAY have the following members: s/MAY have/can have/ > o "title" (string) - A short, human-readable summary of the problem > type. It SHOULD NOT change from occurrence to occurrence of the > problem, except for purposes of localisation. Does this imply localisation-per-request (Accept-Language?) > The detail member, if present, SHOULD focus on helping the client > correct the problem, rather than giving debugging information. s/SHOULD/ought to/ > Finally, an application may have a more appropriate way to carry an s/may/might/ > That said, it is possible to add support for problem details to > existing HTTP APIs using HTTP content negotiation (e.g., using the > Accept request header to indicate a preference for this format). Reference Section 5.3.2 of RFC7231. > New problem type definitions MUST document: > > 1. A type URI (typically, with the "http" scheme), > > 2. A title that appropriately describes it (think short), and > > 3. The HTTP status code for it to be used with. > > Problem types MAY specify the use of the Retry-After response header > in appropriate circumstances. s/Problem type/Problem type definitions/ Also reference Section 7.1.3 of RFC7231. > 8.2. Informative References > > > [ISO-19757-2] > International Organization for Standardization, > "Information Technology --- Document Schema Definition > Languages (DSDL) --- Part 2: Grammar-based Validation --- > RELAX NG", ISO/IEC 19757-2, 2003. This one sounds normative to me. > [W3C.REC-xml-20081126] > Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and > F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth > Edition)", World Wide Web Consortium Recommendation REC- > xml-20081126, November 2008, > . Same here. > Some HTTP-based APIs use XML [W3C.REC-xml-20081126] as their primary > format convention. Such APIs MAY express problem details using the > format defined in this appendix. s/MAY/can/ Best regards, Julian From nobody Mon Dec 8 15:36:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B101A00E1 for ; Mon, 8 Dec 2014 15:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.002 X-Spam-Level: X-Spam-Status: No, score=-4.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_36=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 PA2efwY3voSh for ; Mon, 8 Dec 2014 15:35:58 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07AC1A00FA for ; Mon, 8 Dec 2014 15:35:57 -0800 (PST) Received: from [192.168.1.83] (unknown [118.209.125.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BEA77509B6; Mon, 8 Dec 2014 18:35:54 -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: <54855632.6080801@gmx.de> Date: Tue, 9 Dec 2014 10:35:51 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <8BA03684-EAA5-4693-8551-2C1A08C947AB@mnot.net> References: <8D25F56B-EEEC-4858-9905-999DA0C6D52F@isode.com> <54855632.6080801@gmx.de> To: "Julian F. Reschke" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/qmykDhIgBk7P0XV19KpEC8Yk78o Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-http-problem-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, 08 Dec 2014 23:36:01 -0000 Guten Abend, Julian. > On 8 Dec 2014, at 6:41 pm, Julian Reschke = wrote: >=20 > Hi, >=20 > below some feedback. >=20 > Not in the spec: >=20 > 1) The spec doesn't mention that this sort of duplicates earlier work = done in WebDAV; see = If this were an academic paper, I think that'd be important. As a spec, = I'm not sure that it is. > 2) The spec talks about using Accept to instruct the server whether to = return problem details or HTML. Maybe it would be worthwhile to mention = that if you use XML, you could *always* send problem details, and then = use to instruct the UA to convert = to HTML; that would get rid of the conneg complexity. I'm not sure that browsers are going to support XSLT in the long run. > In the spec: >=20 > > The data model for problem details is a JSON [RFC7159] object; = when > > formatted as a JSON document, it uses the = "application/problem+json" > > media type. Appendix A defines how to express them in an = equivalent > > XML format, which uses the "application/problem+xml" media type. >=20 > Why is this an appendix? When all things are equal, I'd prefer people to use JSON for APIs, not = XML. If we move it to be a peer of the JSON format, we'd need to have = some text advising when to use each, and that could get sticky. Putting = it in an appendix seemed like a reasonable compromise. If we don't put = it in an appendix, I'd almost want to put it in a separate document... > > A problem's type URI SHOULD resolve to HTML > > [W3C.REC-html401-19991224] documentation that explains how to = resolve > > the problem. >=20 > Not sure why we need to mandate HTML here. If the ref is updated to = HTML5 it would at least allow XHTML as well. Yes, the ref should be updated. > > If such additional members are defined, their names SHOULD start = with > > a letter (ALPHA, as per [RFC5234]) and SHOULD consist of = characters > > from ALPHA, DIGIT, and "_" (so that it can be serialized in = formats > > other than JSON), and SHOULD be three characters or longer. >=20 > DIGIT should ref RFC5234 as well, optimally point readers directly to = Appendix B.1. Ack. > > The OPTIONAL RELAX NG schema [ISO-19757-2] for the XML format is: >=20 > What does "OPTIONAL" mean here? The schema doesn't seem optional at = all; lacking it, you wouldn't even know what XML namespace to use. That's Erik's work, but I tend to agree. >=20 > > default namespace ns =3D "urn:ietf:rfc:XXXX" >=20 > This needs to state that it will be updated based on the assigned RFC = number. Ack. >=20 > > start =3D problem > > > > problem =3D > > element problem { > > ( element type { xsd:anyURI }? > > & element title { xsd:string }? > > & element detail { xsd:string }? > > & element status { xsd:positiveInteger }? > > & element instance { xsd:anyURI }? ), > > anyNsElement > > } > > > > anyNsElement =3D > > ( element ns:* { anyNsElement | text } > > | attribute * { text })* > > > > The media type for this format is "application/problem+xml". >=20 >=20 > > Extension arrays and objects can be serialized into the XML = format by > > considering an element containing a child or children to = represent an > > object, except for elements that contain only child element(s) = named > > 'i', which are considered arrays. For example, an alternate = version > > of the example above would appear in XML as: >=20 > This is written like guidance, but it's normative, right? >=20 > > HTTP/1.1 403 Forbidden > > Content-Type: application/problem+xml > > Content-Language: en > > > > > > > > http://example.com/probs/out-of-credit > > You do not have enough credit. > > Your current balance is 30, but that costs 50. > > > > http://example.net/account/12345/msgs/abc > > >=20 > It would be good to point out that due to the type definitions in the = schema, the whitespace inside is ignorable. I'll leave this to Erik... >=20 >=20 > Editorial nits: >=20 >> Abstract >>=20 >> This document defines a "problem detail" as a way to carry machine- >> readable details of errors in a HTTP response, to avoid the need to >> invent new error response formats for HTTP APIs. >=20 > s/invent/define/ maybe? >=20 >> Note to Readers >>=20 >> This draft should be discussed on the apps-discuss mailing list = [1]. >=20 > add "to be removed by RFC Editor..." >=20 >> 1. Introduction >>=20 >>=20 >> HTTP [RFC7230] status codes are sometimes not sufficient to convey >> enough information about an error to be helpful. While humans = behind >> Web browsers can be informed about the nature of the problem with = an >> HTML [W3C.REC-html401-19991224] response body, non-human consumers = of >> so-called "HTTP APIs" are usually not. >=20 > You probably want to cite HTML5 now. Also, consider shortening the = reference name to "HTML". >=20 >> This specification defines simple JSON [RFC7159] and XML >> [W3C.REC-xml-20081126] document formats to suit this purpose. They >> are designed to be reused by HTTP APIs, which can identify distinct >> "problem types" specific to their needs. >=20 > ...and to "XML". >=20 >> Additionally, problems can contain other information, such as a URI >> that identifies the specific occurrence of the problem (effectively >> giving an identifier to the concept "The time Joe didn't have = enough >> credit last Thursday"), which may be useful for support or forensic >> purposes. >=20 > s/may/can/ >=20 >> 3.1. Problem Details Object Members >>=20 >>=20 >> A problem details object MAY have the following members: >=20 > s/MAY have/can have/ >=20 >> o "title" (string) - A short, human-readable summary of the = problem >> type. It SHOULD NOT change from occurrence to occurrence of the >> problem, except for purposes of localisation. >=20 > Does this imply localisation-per-request (Accept-Language?) >=20 >> The detail member, if present, SHOULD focus on helping the client >> correct the problem, rather than giving debugging information. >=20 > s/SHOULD/ought to/ >=20 >> Finally, an application may have a more appropriate way to carry an >=20 > s/may/might/ >=20 >> That said, it is possible to add support for problem details to >> existing HTTP APIs using HTTP content negotiation (e.g., using the >> Accept request header to indicate a preference for this format). >=20 > Reference Section 5.3.2 of RFC7231. >=20 >> New problem type definitions MUST document: >>=20 >> 1. A type URI (typically, with the "http" scheme), >>=20 >> 2. A title that appropriately describes it (think short), and >>=20 >> 3. The HTTP status code for it to be used with. >>=20 >> Problem types MAY specify the use of the Retry-After response = header >> in appropriate circumstances. >=20 > s/Problem type/Problem type definitions/ >=20 > Also reference Section 7.1.3 of RFC7231. >=20 >> 8.2. Informative References >>=20 >>=20 >> [ISO-19757-2] >> International Organization for Standardization, >> "Information Technology --- Document Schema Definition >> Languages (DSDL) --- Part 2: Grammar-based Validation = --- >> RELAX NG", ISO/IEC 19757-2, 2003. >=20 > This one sounds normative to me. >=20 >> [W3C.REC-xml-20081126] >> Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., = and >> F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth >> Edition)", World Wide Web Consortium Recommendation REC- >> xml-20081126, November 2008, >> . >=20 > Same here. >=20 >> Some HTTP-based APIs use XML [W3C.REC-xml-20081126] as their = primary >> format convention. Such APIs MAY express problem details using the >> format defined in this appendix. >=20 > s/MAY/can/ Thanks! Will incorporate. Thanks again for the detailed and useful feedback. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Dec 8 16:43:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF241A1A78 for ; Mon, 8 Dec 2014 16:43:53 -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 DkKQugmpaLzl for ; Mon, 8 Dec 2014 16:43:51 -0800 (PST) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F1F1A1A43 for ; Mon, 8 Dec 2014 16:43:51 -0800 (PST) Received: from dhcp-128-32-211-236.lips.berkeley.edu ([128.32.211.236]) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1Xy8u5-00070I-Da; Mon, 08 Dec 2014 16:43:50 -0800 Message-ID: <548645C4.6050904@berkeley.edu> Date: Mon, 08 Dec 2014 16:43:48 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Julian F. Reschke" References: <8D25F56B-EEEC-4858-9905-999DA0C6D52F@isode.com> <54855632.6080801@gmx.de> <8BA03684-EAA5-4693-8551-2C1A08C947AB@mnot.net> In-Reply-To: <8BA03684-EAA5-4693-8551-2C1A08C947AB@mnot.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/KNTwU5BiRddeuTQq6BXYOj9kJjE Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-http-problem-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, 09 Dec 2014 00:43:53 -0000 hello julian. thanks for the detailed feedback! On 2014-12-08, 15:35 , Mark Nottingham wrote: >> On 8 Dec 2014, at 6:41 pm, Julian Reschke wrote: >> In the spec: >>> The data model for problem details is a JSON [RFC7159] object; when >>> formatted as a JSON document, it uses the "application/problem+json" >>> media type. Appendix A defines how to express them in an equivalent >>> XML format, which uses the "application/problem+xml" media type. >> Why is this an appendix? > When all things are equal, I'd prefer people to use JSON for APIs, not XML. If we move it to be a peer of the JSON format, we'd need to have some text advising when to use each, and that could get sticky. Putting it in an appendix seemed like a reasonable compromise. If we don't put it in an appendix, I'd almost want to put it in a separate document... to me, it seems like the error serialization should simply match the serialization of the rest of the API, so there wouldn't be a need to recommend anything beyond this. as a side note, for home documents, we have the setup that mark is referring to: two separate documents for JSON and XML: http://tools.ietf.org/html/draft-nottingham-json-home-03 http://tools.ietf.org/html/draft-wilde-home-xml-03 personally, i think it's easier to have one document explain the overall model, and then have two serializations of it in the same documents, but i am fine either way. >>> The OPTIONAL RELAX NG schema [ISO-19757-2] for the XML format is: >> What does "OPTIONAL" mean here? The schema doesn't seem optional at all; lacking it, you wouldn't even know what XML namespace to use. > That's Erik's work, but I tend to agree. i have a hard time remembering why it says "OPTIONAL" here. i think the reason was that we did not want to recommend a specific schema language and were simply using RELAX NG as one possible choice. but i think you're right that the term "OPTIONAL" does not make a lot of sense. >>> default namespace ns = "urn:ietf:rfc:XXXX" >> This needs to state that it will be updated based on the assigned RFC number. > Ack. done. ("Note to RFC Editor: Please replace "XXXX" with assigned RFC number before publication.") >>> Extension arrays and objects can be serialized into the XML format by >>> considering an element containing a child or children to represent an >>> object, except for elements that contain only child element(s) named >>> 'i', which are considered arrays. For example, an alternate version >>> of the example above would appear in XML as: >> This is written like guidance, but it's normative, right? good point. what about this wording instead: Extension arrays and objects are serialized into the XML format by considering an element containing a child or children to represent an object, except for elements that contain only child element(s) named 'i', which are considered arrays. For example, the XML version of the JSON example above would appear as: >>> >>> >>> http://example.com/probs/out-of-credit >>> You do not have enough credit. >>> Your current balance is 30, but that costs 50. >>> >>> http://example.net/account/12345/msgs/abc >>> >> It would be good to point out that due to the type definitions in the schema, the whitespace inside is ignorable. > I'll leave this to Erik... actually, i think in this case it might be less confusing to simply not have this extraneous whitespace in the example, so my suggestion is to change example to simply say: http://example.net/account/12345/msgs/abc thanks again for the review! cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nobody Mon Dec 8 22:35:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EA81A1BFA for ; Mon, 8 Dec 2014 22:35:36 -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 F6W3Zir_9MTi for ; Mon, 8 Dec 2014 22:35: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 93C3A1A1AF2 for ; Mon, 8 Dec 2014 22:35:34 -0800 (PST) Received: from [192.168.2.160] ([93.217.103.122]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M0h9K-1Xh71B2NhO-00unpq; Tue, 09 Dec 2014 07:35:31 +0100 Message-ID: <5486982D.1000203@gmx.de> Date: Tue, 09 Dec 2014 07:35:25 +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: Erik Wilde References: <8D25F56B-EEEC-4858-9905-999DA0C6D52F@isode.com> <54855632.6080801@gmx.de> <8BA03684-EAA5-4693-8551-2C1A08C947AB@mnot.net> <548645C4.6050904@berkeley.edu> In-Reply-To: <548645C4.6050904@berkeley.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:AvbedX7R3MR38dYrzj/PtNgbsfsmQDzY1jRymKnBFeN/ZzX35qs xGz66volZ9y+zN7lWEzzAKTwr7rLOxV3vRXekUwV3jXaaYReWXaAP5LVWBYC9oIR6hZ12KM Spu6gRthNmkHKWR3Bw3Wgxc+NL3gkERLKVNgYvJR1xXlygM+z3eT4o7KhdvcIZ/RPxgnsfO mldAXMmZbbPfZLtvDjLZQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/STfdUytlFbRogk7esOt28VSk9nA Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-http-problem-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, 09 Dec 2014 06:35:36 -0000 On 2014-12-09 01:43, Erik Wilde wrote: >> Putting it in an appendix seemed like a reasonable compromise. If we >> don't put it in an appendix, I'd almost want to put it in a separate >> document... > > to me, it seems like the error serialization should simply match the > serialization of the rest of the API, so there wouldn't be a need to > recommend anything beyond this. Agreed. > ... >>>> default namespace ns = "urn:ietf:rfc:XXXX" >>> This needs to state that it will be updated based on the assigned RFC >>> number. >> Ack. > > done. ("Note to RFC Editor: Please replace "XXXX" with assigned RFC > number before publication.") Actually, this should request assignment of a "urn:ietf:params:xml:ns" URN, no? >>>> Extension arrays and objects can be serialized into the XML >>>> format by >>>> considering an element containing a child or children to >>>> represent an >>>> object, except for elements that contain only child element(s) >>>> named >>>> 'i', which are considered arrays. For example, an alternate >>>> version >>>> of the example above would appear in XML as: >>> This is written like guidance, but it's normative, right? > > good point. what about this wording instead: > > Extension arrays and objects are serialized into the XML format by > considering an element containing a child or children to represent an > object, except for elements that contain only child element(s) named > 'i', which are considered arrays. For example, the XML version of the > JSON example above would appear as: Sounds good. >>>> >>>> >>>> http://example.com/probs/out-of-credit >>>> You do not have enough credit. >>>> Your current balance is 30, but that costs 50. >>>> >>>> http://example.net/account/12345/msgs/abc >>>> >>> It would be good to point out that due to the type definitions in the >>> schema, the whitespace inside is ignorable. >> I'll leave this to Erik... > > actually, i think in this case it might be less confusing to simply not > have this extraneous whitespace in the example, so my suggestion is to > change example to simply say: > > http://example.net/account/12345/msgs/abc > > thanks again for the review! cheers, OK, so now we are avoiding the question about ignorable whitespace. So it's not ignorable, right? Best regards, Julian From nobody Mon Dec 8 23:26:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3459F1A014C for ; Mon, 8 Dec 2014 23:26: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 EL39dN7Y9ZUg for ; Mon, 8 Dec 2014 23:26:17 -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 CD07A1A1A45 for ; Mon, 8 Dec 2014 23:26:16 -0800 (PST) Received: from [192.168.2.160] ([93.217.73.16]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MC3zg-1Y70cu1Geu-008tdj; Tue, 09 Dec 2014 08:26:12 +0100 Message-ID: <5486A40C.1080404@gmx.de> Date: Tue, 09 Dec 2014 08:26:04 +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: <8D25F56B-EEEC-4858-9905-999DA0C6D52F@isode.com> <54855632.6080801@gmx.de> <8BA03684-EAA5-4693-8551-2C1A08C947AB@mnot.net> In-Reply-To: <8BA03684-EAA5-4693-8551-2C1A08C947AB@mnot.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:zFkjCPFRYihYhIoTyXzAIBqQMXKmbcpoKwSx6WGmXfPB7eUkLUp 7wbjalxPpTuL0JnB5+PCY2shulYbdyp/C089wW9HhcDKkjxl3D+wUbkCXqDMNAR/m/A7FIz ULcPydn0HkNOor4GeV9q0j0sHb7Dk6E9FiGkVB+oixVyXvDCk2rj7J6sqegCfabisPWjafc zybgj130HR6JzbyxUNdiQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XdKVtL3w2X6V2FMXkrZgvflAmVM Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-http-problem-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, 09 Dec 2014 07:26:28 -0000 On 2014-12-09 00:35, Mark Nottingham wrote: > Guten Abend, Julian. > >> On 8 Dec 2014, at 6:41 pm, Julian Reschke wrote: >> >> Hi, >> >> below some feedback. >> >> Not in the spec: >> >> 1) The spec doesn't mention that this sort of duplicates earlier work done in WebDAV; see > > If this were an academic paper, I think that'd be important. As a spec, I'm not sure that it is. > >> 2) The spec talks about using Accept to instruct the server whether to return problem details or HTML. Maybe it would be worthwhile to mention that if you use XML, you could *always* send problem details, and then use to instruct the UA to convert to HTML; that would get rid of the conneg complexity. > > I'm not sure that browsers are going to support XSLT in the long run. They do right now, and this can be used to avoid conneg altogether. Just saying. >> In the spec: >> >>> The data model for problem details is a JSON [RFC7159] object; when >>> formatted as a JSON document, it uses the "application/problem+json" >>> media type. Appendix A defines how to express them in an equivalent >>> XML format, which uses the "application/problem+xml" media type. >> >> Why is this an appendix? > > When all things are equal, I'd prefer people to use JSON for APIs, not XML. If we move it to be a peer of the JSON format, we'd need to have some text advising when to use each, and that could get sticky. Putting it in an appendix seemed like a reasonable compromise. If we don't put it in an appendix, I'd almost want to put it in a separate document... I disagree that we need to advise which to use. > ... Best regards, Julian From nobody Tue Dec 9 04:14:35 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506541A1BCC for ; Tue, 9 Dec 2014 04:14: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 m918pkelffrz for ; Tue, 9 Dec 2014 04:14:30 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3B91A00F0 for ; Tue, 9 Dec 2014 04:14:29 -0800 (PST) Received: from mfilter6-d.gandi.net (mfilter6-d.gandi.net [217.70.178.135]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 56FF6172090 for ; Tue, 9 Dec 2014 13:14:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter6-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter6-d.gandi.net (mfilter6-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id jLSeGtOvLplq for ; Tue, 9 Dec 2014 13:14:27 +0100 (CET) X-Originating-IP: 91.64.210.128 Received: from [192.168.178.195] (ip5b40d280.dynamic.kabel-deutschland.de [91.64.210.128]) (Authenticated sender: anything@michielbdejong.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id B8B591720C9 for ; Tue, 9 Dec 2014 13:14:26 +0100 (CET) Message-ID: <5486E7A1.8000902@michielbdejong.com> Date: Tue, 09 Dec 2014 13:14:25 +0100 From: Michiel de Jong 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 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/efZQkPTyLZSFtn2JTFNzZnArAzM Subject: [apps-discuss] draft-dejong-remotestorage-04 teleconf about release candidate tomorrow X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 12:14:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We prepared a release candidate for draft-dejong-remotestorage-04, here: https://github.com/remotestorage/spec/releases/tag/04-rc5 We will have a teleconf about it tomorrow, 4pm Berlin time; see: http://community.remotestorage.io/t/teleconf-10-december/237/9 Hope to see you there! Cheers, Michiel. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUhuehAAoJECmDVpL5muhKAZsP/2Wd8aFjzmCnRVplFUMA5bnN 6j62NLUptTXKGzQ5bXrrUE9bYX6Th0R6WfLeQkUIcIFQqDW8ADKHtpXXidE13yhh y19tA2ttLlaJMSRVVhykUbM40jx22thIjS5cwbkV5B/NsVrWF04Q5VlrbsxC26BM mFrWIPE+p0otN+TONkePUs04361y5jKalSsRt6oZLe0aJqdAvLlo1hLu3Kd1QYv+ 37+fe4OGs+Z4dpf+b1GNyM5LVyL7F4VpSjG3LVpQBCfrSu0+YRX9Z0ApJpILac7J q/A7O8YgLZXjAplDmYfB6DX22hGXHDQVOWW3megYv0uk4jAh/mUbbXvcaY+BfhH5 w65iQndS4kJZwsZqh8vW1In+aV86U00A6WOJWkg656L+78pds9uL3CwKPITY4Zjm hB2VgQuVw2yvD3kpC1xXlcz8PY625/2Ej4tbQ5bjD0RcSGY1lG+QodV8fioyyyAm LPZA9G6JZ9QNRMoyfPTIkyWq8zxIGdtU4Wn5V8IgNVQQbCGh1uecDOeOLK3DP3e9 A6pyYreNryf63E6spFPzwhpB+blKitFHvdsCSSAYHbJgV0kvyQwjJNGGVr/cKC1d KBTz2m179w5kT/PNGl2Xv8ASyZNryEVQG4inVAiUT2XAqZVhF860zX/rtjsJlh0K ZP7hbVq0ZYbCroZHKewT =JP8h -----END PGP SIGNATURE----- From nobody Tue Dec 9 09:22:22 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9861A89B8 for ; Tue, 9 Dec 2014 09:22:21 -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 5LsdhAzTDhjI for ; Tue, 9 Dec 2014 09:22:19 -0800 (PST) Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49CF1A701C for ; Tue, 9 Dec 2014 09:22:07 -0800 (PST) Received: from dhcp-128-32-211-236.lips.berkeley.edu ([128.32.211.236]) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1XyOU7-00013K-8c; Tue, 09 Dec 2014 09:22:04 -0800 Message-ID: <54872FBB.5080406@berkeley.edu> Date: Tue, 09 Dec 2014 09:22:03 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Julian Reschke References: <8D25F56B-EEEC-4858-9905-999DA0C6D52F@isode.com> <54855632.6080801@gmx.de> <8BA03684-EAA5-4693-8551-2C1A08C947AB@mnot.net> <548645C4.6050904@berkeley.edu> <5486982D.1000203@gmx.de> In-Reply-To: <5486982D.1000203@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/tnmjKadjrffCTlo2PrOSFtAv8CM Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-http-problem-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, 09 Dec 2014 17:22:21 -0000 hello julian. On 2014-12-08, 22:35 , Julian Reschke wrote: > On 2014-12-09 01:43, Erik Wilde wrote: >>>>> default namespace ns = "urn:ietf:rfc:XXXX" >>>> This needs to state that it will be updated based on the assigned RFC >>>> number. >>> Ack. >> done. ("Note to RFC Editor: Please replace "XXXX" with assigned RFC >> number before publication.") > Actually, this should request assignment of a "urn:ietf:params:xml:ns" > URN, no? not necessarily, no. all we need is a unique URI to identify the namespace for HTTP problems in XML. the simpler urn:ietf:rfc:XXXX form is sufficient here, and there is no registration requirement for those URIs (RFC 2648 defines this IETF URN namespace). >>>>> >>>>> >>>>> http://example.com/probs/out-of-credit >>>>> You do not have enough credit. >>>>> Your current balance is 30, but that costs 50. >>>>> >>>>> http://example.net/account/12345/msgs/abc >>>>> >>>> It would be good to point out that due to the type definitions in the >>>> schema, the whitespace inside is ignorable. >>> I'll leave this to Erik... >> actually, i think in this case it might be less confusing to simply not >> have this extraneous whitespace in the example, so my suggestion is to >> change example to simply say: >> http://example.net/account/12345/msgs/abc >> thanks again for the review! cheers, > OK, so now we are avoiding the question about ignorable whitespace. So > it's not ignorable, right? i would want to avoid any processing model that depends on knowing and using the/a schema. that's usually a problem, because many implementations will simply operate on the XML parse tree and not apply any kind of schema validation/processing. i think i am not quite sure what you would want to see here. the value contained in the XML element "means" the same as a value contained in the corresponding JSON serialization; any difference between them means that the serialized HTTP problem object has those differences as well. thanks and cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nobody Tue Dec 9 09:29:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E19C1A8779 for ; Tue, 9 Dec 2014 09:29: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, 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 ArS5oM2Id2VK for ; Tue, 9 Dec 2014 09:29:22 -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 A89911A700C for ; Tue, 9 Dec 2014 09:29:19 -0800 (PST) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M1n4s-1XifEE24aI-00tmqJ; Tue, 09 Dec 2014 18:29:16 +0100 Message-ID: <54873166.1000603@gmx.de> Date: Tue, 09 Dec 2014 18:29:10 +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: Erik Wilde References: <8D25F56B-EEEC-4858-9905-999DA0C6D52F@isode.com> <54855632.6080801@gmx.de> <8BA03684-EAA5-4693-8551-2C1A08C947AB@mnot.net> <548645C4.6050904@berkeley.edu> <5486982D.1000203@gmx.de> <54872FBB.5080406@berkeley.edu> In-Reply-To: <54872FBB.5080406@berkeley.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:DGsgSquMsUcIhprODTVQEvexNfgXY1Qjc1nnNfOUKKEzdjs6/g3 eutsXjLr6fcL0B6cxWPwdHI0rSU/XFq9QzXgLwLkd/Z5lJo6jqgs6wA0+88l65NZuU2krfF ovJEcxmeeLsfq2wNWE2P9zOioIiXf9TqlL2MFUmbTH7Op3c62I607jav5tbV+7ukGYixTNz 1cIUwinkeR2rzPe9ldQxA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/4w8FAhvWKyMh3_RYUv-qDDpQjw8 Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-http-problem-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, 09 Dec 2014 17:29:25 -0000 On 2014-12-09 18:22, Erik Wilde wrote: > hello julian. > > On 2014-12-08, 22:35 , Julian Reschke wrote: >> On 2014-12-09 01:43, Erik Wilde wrote: >>>>>> default namespace ns = "urn:ietf:rfc:XXXX" >>>>> This needs to state that it will be updated based on the assigned RFC >>>>> number. >>>> Ack. >>> done. ("Note to RFC Editor: Please replace "XXXX" with assigned RFC >>> number before publication.") >> Actually, this should request assignment of a "urn:ietf:params:xml:ns" >> URN, no? > > not necessarily, no. all we need is a unique URI to identify the > namespace for HTTP problems in XML. the simpler urn:ietf:rfc:XXXX form > is sufficient here, and there is no registration requirement for those > URIs (RFC 2648 defines this IETF URN namespace). Hmmm. I think it'll cause confusion. I also think that not having the rfc# in it will be better in case we'll ever revise this document. >>>>>> >>>>>> >>>>>> http://example.com/probs/out-of-credit >>>>>> You do not have enough credit. >>>>>> Your current balance is 30, but that costs 50. >>>>>> >>>>>> http://example.net/account/12345/msgs/abc >>>>>> >>>>> It would be good to point out that due to the type definitions in the >>>>> schema, the whitespace inside is ignorable. >>>> I'll leave this to Erik... >>> actually, i think in this case it might be less confusing to simply not >>> have this extraneous whitespace in the example, so my suggestion is to >>> change example to simply say: >>> http://example.net/account/12345/msgs/abc >>> thanks again for the review! cheers, >> OK, so now we are avoiding the question about ignorable whitespace. So >> it's not ignorable, right? > > i would want to avoid any processing model that depends on knowing and > using the/a schema. that's usually a problem, because many > implementations will simply operate on the XML parse tree and not apply > any kind of schema validation/processing. +1 > i think i am not quite sure what you would want to see here. the value > contained in the XML element "means" the same as a value contained in > the corresponding JSON serialization; any difference between them means > that the serialized HTTP problem object has those differences as well. OK, so then let's agree that the example was misleading :-) Best regards, Julian From nobody Tue Dec 9 11:54:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC7E1A0026 for ; Tue, 9 Dec 2014 11:54:11 -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 jrkcg1-QgAuJ for ; Tue, 9 Dec 2014 11:54:09 -0800 (PST) Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0B961A0013 for ; Tue, 9 Dec 2014 11:54:08 -0800 (PST) Received: from dhcp-128-32-211-236.lips.berkeley.edu ([128.32.211.236]) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1XyQrE-0007lj-LZ; Tue, 09 Dec 2014 11:54:05 -0800 Message-ID: <5487535B.5020007@berkeley.edu> Date: Tue, 09 Dec 2014 11:54:03 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Julian Reschke References: <8D25F56B-EEEC-4858-9905-999DA0C6D52F@isode.com> <54855632.6080801@gmx.de> <8BA03684-EAA5-4693-8551-2C1A08C947AB@mnot.net> <548645C4.6050904@berkeley.edu> <5486982D.1000203@gmx.de> <54872FBB.5080406@berkeley.edu> <54873166.1000603@gmx.de> In-Reply-To: <54873166.1000603@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/8dUg1367ZvQW1gCS9twLbQJc8Uo Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-http-problem-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, 09 Dec 2014 19:54:12 -0000 hello julian. On 2014-12-09, 9:29 , Julian Reschke wrote: > On 2014-12-09 18:22, Erik Wilde wrote: >> On 2014-12-08, 22:35 , Julian Reschke wrote: >>> Actually, this should request assignment of a "urn:ietf:params:xml:ns" >>> URN, no? >> not necessarily, no. all we need is a unique URI to identify the >> namespace for HTTP problems in XML. the simpler urn:ietf:rfc:XXXX form >> is sufficient here, and there is no registration requirement for those >> URIs (RFC 2648 defines this IETF URN namespace). > Hmmm. I think it'll cause confusion. I also think that not having the > rfc# in it will be better in case we'll ever revise this document. i am pretty sure it works either way. it's as simple as it gets for a URI that clearly identifies an RFC. and as long as the "XML schema" stays the same, it should be identified by the same URI, and when it gets changed in a possible future update of the spec, then the URI should change anyway to identify the new schema. >>>>>>> >>>>>>> http://example.net/account/12345/msgs/abc >>>>>>> >>>> actually, i think in this case it might be less confusing to simply not >>>> have this extraneous whitespace in the example, so my suggestion is to >>>> change example to simply say: >>>> http://example.net/account/12345/msgs/abc >> i think i am not quite sure what you would want to see here. the value >> contained in the XML element "means" the same as a value contained in >> the corresponding JSON serialization; any difference between them means >> that the serialized HTTP problem object has those differences as well. > OK, so then let's agree that the example was misleading :-) thanks for spotting it! cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nobody Tue Dec 9 11:55:16 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5490B1A038D for ; Tue, 9 Dec 2014 11:55:14 -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 L971jzkfbJ6t for ; Tue, 9 Dec 2014 11:55:10 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0661.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::661]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65E71A19F4 for ; Tue, 9 Dec 2014 11:55:07 -0800 (PST) Received: from DM2PR0201MB0958.namprd02.prod.outlook.com (25.160.216.26) by DM2PR0201MB1072.namprd02.prod.outlook.com (25.160.221.141) with Microsoft SMTP Server (TLS) id 15.1.31.17; Tue, 9 Dec 2014 19:54:44 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0958.namprd02.prod.outlook.com (25.160.216.26) with Microsoft SMTP Server (TLS) id 15.1.31.17; Tue, 9 Dec 2014 19:54:42 +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.0031.000; Tue, 9 Dec 2014 19:54:42 +0000 From: Larry Masinter To: Matthew Kerwin , IETF Apps Discuss Thread-Topic: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt Thread-Index: AQHP2Sc1jlL4BTpaWESzwAi/oPo9Z5yIE6gA Date: Tue, 9 Dec 2014 19:54:41 +0000 Message-ID: References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:9:8380:992:11e1:2b8e:743a:254b] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB0958;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB0958; x-forefront-prvs: 0420213CCD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(2473001)(189002)(377424004)(377454003)(199003)(69234005)(74316001)(122556002)(19617315012)(21056001)(54206007)(97736003)(587094005)(62966003)(77156002)(4396001)(2420400003)(46102003)(68736005)(120916001)(107046002)(102836002)(15975445007)(14971765001)(99396003)(230783001)(19580405001)(31966008)(19580395003)(19625215002)(40100003)(101416001)(16601075003)(106356001)(19609705001)(33656002)(106116001)(99286002)(105586002)(50986999)(20776003)(19300405004)(64706001)(87936001)(54356999)(2656002)(76176999)(16236675004)(92566001)(86362001)(54606007)(76576001)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0958; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_DM2PR0201MB09602B351692D424A49C6B0DC3650DM2PR0201MB0960_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB1072; X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/NsOYamN15GcMrSV1bBuOrA5XirY Cc: Sam Ruby 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, 09 Dec 2014 19:55:14 -0000 --_000_DM2PR0201MB09602B351692D424A49C6B0DC3650DM2PR0201MB0960_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhcHBsYXVkIHRoZSBtb3ZlIHRvIGRvY3VtZW50IGZpbGU6Lg0KDQpUaHJlZSBjb21tZW50cyBv biBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rZXJ3aW4tZmlsZS1zY2hlbWUNCg0K Rmlyc3QgY29tbWVudDoNCg0KUGxlYXNlIGFsaWduIHdpdGggdGhlIHNwZWNpYWwgcHJvY2Vzc2lu ZyBmb3Ig4oCcZmlsZTrigJ0gaW46DQpodHRwczovL3NwZWNzLndlYnBsYXRmb3JtLm9yZy91cmwv d2Vic3BlY3MvZGV2ZWxvcC8NCg0KVGhhdCBzcGVjIChkZXZlbG9wZWQgaW4gc3luYyB3aXRoIFdI QVRXRyBVUkwpIGZvY3VzZXMgb24NCnBhcnNpbmcgYW5kIHByb2Nlc3Npbmcgb2YgYmFzZSArIHJl bGF0aXZlLCB3aGVuIHRoZSBzY2hlbWUNCihvciBiYXNlIHNjaGVtZSkgaXMgIOKAnGZpbGU64oCd LCB3aGlsZSB0aGUga2Vyd2luLWZpbGUtc2NoZW1lDQp0YWxrcyBtb3JlIGFib3V0IG1hcHBpbmcg YmV0d2VlbiBsb2NhbCBmaWxlIHBhdGhzIGFuZCDigJxmaWxlOuKAnQ0KSVJJcyAoVVJMcykuDQoN CkJ1dCB0aGUgb3ZlcmxhcCBpcyBzaWduaWZpY2FudCwgYW5kIEkgaG9wZSBjb3VsZCBiZSBlbGlt aW5hdGVkLA0KaWYgdGhlIGRpcmVjdGlvbiBvZiBtb3ZpbmcgdGhlIHdlYnBsYXRmb3JtLm9yZyBz cGVjIHRvDQpvYnNvbGV0ZSAzOTg3IGlzIGFjY2VwdGVkLg0KDQpTZWNvbmQgY29tbWVudDoNCg0K WW91IGRlc2NyaWJlIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBsb2NhbCBmaWxlIG5hbWVzDQph bmQg4oCYZmlsZTrigJkgVVJMUyBmb3Ig4oCcVU5JWC1saWtl4oCdLCDigJxET1MtIG9yIFdpbmRv d3MtYmFzZWTigJ0NCmFuZCDigJxWTVMgRmlsZXMtMTHigJ0uIFRoZXNlIGNhdGVnb3JpZXMgYXJl buKAmXQgcHJlY2lzZSBvcg0KZXhoYXVzdGl2ZSwgYW5kIGZpbGUgc3lzdGVtIHByb2Nlc3Npbmcg b2YgZmlsZSBuYW1lcyBjYW4NCnZhcnkgZGVwZW5kaW5nIG9uIHZlcnNpb24sIGxhbmd1YWdlIHBh Y2sgaW5zdGFsbGVkIGluIE9TLA0KYXMgd2VsbCBhcyBuZXR3b3JrIHByb3RvY29sIChOZnM/KS4N Cg0KSSB3b3VsZCByYXRoZXIgc2VlIGEgbW9yZSBleHRlbnNpYmxlIG9yZ2FuaXphdGlvbiBvZg0K dGhlIHNwZWNpZmljYXRpb24gYnkgZXN0YWJsaXNoaW5nIGEgdGVtcGxhdGUsIGFuZCB0aGVuDQpz ZXBhcmF0ZWx5IGRvY3VtZW50aW5nLCBvbiBhIGZpbGUtc3lzdGVtIGJ5IGZpbGUtc3lzdGVtDQpi YXNpcywgaG93IHRvIHRyYW5zbGF0ZSBhbmQgbWF0Y2gsIGJhc2VkIG5vdCBvbiB0aGUNClVSSSBi dXQgb24gdGhlIHBhcnNlZCBjb21wb25lbnRzIHJlc3VsdGluZyBmcm9tDQpVUkwtcGFyc2luZy4g VGhpcyB3b3VsZCBhbGxvdyBuZXcgb3IgZGlmZmVyZW50IGZpbGUNCnN5c3RlbXMgdG8gYmUgZG9j dW1lbnRlZC4NCg0KVGhpcmQgY29tbWVudDoNCg0KVGhlIHRyYW5zbGF0aW9uIGJldHdlZW4gZmls ZSBuYW1lcyBhbmQgVVJMcyBhbmQgdGhpbmdzDQpsaWtlIHRoZW0gaGFwcGVuIGluIHNldmVyYWwg c3BlY3M6DQoNCmNvbnRlbnQtZGlzcG9zaXRpb24gZm9yIGZpbGUgZG93bmxvYWQsIG11bHRpcGFy dC9mb3JtLWRhdGENCmZvciBmaWxlIHVwbG9hZCwgYnkgY29tbW9uIEhUVFAgc2VydmVycywgd2hl biBwYWNrYWdpbmcgZmlsZXMNCnRvZ2V0aGVyIGludG8gYXJjaGl2ZSB0eXBlcyBhcyBiZWluZyBk aXNjdXNzZWQgYnkgdGhvc2UgcHJvcG9zaW5nDQphIG5ldyDigJhhcmNoaXZl4oCZIHRvcCBsZXZl bCBtZWRpYSB0eXBlLg0KDQpJdCB3b3VsZCBiZSBiZW5lZmljaWFsIGlmIHdlIGNvbnZlcmdlIHRo ZXNlLCBhcyBpdCByZWR1Y2VzIGludGVyb3BlcmFiaWxpdHkNCnRvIGhhdmUgaW5jb21wYXRpYmxl IG1ldGhvZHMgb2YgdHJhbnNsYXRpb24gZm9yIGxvY2FsIGZpbGVzIG5hbWVzIGRlcGVuZGluZw0K b24gdGhlIGNhdGVnb3JpemF0aW9uLg0KDQpMYXJyeQ0KLS0NCmh0dHA6Ly9sYXJyeS5tYXNpbnRl ci5uZXQNCg0KRnJvbTogYXBwcy1kaXNjdXNzIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXR0aGV3IEtlcndpbg0KU2VudDogVGh1cnNkYXksIFNl cHRlbWJlciAyNSwgMjAxNCA2OjEzIFBNDQpUbzogSUVURiBBcHBzIERpc2N1c3M7IHVyaUB3My5v cmcNClN1YmplY3Q6IFthcHBzLWRpc2N1c3NdIEZ3ZDogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQta2Vyd2luLWZpbGUtc2NoZW1lLTEzLnR4dA0KDQpGWUk6IHRoaXMgaXMg bXkgZmlsZSBVUkkgZHJhZnQsIG5vdyBsaXN0aW5nIGFwcHMtZGlzY3VzcyBhcyB0aGUgb2ZmaWNp YWwgcGxhY2UgZm9yIGRpc2N1c3Npb24uDQoNCj4+Pg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQta2Vyd2luLWZpbGUtc2NoZW1lLTEzLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBNYXR0aGV3IEtlcndpbiBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0 b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQta2Vyd2luLWZpbGUtc2NoZW1lDQpSZXZpc2lv bjogICAgICAgMTMNClRpdGxlOiAgICAgICAgICBUaGUgZmlsZSBVUkkgU2NoZW1lDQpEb2N1bWVu dCBkYXRlOiAgMjAxNC0wOS0yNg0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lv bg0KUGFnZXM6ICAgICAgICAgIDE2DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQta2Vyd2luLWZpbGUtc2NoZW1lLTEzLnR4dA0KU3RhdHVz OiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtlcndpbi1m aWxlLXNjaGVtZS8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1rZXJ3aW4tZmlsZS1zY2hlbWUtMTMNCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1rZXJ3aW4tZmlsZS1zY2hlbWUtMTMNCg0KQWJzdHJh Y3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgImZpbGUiIFVuaWZvcm0gUmVzb3Vy Y2UgSWRlbnRpZmllciAoVVJJKQ0KICAgc2NoZW1lLCByZXBsYWNpbmcgdGhlIGRlZmluaXRpb24g aW4gUkZDIDE3MzguDQoNCiAgIEl0IGF0dGVtcHRzIHRvIGRvY3VtZW50IGN1cnJlbnQgcHJhY3Rp Y2VzLCB3aGlsZSBhdCB0aGUgc2FtZSB0aW1lDQogICBkZWZpbmluZyBhIGNvbW1vbiBjb3JlIHdo aWNoIGlzIGludGVuZGVkIHRvIGludGVyb3BlcmF0ZSBhY3Jvc3MgdGhlDQogICBicm9hZCBzcGVj dHJ1bSBvZiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMuDQoNCk5vdGUgdG8gUmVhZGVycyAoVG8g YmUgcmVtb3ZlZCBieSB0aGUgUkZDIEVkaXRvcikNCg0KICAgVGhpcyBkcmFmdCBzaG91bGQgYmUg ZGlzY3Vzc2VkIG9uIHRoZSBJRVRGIEFwcGxpY2F0aW9ucyBBcmVhIFdvcmtpbmcNCiAgIEdyb3Vw IGRpc2N1c3Npb24gbGlzdCA8YXBwcy1kaXNjdXNzQGlldGYub3JnPG1haWx0bzphcHBzLWRpc2N1 c3NAaWV0Zi5vcmc+Pi4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxo dHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg0KLS0N CiAgTWF0dGhldyBLZXJ3aW4NCiAgaHR0cDovL21hdHRoZXcua2Vyd2luLm5ldC5hdS8NCg== --_000_DM2PR0201MB09602B351692D424A49C6B0DC3650DM2PR0201MB0960_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpHZW9yZ2lhOw0KCXBhbm9zZS0xOjIgNCA1 IDIgNSA0IDUgMiAzIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYXBwbGF1ZCB0aGUg bW92ZSB0byBkb2N1bWVudCBmaWxlOi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+VGhyZWUgY29tbWVudHMgb24NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWtlcndpbi1maWxlLXNjaGVtZSI+aHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQta2Vyd2luLWZpbGUtc2NoZW1lPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6bm9uZTtib3Jk ZXItYm90dG9tOmRvdWJsZSB3aW5kb3d0ZXh0IDIuMjVwdDtwYWRkaW5nOjBpbiAwaW4gMS4wcHQg MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJib3JkZXI6bm9uZTtwYWRkaW5nOjBp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkZpcnN0IGNvbW1lbnQ6PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBs ZWFzZSBhbGlnbiB3aXRoIHRoZSBzcGVjaWFsIHByb2Nlc3NpbmcgZm9yIOKAnGZpbGU64oCdIGlu Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vc3BlY3Mud2VicGxhdGZvcm0ub3JnL3VybC93ZWJzcGVj cy9kZXZlbG9wLyI+aHR0cHM6Ly9zcGVjcy53ZWJwbGF0Zm9ybS5vcmcvdXJsL3dlYnNwZWNzL2Rl dmVsb3AvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhh dCBzcGVjIChkZXZlbG9wZWQgaW4gc3luYyB3aXRoIFdIQVRXRyBVUkwpIGZvY3VzZXMgb24NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5wYXJzaW5nIGFuZCBwcm9jZXNzaW5nIG9mIGJhc2UgJiM0MzsgcmVs YXRpdmUsIHdoZW4gdGhlIHNjaGVtZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4ob3IgYmFzZSBzY2hlbWUp IGlzJm5ic3A7IOKAnGZpbGU64oCdLCB3aGlsZSB0aGUga2Vyd2luLWZpbGUtc2NoZW1lPGJyPg0K dGFsa3MgbW9yZSBhYm91dCBtYXBwaW5nIGJldHdlZW4gbG9jYWwgZmlsZSBwYXRocyBhbmQg4oCc ZmlsZTrigJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SVJJcyAoVVJMcykuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJ1dCB0aGUgb3ZlcmxhcCBpcyBzaWduaWZpY2Fu dCwgYW5kIEkgaG9wZSBjb3VsZCBiZSBlbGltaW5hdGVkLDxicj4NCmlmIHRoZSBkaXJlY3Rpb24g b2YgbW92aW5nIHRoZSB3ZWJwbGF0Zm9ybS5vcmcgc3BlYyB0bzxicj4NCm9ic29sZXRlIDM5ODcg aXMgYWNjZXB0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1l bnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpub25lO2JvcmRlci1ib3R0b206ZG91YmxlIHdpbmRv d3RleHQgMi4yNXB0O3BhZGRpbmc6MGluIDBpbiAxLjBwdCAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U2Vjb25kIGNvbW1l bnQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Zb3UgZGVzY3Jp YmUgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGxvY2FsIGZpbGUgbmFtZXM8YnI+DQphbmQg4oCY ZmlsZTrigJkgVVJMUyBmb3Ig4oCcVU5JWC1saWtl4oCdLCDigJxET1MtIG9yIFdpbmRvd3MtYmFz ZWTigJ08YnI+DQphbmQg4oCcVk1TIEZpbGVzLTEx4oCdLiBUaGVzZSBjYXRlZ29yaWVzIGFyZW7i gJl0IHByZWNpc2Ugb3I8YnI+DQpleGhhdXN0aXZlLCBhbmQgZmlsZSBzeXN0ZW0gcHJvY2Vzc2lu ZyBvZiBmaWxlIG5hbWVzIGNhbjxicj4NCnZhcnkgZGVwZW5kaW5nIG9uIHZlcnNpb24sIGxhbmd1 YWdlIHBhY2sgaW5zdGFsbGVkIGluIE9TLDxicj4NCmFzIHdlbGwgYXMgbmV0d29yayBwcm90b2Nv bCAoTmZzPykuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB3 b3VsZCByYXRoZXIgc2VlIGEgbW9yZSBleHRlbnNpYmxlIG9yZ2FuaXphdGlvbiBvZg0KPGJyPg0K dGhlIHNwZWNpZmljYXRpb24gYnkgZXN0YWJsaXNoaW5nIGEgdGVtcGxhdGUsIGFuZCB0aGVuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPnNlcGFyYXRlbHkgZG9jdW1lbnRpbmcsIG9uIGEgZmlsZS1zeXN0ZW0g YnkgZmlsZS1zeXN0ZW08YnI+DQpiYXNpcywgaG93IHRvIHRyYW5zbGF0ZSBhbmQgbWF0Y2gsIGJh c2VkIG5vdCBvbiB0aGU8YnI+DQpVUkkgYnV0IG9uIHRoZSBwYXJzZWQgY29tcG9uZW50cyByZXN1 bHRpbmcgZnJvbTxicj4NClVSTC1wYXJzaW5nLiBUaGlzIHdvdWxkIGFsbG93IG5ldyBvciBkaWZm ZXJlbnQgZmlsZTxicj4NCnN5c3RlbXMgdG8gYmUgZG9jdW1lbnRlZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOm5v bmU7Ym9yZGVyLWJvdHRvbTpkb3VibGUgd2luZG93dGV4dCAyLjI1cHQ7cGFkZGluZzowaW4gMGlu IDEuMHB0IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYm9yZGVyOm5vbmU7cGFk ZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5UaGlyZCBjb21tZW50OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+VGhlIHRyYW5zbGF0aW9uIGJldHdlZW4gZmlsZSBuYW1lcyBhbmQg VVJMcyBhbmQgdGhpbmdzPGJyPg0KbGlrZSB0aGVtIGhhcHBlbiBpbiBzZXZlcmFsIHNwZWNzOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Y29udGVudC1kaXNwb3Np dGlvbiBmb3IgZmlsZSBkb3dubG9hZCwgbXVsdGlwYXJ0L2Zvcm0tZGF0YTxicj4NCmZvciBmaWxl IHVwbG9hZCwgYnkgY29tbW9uIEhUVFAgc2VydmVycywgd2hlbiBwYWNrYWdpbmcgZmlsZXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+dG9nZXRoZXIgaW50byBhcmNoaXZlIHR5cGVzIGFzIGJlaW5nIGRpc2N1 c3NlZCBieSB0aG9zZSBwcm9wb3NpbmcNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hIG5ldyDigJhhcmNo aXZl4oCZIHRvcCBsZXZlbCBtZWRpYSB0eXBlLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5JdCB3b3VsZCBiZSBiZW5lZmljaWFsIGlmIHdlIGNvbnZlcmdlIHRo ZXNlLCBhcyBpdCByZWR1Y2VzIGludGVyb3BlcmFiaWxpdHkNCjxicj4NCnRvIGhhdmUgaW5jb21w YXRpYmxlIG1ldGhvZHMgb2YgdHJhbnNsYXRpb24gZm9yIGxvY2FsIGZpbGVzIG5hbWVzIGRlcGVu ZGluZzxicj4NCm9uIHRoZSBjYXRlZ29yaXphdGlvbi48YnI+DQo8YnI+DQpMYXJyeTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5odHRwOi8vbGFycnkubWFzaW50ZXIubmV0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4gYXBwcy1kaXNjdXNzIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1hdHRoZXcgS2Vyd2luPGJyPg0KPGI+U2VudDo8 L2I+IFRodXJzZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMTQgNjoxMyBQTTxicj4NCjxiPlRvOjwvYj4g SUVURiBBcHBzIERpc2N1c3M7IHVyaUB3My5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2FwcHMt ZGlzY3Vzc10gRndkOiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1rZXJ3 aW4tZmlsZS1zY2hlbWUtMTMudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 R2VvcmdpYSZxdW90OyxzZXJpZjtjb2xvcjojMDczNzYzIj5GWUk6IHRoaXMgaXMgbXkgZmlsZSBV UkkgZHJhZnQsIG5vdyBsaXN0aW5nIGFwcHMtZGlzY3VzcyBhcyB0aGUgb2ZmaWNpYWwgcGxhY2Ug Zm9yIGRpc2N1c3Npb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEm cXVvdDssc2VyaWY7Y29sb3I6IzA3Mzc2MyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2VyaWY7Y29sb3I6IzA3Mzc2MyI+Jmd0OyZndDsmZ3Q7 PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQta2Vyd2luLWZpbGUtc2NoZW1lLTEzLnR4dDxicj4NCmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWF0dGhldyBLZXJ3aW4gYW5kIHBvc3RlZCB0byB0aGU8 YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWtlcndpbi1maWxlLXNjaGVtZTxicj4NClJldmlz aW9uOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzEzPGJyPg0KVGl0bGU6Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGUgZmlsZSBVUkkgU2NoZW1lPGJyPg0KRG9jdW1lbnQg ZGF0ZTombmJzcDsgMjAxNC0wOS0yNjxicj4NCkdyb3VwOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KUGFnZXM6Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAxNjxicj4NClVSTDombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1rZXJ3aW4tZmlsZS1zY2hlbWUtMTMudHh0IiB0YXJnZXQ9Il9ibGFuayI+ DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1rZXJ3aW4tZmlsZS1z Y2hlbWUtMTMudHh0PC9hPjxicj4NClN0YXR1czombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta2Vy d2luLWZpbGUtc2NoZW1lLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWtlcndpbi1maWxlLXNjaGVtZS88L2E+PGJyPg0KSHRtbGl6ZWQ6Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQta2Vyd2luLWZpbGUtc2NoZW1lLTEzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQta2Vyd2luLWZpbGUtc2NoZW1lLTEzPC9hPjxicj4NCkRp ZmY6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRw Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1rZXJ3aW4tZmlsZS1zY2hlbWUtMTMi IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1r ZXJ3aW4tZmlsZS1zY2hlbWUtMTM8L2E+PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7 ICZuYnNwO1RoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSAmcXVvdDtmaWxlJnF1b3Q7IFVuaWZv cm0gUmVzb3VyY2UgSWRlbnRpZmllciAoVVJJKTxicj4NCiZuYnNwOyAmbmJzcDtzY2hlbWUsIHJl cGxhY2luZyB0aGUgZGVmaW5pdGlvbiBpbiBSRkMgMTczOC48YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7SXQgYXR0ZW1wdHMgdG8gZG9jdW1lbnQgY3VycmVudCBwcmFjdGljZXMsIHdoaWxlIGF0IHRo ZSBzYW1lIHRpbWU8YnI+DQombmJzcDsgJm5ic3A7ZGVmaW5pbmcgYSBjb21tb24gY29yZSB3aGlj aCBpcyBpbnRlbmRlZCB0byBpbnRlcm9wZXJhdGUgYWNyb3NzIHRoZTxicj4NCiZuYnNwOyAmbmJz cDticm9hZCBzcGVjdHJ1bSBvZiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMuPGJyPg0KPGJyPg0K Tm90ZSB0byBSZWFkZXJzIChUbyBiZSByZW1vdmVkIGJ5IHRoZSBSRkMgRWRpdG9yKTxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDtUaGlzIGRyYWZ0IHNob3VsZCBiZSBkaXNjdXNzZWQgb24gdGhlIElF VEYgQXBwbGljYXRpb25zIEFyZWEgV29ya2luZzxicj4NCiZuYnNwOyAmbmJzcDtHcm91cCBkaXNj dXNzaW9uIGxpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmciPmFw cHMtZGlzY3Vzc0BpZXRmLm9yZzwvYT4mZ3Q7Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NClRoZSBJRVRGIFNl Y3JldGFyaWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgTWF0dGhldyBLZXJ3aW48YnI+DQombmJzcDsgPGEgaHJlZj0iaHR0cDovL21hdHRoZXcua2Vy d2luLm5ldC5hdS8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbWF0dGhldy5rZXJ3aW4ubmV0LmF1 LzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_DM2PR0201MB09602B351692D424A49C6B0DC3650DM2PR0201MB0960_-- From nobody Tue Dec 9 13:13:28 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B631A8A3F for ; Tue, 9 Dec 2014 13:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 rT7CMIwKnqZP for ; Tue, 9 Dec 2014 13:13:24 -0800 (PST) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 547A61A8A39 for ; Tue, 9 Dec 2014 13:13:24 -0800 (PST) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 24E3320058D83; Tue, 9 Dec 2014 13:13:24 -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=6TeoJd54Zpx+QF bdbIlSj0tqXtk=; b=H27I0Kt02l63TQ7Fcnr83DjjGHpIZC7vQo/SU7Issy3GIi 7/5X/ij1N4+itQQZSlQGaCFiZtgAcfOFdKbfuYFbOFzseOBHhP18U9JDJ8fNg8jX V3H45Q+EPd08XVbmAQnMBBkWSdmi0K5bXqSGpe4Ez0IUlNopjHdPu2dXqR8c8= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPA id CE0342005D82E; Tue, 9 Dec 2014 13:13:23 -0800 (PST) Date: Tue, 9 Dec 2014 15:13:23 -0600 From: Nico Williams To: Sean Leonard Message-ID: <20141209211318.GH12979@localhost> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <5429A68D.6030606@seantek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5429A68D.6030606@seantek.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/rUGSzYSw6jsJ8R9rIgRGKEIPuVw Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] "local convention" in 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: Tue, 09 Dec 2014 21:13:25 -0000 On Mon, Sep 29, 2014 at 11:35:57AM -0700, Sean Leonard wrote: > Colleagues: > > We ought to step back for a moment and ask ourselves what exactly > the goals are of getting a common file URI scheme through the IETF > process. > > [...] For one thing, there are contexts where a URI is needed (e.g., browser location bar, the DOM location, ...). For another, file: is undeniably in use. For a third, this is not unlike PKCS#11 URIs: there are cases where local interoperability between applications would be helped by having this. IMO, Nico -- From nobody Tue Dec 9 14:11:07 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F55B1A0119 for ; Tue, 9 Dec 2014 14:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.666 X-Spam-Level: X-Spam-Status: No, score=-3.666 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, IP_NOT_FRIENDLY=0.334, 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 UcC3EAzU62QR for ; Tue, 9 Dec 2014 14:11:03 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4041A002B for ; Tue, 9 Dec 2014 14:11:03 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id EDEEF2C806B; Tue, 9 Dec 2014 14:11: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=qfr8eKRcyEHUF2 HdGtcjW566s4I=; b=IRdxE7mtU72NUhGS70O4lZNDxN05D74xWomMxEa3lUURnZ N2wdZu6jw4zCoxs2/6zVdV1lhQDydlesDVRUiBaWH0j6NrcKmB4S3wjm9hl3O3d5 c0j6SYPq9VMNTGGK1k4sPLTeqiFal3JWbEQorpNYsXGGlFK4CYCKAkNAxxkOM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPA id 956C12C8058; Tue, 9 Dec 2014 14:11:02 -0800 (PST) Date: Tue, 9 Dec 2014 16:10:47 -0600 From: Nico Williams To: Matthew Kerwin Message-ID: <20141209221042.GJ12979@localhost> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <5429941C.6040808@seantek.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: http://mailarchive.ietf.org/arch/msg/apps-discuss/sR9LpOAu__xyyTV4EPbQvD96J-Q 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, 09 Dec 2014 22:11:04 -0000 On Tue, Sep 30, 2014 at 09:37:05AM +1000, Matthew Kerwin wrote: > On 30 September 2014 03:17, Sean Leonard wrote: > > Specifying the Path to a File or Directory > > > > The biggest reason for that omission is that, quite simply, I'd not seen > it. (I figured, right from the start, that people would be ready and > willing to point out all my shortcomings and direct me to their favoured > implementations' documentation and justifications.) Hmmm, it might be worth discussing because a file: URI using st_dev + st_ino might be useful for matching purposes. (There really shouldn't be much in the way of an openi() outside very special cases where file: URIs probably aren't getting used.) But, "meh", besides, this convention kinda camps on the traditional three-slashes file: URIs. > Regarding the amount of text dedicated to Windows, all I said was: "they > have drive letters, which you map this way," and: "some people actually map > drive letters this way instead, but that's not good." [...] You missed /cygdrive//... (Cygwin), though Cygwin falls into the POSIX "mostly no need to mention it" informational category. > Is there somewhere else I've disproportionately represented legacy > DOS/Windows cases to the exclusion of other systems? I think it's fine. Nico -- From nobody Tue Dec 9 14:21:55 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C89D1A1A2D for ; Tue, 9 Dec 2014 14:21:53 -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 qMeLgxOSBA74 for ; Tue, 9 Dec 2014 14:21:52 -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 376881A1A1D for ; Tue, 9 Dec 2014 14:21:52 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 1AB7643807C; Tue, 9 Dec 2014 14:21:52 -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=nOvQplJUjouM2r EukCicUjk2Tsc=; b=QTaYbcUaUIMqs2dtl3YAhS/sRG+95pLCnCtR0VDJBd9yzL wG4vyYeJK2xB6CxxDPr7ut0KZBA49nzUtpypHXb65x95mas7BsGReJMNOx8RL0vv U0LPt4V3ZFIYUw/ZxegiRcGU+N9r09F3YjeIEC0pBt9F009yfRWM7BUKq5JMM= 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 B781943806C; Tue, 9 Dec 2014 14:21:51 -0800 (PST) Date: Tue, 9 Dec 2014 16:21:51 -0600 From: Nico Williams To: Daniel Stenberg Message-ID: <20141209222146.GK12979@localhost> References: <20140926010029.26660.82167.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: http://mailarchive.ietf.org/arch/msg/apps-discuss/4rR6DsgcNpoO6i1N4pZy4ZsfDC4 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, 09 Dec 2014 22:21:53 -0000 On Fri, Sep 26, 2014 at 09:19:14AM +0200, Daniel Stenberg wrote: > On Fri, 26 Sep 2014, Matthew Kerwin wrote: > >http://www.ietf.org/internet-drafts/draft-kerwin-file-scheme-13.txt > > [...] > I would rather have a new spec straigten up and tighten the language > somewhat so that we can get a stricter interpretation of how a > file:// is supposed to work. Sure, there will then possibly be a few > non-compliant parsers out there that accept a few non-standard > formats but it should be clear to those who generates or writes > file:// URIs which the correct way is. That way we could potentially > move into a future with less file:// URI variations rather than > more. The rest of my comments are based on this basic stand. My biggest concern is that ambiguities, if any, between various historical forms should be documented, and the normative "modern" form should be given. Switching from traditional to modern forms may not be easy. Text about how to get there from here is needed. > I also think that the 'host' part of the file: URI was a mistake to > begin with. It was always a mystery to readers of RFC1738 and I > think it should be better clarified here as well that it is useless > and not interoperable. At any rate, we need only one way to represent UNC-like paths. > The query part. It didn't exist in 1738, so introducing that now > will break a lot of old parsers (like mine) even if I recognize that > 3986 says that it should be supported globally. This, for just a > vague extension model without any clear purpose or use case. About the only things I could think of stuffing there would be st_dev and st_ino like things. Are there any uses of queries that we know of for file: URIs? Nico -- From nobody Tue Dec 9 14:27:22 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8011A1AB1 for ; Tue, 9 Dec 2014 14:27:21 -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 5co0eVw9VRaB for ; Tue, 9 Dec 2014 14:27:20 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C00CB1A1A7C for ; Tue, 9 Dec 2014 14:27:20 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 2C5A794059; Tue, 9 Dec 2014 14:27:20 -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=3Ilx0hPjIus2QC 8Tr5iItayLWZk=; b=nclI9oRlptEWaaHRf+X9QMnOQPBCCb6JWRxtiftBQLuCIT 0nF29xA6Z6M900WzBEFWUWEVwu2m+ktBCXPFe9CZVF9gJkG7sVorv4we2yim/N66 h/4Qv2EroflaBwgewEUujZy7WWmb+P8SIXHdj8xByKGNm6dNrSSrqWmlEy9KA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPA id C19F79405C; Tue, 9 Dec 2014 14:27:19 -0800 (PST) Date: Tue, 9 Dec 2014 16:27:19 -0600 From: Nico Williams To: Matthew Kerwin Message-ID: <20141209222714.GL12979@localhost> References: <20140926010029.26660.82167.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: http://mailarchive.ietf.org/arch/msg/apps-discuss/M5J_jATIllTz7G69j8iVVBgHhzU Cc: uri@w3.org, 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, 09 Dec 2014 22:27:21 -0000 FWIW, HFS+ normalizes to something close to NFD. Not adhering to the recommendation to normalize might cause problems here. Also, if file: is intended for local use only, then there may not be any point to normalizing. Hmmm, that will vary, no? It will generally depend on what the filesystem does. Most just-use-8, some do better. ZFS does normalization-insensitive matching; HFS+ normalizes to NFD. Anyways, normalizing to NFC is probably the best thing to do, but mentioning the above might give implementors the sense of urgency they might need to actually implement this recommendation (or a clue as to bug reports they run into). Nico -- From nobody Tue Dec 9 14:43:16 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E9C1A1B79 for ; Tue, 9 Dec 2014 14:43:15 -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 BFBuMzedsaIi for ; Tue, 9 Dec 2014 14:43:14 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 487C21A1A46 for ; Tue, 9 Dec 2014 14:43:14 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 3E9DC674056; Tue, 9 Dec 2014 14:42:54 -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=nafknvCLuP9h4K b+DKV5IYMwnAY=; b=CabUrUe5O9ACWZayVnoUA+I7Qm7otiFzHaSnFvV0FFM8as 1185fBQo2PjeA9rnHHS100k45PUHHDCKJyTHBJJAOJc1p23WcRC5QGRymBCnHMmS aUqjecqAMbL434u5AyTr/uUfx9xOzz7JONcqCAaNbz2o8My+Hpgb1Zi4kJI5E= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPA id 2619367406A; Tue, 9 Dec 2014 14:42:28 -0800 (PST) Date: Tue, 9 Dec 2014 16:42:12 -0600 From: Nico Williams To: "Phillips, Addison" Message-ID: <20141209224207.GM12979@localhost> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <20141209222714.GL12979@localhost> <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC1D0@ex10-mbx-9007.ant.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC1D0@ex10-mbx-9007.ant.amazon.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_oRRhDpghQirf0rlA9iLOPPQbSg Cc: "uri@w3.org" , 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, 09 Dec 2014 22:43:15 -0000 On Tue, Dec 09, 2014 at 10:37:19PM +0000, Phillips, Addison wrote: > Although normalization is often a good idea... normalization might be > a problem if the local filesystem allows normalized and non-normalized > representations both to appear. You wouldn't be able to specify a > non-normalized representation. At least for Latin scripts most input methods produce NFC-ish output. This is true even on OS X even though its own HFS+ decomposes file/ directory names (!). What can I say other than "add that to the pile of mistakes we need a time machine to correct"? Anyways, in general normalizing to NFC does less damage than any other normalization, and not normalizing can cause weird things, but then, so can normalizing. My preference (for those who don't already know) is for all [new] filesystems to do normalization-insensitive matching, as that's the least problematic option. But this isn't going to happen anytime soon, apps can't tell if the filesystem is going to do this, and so on and so forth. Nico -- From nobody Tue Dec 9 14:59:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280651A6FCC for ; Tue, 9 Dec 2014 14:59:39 -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 R5tQHLpm5azm for ; Tue, 9 Dec 2014 14:59:37 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010: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 6B1941A3BA1 for ; Tue, 9 Dec 2014 14:59:37 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id n15so1391714lbi.30 for ; Tue, 09 Dec 2014 14:59: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:cc:content-type; bh=TUP4v+n0iburf9YurKGI/pMfrq6iBqeg+S9P3Ekqx8c=; b=bg1V3eRIIGNBzmmQB6Vdg1RkrC+TvVf3ELeogvP7i+f58t9ZBA2mME1HonsdxWvq3y N8ZljYmpgJ5K24ODpbV2wFsaE77ytk7NssIOZ6leeJQpmmh3qABEsgi/KjdKod4ytyZt Eb4u5FAlmVZeqjKBEHYFdJaNJOlGWQ0N0W44VxT1J/v4n7DruS13alVHcF9jrNFVSzD+ s/fFqNNrv7gKABi89BL9OQLxtClCXfJuscey26h6sc0lGpu6k1ig5suWjEDTf5LtTk0Z gyUGA3kosSSkG6tATdFEI1pE9lAxpdaCirkLU9vu3mRf1aQs9WLzWdR5cybIz2NIRs96 ON1w== MIME-Version: 1.0 X-Received: by 10.152.2.41 with SMTP id 9mr790533lar.47.1418165975872; Tue, 09 Dec 2014 14:59:35 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.152.148.227 with HTTP; Tue, 9 Dec 2014 14:59:35 -0800 (PST) In-Reply-To: <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC1D0@ex10-mbx-9007.ant.amazon.com> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <20141209222714.GL12979@localhost> <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC1D0@ex10-mbx-9007.ant.amazon.com> Date: Wed, 10 Dec 2014 08:59:35 +1000 X-Google-Sender-Auth: J8Xak1je1J2T6epQJOZ8LHOfbRo Message-ID: From: Matthew Kerwin To: "Phillips, Addison" Content-Type: multipart/alternative; boundary=089e013c6258397a940509d07fe4 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/fYWxFq2M-fsbVEG2OxWLnSCTHM8 Cc: "uri@w3.org" , 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, 09 Dec 2014 22:59:39 -0000 --089e013c6258397a940509d07fe4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10 December 2014 at 08:37, Phillips, Addison wrote: > Although normalization is often a good idea... normalization might be a > problem if the local filesystem allows normalized and non-normalized > representations both to appear. You wouldn't be able to specify a > non-normalized representation. > > Do you have an example? I'm trying to think it through, but I keep going in circles. The one I think of is ext[2-4] where the filesystem stores octet sequences, and shell/applications/etc. use things like the user's locale environment when representing those octets as text strings. Are you saying that if we mandate NFC normalisation of URIs, you can't distinguish between a files whose filename octets are {0xE4} vs {0xC3, 0xA4} (i.e. U+00E4 "=C3= =A4" in WIndows-1252 / UTF-8)? Wouldn't "file://%E4" would cover that? --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --089e013c6258397a940509d07fe4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 10 December 2014 at 08:37, Phillips, Addison &l= t;addison@lab126.co= m> wrote:
Although normalization is often a good idea... no= rmalization might be a problem if the local filesystem allows normalized an= d non-normalized representations both to appear. You wouldn't be able t= o specify a non-normalized representation.


Do you have an example? I= 'm trying to think it through, but I keep going in circles. The one I t= hink of is ext[2-4] where the filesystem stores octet sequences, and shell/= applications/etc. use things like the user's locale environment when re= presenting those octets as text strings. Are you saying that if we mandate = NFC normalisation of URIs, you can't distinguish between a files whose = filename octets are {0xE4} vs {0xC3, 0xA4} (i.e. U+00E4 "=C3=A4" = in WIndows-1252 / UTF-8)?

Wouldn't &qu= ot;file://%E4" would cover that?


--
=C2=A0 Matthew Kerw= in
=C2=A0 ht= tp://matthew.kerwin.net.au/
--089e013c6258397a940509d07fe4-- From nobody Tue Dec 9 15:26:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900D81A038A for ; Tue, 9 Dec 2014 15:26:25 -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 djKxWoXE6jd7 for ; Tue, 9 Dec 2014 15:26:23 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EBF91A6EEC for ; Tue, 9 Dec 2014 15:26:23 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l15so9568052wiw.8 for ; Tue, 09 Dec 2014 15:26:22 -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=DG2VA85ZxSBjubpuh+kCfkbTPHkjgb/RoV5xvrveIcU=; b=kl58g405uXOKp8c3kGiJX10akXJBvp/8kXQYDKn1CIM2SmZd3293Dm0yilOD5lzOYo V4wQG1X/9qtiwqdFF9LTrXXkRBOMq5ussSbwsEUFt13eVmcXR3/eKYsY6jiuSqfVYzrt D+IoVoUuHbM99Ae0D8x1KEGKtE3q0CZ8zkqxu+CNBG4pMvY8mVXnOnKzUPifoqhuwI52 91FeK5TmELt2sMKd8M1CBHR3jy+0av/H3PX1ToHOyeuHsMgKxgVNXULqCjfc42OqQ86W ohxpLiw3ESMIbGMf2qZ7nvTWEG5eTT36s6m9GVOn1g0y7Y3gTZYYTjXEslgeCjh/B1M4 WYCQ== MIME-Version: 1.0 X-Received: by 10.194.103.232 with SMTP id fz8mr1431524wjb.110.1418167581931; Tue, 09 Dec 2014 15:26:21 -0800 (PST) Received: by 10.27.76.134 with HTTP; Tue, 9 Dec 2014 15:26:21 -0800 (PST) In-Reply-To: References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> Date: Tue, 9 Dec 2014 15:26:21 -0800 Message-ID: From: "Murray S. Kucherawy" To: Matthew Kerwin Content-Type: multipart/alternative; boundary=047d7bf109f0f3ff8f0509d0de12 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/XU69qkQj2oJiaWzSaY78w62DDfM Cc: uri@w3.org, 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, 09 Dec 2014 23:26:25 -0000 --047d7bf109f0f3ff8f0509d0de12 Content-Type: text/plain; charset=UTF-8 Hi Matthew, Are you looking to process this through APPSAWG or as an individual submission? -MSK On Thu, Sep 25, 2014 at 6:13 PM, Matthew Kerwin wrote: > FYI: this is my file URI draft, now listing apps-discuss as the official > place for discussion. > > >>> > > A new version of I-D, draft-kerwin-file-scheme-13.txt > has been successfully submitted by Matthew Kerwin and posted to the > IETF repository. > > Name: draft-kerwin-file-scheme > Revision: 13 > Title: The file URI Scheme > Document date: 2014-09-26 > Group: Individual Submission > Pages: 16 > URL: > http://www.ietf.org/internet-drafts/draft-kerwin-file-scheme-13.txt > Status: https://datatracker.ietf.org/doc/draft-kerwin-file-scheme/ > Htmlized: http://tools.ietf.org/html/draft-kerwin-file-scheme-13 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-kerwin-file-scheme-13 > > 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 . > > > > > 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. > > The IETF Secretariat > > > > > -- > Matthew Kerwin > http://matthew.kerwin.net.au/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --047d7bf109f0f3ff8f0509d0de12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Matthew,

Are you looking to process this th= rough APPSAWG or as an individual submission?

-MSK

On Thu, Sep 25, 201= 4 at 6:13 PM, Matthew Kerwin <matthew@kerwin.net.au> wro= te:
FYI: this is my = file URI draft, now listing apps-discuss as the official place for discussi= on.

>>>

A new version of I-D, draft-kerwin-file-scheme-13.txt
has been successfully submitted by Matthew Kerwin and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-kerwin-file-scheme
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A013
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The file URI Scheme
Document date:=C2=A0 2014-09-26
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 16
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http:/= /www.ietf.org/internet-drafts/draft-kerwin-file-scheme-13.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.= ietf.org/doc/draft-kerwin-file-scheme/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/dr= aft-kerwin-file-scheme-13
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.= ietf.org/rfcdiff?url2=3Ddraft-kerwin-file-scheme-13

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>.




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.

The IETF Secretariat




--
=C2=A0 Matthew Kerwin<= br>=C2=A0 http:= //matthew.kerwin.net.au/

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


--047d7bf109f0f3ff8f0509d0de12-- From nobody Tue Dec 9 15:30:39 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E73E1A8871 for ; Tue, 9 Dec 2014 15:30:38 -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 n7TBwiH1gySS for ; Tue, 9 Dec 2014 15:30:37 -0800 (PST) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d: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 BFCC31A6F22 for ; Tue, 9 Dec 2014 15:30:36 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id w8so1249823qac.9 for ; Tue, 09 Dec 2014 15:30:36 -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=RilcSPUSxmgjN2YZI5EvLwV9eT0Nk7+oMiEnQqiW658=; b=OpwaArUmgO1tNC+zVqv5Uym0RiDc4L8drEk+Hf5d0orJAR7prva8jjUQlB3QmRv5MS 2HQVDWPPjCQCOUx8rT8k7e9Ust9qKsXk4k38ZAim5xKSn7sbXTFlREx9UMLD/F7oqNj7 S35k9po6eQMoYdy4aqT/1ZE6CO+Pt4CnqCyEk3drAfDkJg/MxMf3f4B5Lp/l4xduxr4X QaIFXEQ/Jmndx5OV8DAktYPpw1UlI7WZD/jqCK1U98C6B8cdnmyGFPqo62xbICcrecjq ctCJTn/9H6w3u6N3KVnHBERBNqN9jTkm1c7JiXw2bUkwklHQgbwHgymjVJyUMSTCeZ80 WX8A== MIME-Version: 1.0 X-Received: by 10.224.148.18 with SMTP id n18mr2255943qav.100.1418167835966; Tue, 09 Dec 2014 15:30:35 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.86.163 with HTTP; Tue, 9 Dec 2014 15:30:35 -0800 (PST) In-Reply-To: References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 09:30:35 +1000 X-Google-Sender-Auth: w9lbi5IVKoCR5cL385wpWQlF7Ws Message-ID: From: Matthew Kerwin To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=089e0153838e1845090509d0ee6a Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/yk8YVgDYeWgRk2E5UJVQTbuhao4 Cc: "uri@w3.org" , 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, 09 Dec 2014 23:30:38 -0000 --089e0153838e1845090509d0ee6a Content-Type: text/plain; charset=UTF-8 On 10 December 2014 at 09:26, Murray S. Kucherawy wrote: > Hi Matthew, > > Are you looking to process this through APPSAWG or as an individual > submission? > > -MSK > > I'd prefer it to be through the WG. -- Matthew Kerwin http://matthew.kerwin.net.au/ --089e0153838e1845090509d0ee6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 10 December 2014 at 09:26, Murray S. Kucherawy <<= a href=3D"mailto:superuser@gmail.com" target=3D"_blank">superuser@gmail.com= > wrote:
Hi Matthew,
Are you looking to process this through APPSAWG or as an individual su= bmission?

-MSK


<= div>
I'd prefer it to be through the WG.


--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--089e0153838e1845090509d0ee6a-- From nobody Tue Dec 9 15:43:10 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3771A1A48 for ; Tue, 9 Dec 2014 15:43:09 -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 sCLHV6d8r2FL for ; Tue, 9 Dec 2014 15:43:08 -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 DE7FC1A00E8 for ; Tue, 9 Dec 2014 15:43:08 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id A1CC820047B88; Tue, 9 Dec 2014 15:43:08 -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=pooxSRJ8ioFMj4 nU7AE+74Ux/KE=; b=BKAUawGD8RYYMhlP6OTJ1t8Ax+eJPlU7yOEk6bfxcC4ff8 rEPS7vr+lffsQ3hg9R8rad8L/y39IsnnFshILWZUDL0smnMpkyiAjDhrFVkJq1QQ juPq5skQdlIbn1qi8Rh1YTDXq6Ad/j15dLc0EBy6GO9P22lv+j9JdQ33+n5m4= 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 3E2F120047B84; Tue, 9 Dec 2014 15:43:08 -0800 (PST) Date: Tue, 9 Dec 2014 17:43:07 -0600 From: Nico Williams To: "Phillips, Addison" Message-ID: <20141209234302.GN12979@localhost> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <20141209222714.GL12979@localhost> <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC1D0@ex10-mbx-9007.ant.amazon.com> <20141209224207.GM12979@localhost> <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC343@ex10-mbx-9007.ant.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC343@ex10-mbx-9007.ant.amazon.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ELojpqrN2SVvhklZvYMObx8vZAk Cc: "uri@w3.org" , 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, 09 Dec 2014 23:43:09 -0000 On Tue, Dec 09, 2014 at 10:57:17PM +0000, Phillips, Addison wrote: > Yes, I completely agree that NFC is the right choice and does the > least harm. For wire-format exchange the ideal would be for NFC to be > the rule. > > file:// is a little different, since it is mainly trying to represent It may not be for a wire-format, but it exists nonetheless to interoperate, even if locally-only, between different apps, possibly portable apps. Therefore the issue comes up. > the characters/byte codes the file system is using while still trying > to be recognizable to the user. Maybe it doesn't matter, though: most Even on a typical Unix system that doesn't help: the filesystem typically treats filenames as octet strings not including '/'. > user-agents provide a dialog box, auto-complete, or some other > mechanism. Perhaps the rule is "NFC for the URI, file system/user > agent provides re-normalization or normalization-independent selection > for file systems that use a different normalization form, > de-normalized files use escapes (== don't do that)"? This comes up in many places (NFSv4, WebDAV, ...). Nico -- From nobody Tue Dec 9 15:54:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A0D1A1B06 for ; Tue, 9 Dec 2014 15:54: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 tismT6LgE3nw for ; Tue, 9 Dec 2014 15:54:27 -0800 (PST) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B56C51A01C6 for ; Tue, 9 Dec 2014 15:54:27 -0800 (PST) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 3272620058D81; Tue, 9 Dec 2014 15:54:27 -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=xA0Y8pc4u71yrSmq+SWzzp1D9m8=; b=F1bpzYFs5AI jJROFZ/hwsfAyQv82lVSL1SpHMVJvyP5VmABKfTQQC6sfp9C/Xjhxts5Wqau1ABj EKum1f+r7agOljlRAQ0pslbSmd5qmBIC7OO4OOfwfdJCp2S969Sl0wiQpUPht+8Q 2YlXkq9Zv8zm+n1ULTuA1YFlQxrS1LK4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPA id B61FA2005D82E; Tue, 9 Dec 2014 15:54:26 -0800 (PST) Date: Tue, 9 Dec 2014 17:54:26 -0600 From: Nico Williams To: Matthew Kerwin Message-ID: <20141209235420.GO12979@localhost> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <20141209222714.GL12979@localhost> <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC1D0@ex10-mbx-9007.ant.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wUtWqdMEf_5oztjeNC4L7XBOgoA Cc: "uri@w3.org" , IETF Apps Discuss , "Phillips, Addison" 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, 09 Dec 2014 23:54:29 -0000 On Wed, Dec 10, 2014 at 08:59:35AM +1000, Matthew Kerwin wrote: > On 10 December 2014 at 08:37, Phillips, Addison wr= ote: > > Although normalization is often a good idea... normalization might be= a > > problem if the local filesystem allows normalized and non-normalized > > representations both to appear. You wouldn't be able to specify a > > non-normalized representation. >=20 > Do you have an example? I'm trying to think it through, but I keep goin= g in > circles. The one I think of is ext[2-4] where the filesystem stores oct= et > sequences, and shell/applications/etc. use things like the user's local= e > environment when representing those octets as text strings. Are you say= ing > that if we mandate NFC normalisation of URIs, you can't distinguish bet= ween > a files whose filename octets are {0xE4} vs {0xC3, 0xA4} (i.e. U+00E4 "= =E4" > in WIndows-1252 / UTF-8)? >=20 > Wouldn't "file://%E4" would cover that? Suppose one app doesn't normalize. And another does. The user might be unable to type in the name of a file they want to open that exists. This is a bit contrived because they'll be able to pick the file in a file selection combo box, but still. A classic example many years ago was a git repo that had such characters in some filenames and which then broke on OS X. I don't have a link handy. Nico --=20 From nobody Tue Dec 9 17:14:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5731A03C7 for ; Tue, 9 Dec 2014 17:14: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 djIiAktJDiuo for ; Tue, 9 Dec 2014 17:14: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 E66C61A038F for ; Tue, 9 Dec 2014 17:14:51 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:41553] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id E4/67-21961-B8E97845; Wed, 10 Dec 2014 01:14:51 +0000 Received: from [192.168.1.109] (unknown [192.168.1.109]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id AA6EF140EBA; Tue, 9 Dec 2014 20:14:50 -0500 (EST) Message-ID: <54879E89.6050103@intertwingly.net> Date: Tue, 09 Dec 2014 20:14: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: Matthew Kerwin 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/FNFrIePGC4j8ZstI-WWJE41dvaQ Cc: apps-discuss@ietf.org Subject: [apps-discuss] draft-kerwin-file-scheme-13.txt / WHATWG / W3C X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 01:14:53 -0000 Not sure how I missed this previously, but I'm one of the editors of the WHATWG and W3C specifications: https://url.spec.whatwg.org/ http://www.w3.org/TR/url/ I've also got a major update in progress, though it isn't complete: https://specs.webplatform.org/url/webspecs/develop/ I suspect that we have common interests. Ideally these specs will be consistent with extant implementations and with each other. I'm looking to make the following more usable, but meanwhile here are some interop test results, a number of which involve file schemes: https://url.spec.whatwg.org/interop/urltest-results/ A few bugs reports on this effort may also be of interest: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27518 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23550 https://www.w3.org/Bugs/Public/show_bug.cgi?id=27517 - Sam Ruby From nobody Tue Dec 9 18:23:23 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65BC1A8869 for ; Tue, 9 Dec 2014 18:23:17 -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 8xFuiYXTFiHV for ; Tue, 9 Dec 2014 18:23:16 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A34E51A1AE0 for ; Tue, 9 Dec 2014 18:23:14 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 75C3B778061; Tue, 9 Dec 2014 18:23:14 -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=SDxBJebMs9+DTQ ZmMJcPccyQ0eU=; b=iQ+xxnFvotj5JJ8CfmuSgsbMat7vBYhmVg6EiYLdkdEy5i bTo56Z2ULzI+B4pjD/dT+6DiAY9fJZYz+NSbzyqBGIQIr5QMccDfZKE95NL0j9oY cj7mpdEU61zUhujBRKAocKuh0ioHmfMTOOcsTZvBKXmkaE70/WUjk36Ed5c+U= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPA id EE98777805F; Tue, 9 Dec 2014 18:23:13 -0800 (PST) Date: Tue, 9 Dec 2014 20:23:13 -0600 From: Nico Williams To: John Cowan Message-ID: <20141210022309.GX12979@localhost> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <20141209222714.GL12979@localhost> <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC1D0@ex10-mbx-9007.ant.amazon.com> <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC3CC@ex10-mbx-9007.ant.amazon.com> <20141210020759.GE32263@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141210020759.GE32263@mercury.ccil.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/V2UZPeGyQSFYTTXoia4FrSn2voM Cc: "uri@w3.org" , IETF Apps Discuss , "Phillips, Addison" 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: Wed, 10 Dec 2014 02:23:18 -0000 On Tue, Dec 09, 2014 at 09:07:59PM -0500, John Cowan wrote: > Phillips, Addison scripsit: > > These are both in UTF-8, are visually indistinguishable, and are > > identical under NFC, but fopen() cares which bag of bytes you grab. > > The same is true on Windows, where filenames are 16-bit code units rather > than 8-bit code units. In general, we simply cannot normalize file names, > because both Windows and Unix filesystems distinguish between names that > are equivalent under canonical equivalence. The preferable thing to do is to have form-preserve-on-create and form- insensitive lookups in the filesystem, which creates some unlikely aliases, but mostly avoids real problems. In practice few filesystems do this, so applications layered above them have to do something. "Nothing" works most of the time. Sometimes it doesn't work, and when it doesn't, it hurts. The example that comes to mind is git on HFS+. git has a configuration option to normalize: core.precomposeunicode:: This option is only used by Mac OS implementation of Git. When core.precomposeunicode=true, Git reverts the unicode decomposition of filenames done by Mac OS. This is useful when sharing a repository between Mac OS and Linux or Windows. (Git for Windows 1.7.10 or higher is needed, or Git under cygwin 1.7). When false, file names are handled fully transparent by Git, which is backward compatible with older versions of Git. Also, the ideal is that the filesystem stores Unicode filenames, and consumers in any non-Unicode locales convert. I think I have an I-D lying about discussing this. This keeps coming up. Maybe we should publish it? Though the file: URI scheme makes a poor trigger for publishing it: it'll be easier to ignore normalization in the file: scheme. Nico -- From nobody Wed Dec 10 12:20:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2464D1A1B7C for ; Tue, 9 Dec 2014 14:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, TVD_FROM_1=0.999] 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 P5XDmDdtaULc for ; Tue, 9 Dec 2014 14:37:24 -0800 (PST) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.189.228]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C9B41A1B29 for ; Tue, 9 Dec 2014 14:37:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,548,1413244800"; d="scan'208";a="151285789" Received: from email-inbound-relay-25003.iad12.amazon.com ([10.135.184.208]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Dec 2014 22:37:23 +0000 Received: from ex10-hub-9003.ant.amazon.com (iad1-ws-svc-lb91-vlan2.amazon.com [10.0.103.146]) by email-inbound-relay-25003.iad12.amazon.com (8.14.7/8.14.7) with ESMTP id sB9MbK1L013983 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 9 Dec 2014 22:37:21 GMT Received: from EX10-MBX-9007.ant.amazon.com ([fe80::c158:80fd:f614:552d]) by ex10-hub-9003.ant.amazon.com ([::1]) with mapi id 14.03.0181.006; Tue, 9 Dec 2014 14:37:20 -0800 From: "Phillips, Addison" To: Nico Williams , Matthew Kerwin Thread-Topic: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt Thread-Index: AQHQE/+ZrEoRIKz8pkyZnLCvUWZ3u5yH2AaA Date: Tue, 9 Dec 2014 22:37:19 +0000 Message-ID: <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC1D0@ex10-mbx-9007.ant.amazon.com> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <20141209222714.GL12979@localhost> In-Reply-To: <20141209222714.GL12979@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.49.70] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Y6fsObmTIPDg_6070P1hQ7PaqI0 X-Mailman-Approved-At: Wed, 10 Dec 2014 12:20:09 -0800 Cc: "uri@w3.org" , 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, 09 Dec 2014 22:37:27 -0000 QWx0aG91Z2ggbm9ybWFsaXphdGlvbiBpcyBvZnRlbiBhIGdvb2QgaWRlYS4uLiBub3JtYWxpemF0 aW9uIG1pZ2h0IGJlIGEgcHJvYmxlbSBpZiB0aGUgbG9jYWwgZmlsZXN5c3RlbSBhbGxvd3Mgbm9y bWFsaXplZCBhbmQgbm9uLW5vcm1hbGl6ZWQgcmVwcmVzZW50YXRpb25zIGJvdGggdG8gYXBwZWFy LiBZb3Ugd291bGRuJ3QgYmUgYWJsZSB0byBzcGVjaWZ5IGEgbm9uLW5vcm1hbGl6ZWQgcmVwcmVz ZW50YXRpb24uDQoNCkFkZGlzb24NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBOaWNvIFdpbGxpYW1zIFttYWlsdG86bmljb0BjcnlwdG9uZWN0b3IuY29tXQ0KPiBTZW50 OiBUdWVzZGF5LCBEZWNlbWJlciAwOSwgMjAxNCAyOjI3IFBNDQo+IFRvOiBNYXR0aGV3IEtlcndp bg0KPiBDYzogSUVURiBBcHBzIERpc2N1c3M7IHVyaUB3My5vcmcNCj4gU3ViamVjdDogUmU6IFth cHBzLWRpc2N1c3NdIEZ3ZDogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt DQo+IGtlcndpbi1maWxlLXNjaGVtZS0xMy50eHQNCj4gDQo+IA0KPiBGV0lXLCBIRlMrIG5vcm1h bGl6ZXMgdG8gc29tZXRoaW5nIGNsb3NlIHRvIE5GRC4gIE5vdCBhZGhlcmluZyB0byB0aGUNCj4g cmVjb21tZW5kYXRpb24gdG8gbm9ybWFsaXplIG1pZ2h0IGNhdXNlIHByb2JsZW1zIGhlcmUuDQo+ IA0KPiBBbHNvLCBpZiBmaWxlOiBpcyBpbnRlbmRlZCBmb3IgbG9jYWwgdXNlIG9ubHksIHRoZW4g dGhlcmUgbWF5IG5vdCBiZSBhbnkgcG9pbnQgdG8NCj4gbm9ybWFsaXppbmcuICBIbW1tLCB0aGF0 IHdpbGwgdmFyeSwgbm8/ICBJdCB3aWxsIGdlbmVyYWxseSBkZXBlbmQgb24gd2hhdCB0aGUNCj4g ZmlsZXN5c3RlbSBkb2VzLiAgTW9zdCBqdXN0LXVzZS04LCBzb21lIGRvIGJldHRlci4NCj4gWkZT IGRvZXMgbm9ybWFsaXphdGlvbi1pbnNlbnNpdGl2ZSBtYXRjaGluZzsgSEZTKyBub3JtYWxpemVz IHRvIE5GRC4NCj4gDQo+IEFueXdheXMsIG5vcm1hbGl6aW5nIHRvIE5GQyBpcyBwcm9iYWJseSB0 aGUgYmVzdCB0aGluZyB0byBkbywgYnV0IG1lbnRpb25pbmcNCj4gdGhlIGFib3ZlIG1pZ2h0IGdp dmUgaW1wbGVtZW50b3JzIHRoZSBzZW5zZSBvZiB1cmdlbmN5IHRoZXkgbWlnaHQgbmVlZCB0bw0K PiBhY3R1YWxseSBpbXBsZW1lbnQgdGhpcyByZWNvbW1lbmRhdGlvbiAob3IgYSBjbHVlIGFzIHRv IGJ1ZyByZXBvcnRzIHRoZXkgcnVuDQo+IGludG8pLg0KPiANCj4gTmljbw0KPiAtLQ0KDQo= From nobody Wed Dec 10 12:20:17 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9D11A6EE7 for ; Tue, 9 Dec 2014 14:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, TVD_FROM_1=0.999] 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 NiHFRUGsr-_l for ; Tue, 9 Dec 2014 14:57:23 -0800 (PST) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2603B1A3BA1 for ; Tue, 9 Dec 2014 14:57:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,548,1413244800"; d="scan'208";a="149762756" Received: from email-inbound-relay-6003.iad6.amazon.com ([10.103.7.120]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Dec 2014 22:57:21 +0000 Received: from ex10-hub-9004.ant.amazon.com (iad1-ws-svc-lb91-vlan3.amazon.com [10.0.103.150]) by email-inbound-relay-6003.iad6.amazon.com (8.14.7/8.14.7) with ESMTP id sB9MvG6G008659 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 9 Dec 2014 22:57:19 GMT Received: from EX10-MBX-9007.ant.amazon.com ([fe80::c158:80fd:f614:552d]) by ex10-hub-9004.ant.amazon.com ([::1]) with mapi id 14.03.0181.006; Tue, 9 Dec 2014 14:57:18 -0800 From: "Phillips, Addison" To: Nico Williams Thread-Topic: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt Thread-Index: AQHQFAGFuAHuY6AmmEa7hE9lsEtCyZyH2y1g Date: Tue, 9 Dec 2014 22:57:17 +0000 Message-ID: <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC343@ex10-mbx-9007.ant.amazon.com> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <20141209222714.GL12979@localhost> <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC1D0@ex10-mbx-9007.ant.amazon.com> <20141209224207.GM12979@localhost> In-Reply-To: <20141209224207.GM12979@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.49.70] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Precedence: Bulk Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/-jmKBm9v-g4qKZNqMPPVl_HjVgk X-Mailman-Approved-At: Wed, 10 Dec 2014 12:20:09 -0800 Cc: "uri@w3.org" , 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 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 22:57:24 -0000 PiBBbnl3YXlzLCBpbiBnZW5lcmFsIG5vcm1hbGl6aW5nIHRvIE5GQyBkb2VzIGxlc3MgZGFtYWdl IHRoYW4gYW55IG90aGVyDQo+IG5vcm1hbGl6YXRpb24sIGFuZCBub3Qgbm9ybWFsaXppbmcgY2Fu IGNhdXNlIHdlaXJkIHRoaW5ncywgYnV0IHRoZW4sIHNvIGNhbg0KPiBub3JtYWxpemluZy4NCg0K WWVzLCBJIGNvbXBsZXRlbHkgYWdyZWUgdGhhdCBORkMgaXMgdGhlIHJpZ2h0IGNob2ljZSBhbmQg ZG9lcyB0aGUgbGVhc3QgaGFybS4gRm9yIHdpcmUtZm9ybWF0IGV4Y2hhbmdlIHRoZSBpZGVhbCB3 b3VsZCBiZSBmb3IgTkZDIHRvIGJlIHRoZSBydWxlLg0KDQpmaWxlOi8vIGlzIGEgbGl0dGxlIGRp ZmZlcmVudCwgc2luY2UgaXQgaXMgbWFpbmx5IHRyeWluZyB0byByZXByZXNlbnQgdGhlIGNoYXJh Y3RlcnMvYnl0ZSBjb2RlcyB0aGUgZmlsZSBzeXN0ZW0gaXMgdXNpbmcgd2hpbGUgc3RpbGwgdHJ5 aW5nIHRvIGJlIHJlY29nbml6YWJsZSB0byB0aGUgdXNlci4gIE1heWJlIGl0IGRvZXNuJ3QgbWF0 dGVyLCB0aG91Z2g6IG1vc3QgdXNlci1hZ2VudHMgcHJvdmlkZSBhIGRpYWxvZyBib3gsIGF1dG8t Y29tcGxldGUsIG9yIHNvbWUgb3RoZXIgbWVjaGFuaXNtLiBQZXJoYXBzIHRoZSBydWxlIGlzICJO RkMgZm9yIHRoZSBVUkksIGZpbGUgc3lzdGVtL3VzZXIgYWdlbnQgcHJvdmlkZXMgcmUtbm9ybWFs aXphdGlvbiBvciBub3JtYWxpemF0aW9uLWluZGVwZW5kZW50IHNlbGVjdGlvbiBmb3IgZmlsZSBz eXN0ZW1zIHRoYXQgdXNlIGEgZGlmZmVyZW50IG5vcm1hbGl6YXRpb24gZm9ybSwgZGUtbm9ybWFs aXplZCBmaWxlcyB1c2UgZXNjYXBlcyAoPT0gZG9uJ3QgZG8gdGhhdCkiPw0KDQpBZGRpc29uDQo= From nobody Wed Dec 10 12:20:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C0A1A8899 for ; Tue, 9 Dec 2014 15:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, TVD_FROM_1=0.999] 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 8eV-S2AV6u9t for ; Tue, 9 Dec 2014 15:06:04 -0800 (PST) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437E71A8898 for ; Tue, 9 Dec 2014 15:06:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,548,1413244800"; d="scan'208,217";a="178524786" Received: from email-inbound-relay-25001.iad12.amazon.com ([10.205.29.168]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Dec 2014 23:06:02 +0000 Received: from ex10-hub-36002.ant.amazon.com (iad1-ws-svc-lb91-vlan3.amazon.com [10.0.103.150]) by email-inbound-relay-25001.iad12.amazon.com (8.14.7/8.14.7) with ESMTP id sB9N5ihf026895 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 9 Dec 2014 23:06:01 GMT Received: from EX10-MBX-9007.ant.amazon.com ([fe80::c158:80fd:f614:552d]) by ex10-hub-36002.ant.amazon.com ([::1]) with mapi id 14.03.0181.006; Tue, 9 Dec 2014 15:05:29 -0800 From: "Phillips, Addison" To: Matthew Kerwin Thread-Topic: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt Thread-Index: AQHQFAPS7zFT8V+HwEy1Kmn79VlrlZyH3+Kw Date: Tue, 9 Dec 2014 23:05:28 +0000 Message-ID: <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC3CC@ex10-mbx-9007.ant.amazon.com> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <20141209222714.GL12979@localhost> <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC1D0@ex10-mbx-9007.ant.amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.49.70] Content-Type: multipart/alternative; boundary="_000_7C0AF84C6D560544A17DDDEB68A9DFB52EAAC3CCex10mbx9007anta_" MIME-Version: 1.0 Precedence: Bulk Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Z2XehMDSandKzNPc7RqE519yPZ8 X-Mailman-Approved-At: Wed, 10 Dec 2014 12:20:09 -0800 Cc: "uri@w3.org" , 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 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 23:06:06 -0000 --_000_7C0AF84C6D560544A17DDDEB68A9DFB52EAAC3CCex10mbx9007anta_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVhaCwgdGhhdOKAmXMgZXhhY3RseSB0aGUgZXhhbXBsZSBmaWxlc3lzdGVtIEkgaGFkIGluIG1p bmQuDQoNCkFjdHVhbGx5LCBteSB0aG91Z2h0IHdhcyB0aGF0IFUrMDBFNCBhbmQgVSswMDYxLjAz MDggd291bGQgYmU6DQoNCnsgMHhDMy5BNCB9IHZzLiB7IDB4NjEuQ0MuODggfQ0KDQpUaGVzZSBh cmUgYm90aCBpbiBVVEYtOCwgYXJlIHZpc3VhbGx5IGluZGlzdGluZ3Vpc2hhYmxlLCBhbmQgYXJl IGlkZW50aWNhbCB1bmRlciBORkMsIGJ1dCBmb3BlbigpIGNhcmVzIHdoaWNoIGJhZyBvZiBieXRl cyB5b3UgZ3JhYi4NCg0KQWRkaXNvbg0KDQpGcm9tOiBwaGx1aWQ2MUBnbWFpbC5jb20gW21haWx0 bzpwaGx1aWQ2MUBnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBNYXR0aGV3IEtlcndpbg0KU2VudDog VHVlc2RheSwgRGVjZW1iZXIgMDksIDIwMTQgMzowMCBQTQ0KVG86IFBoaWxsaXBzLCBBZGRpc29u DQpDYzogTmljbyBXaWxsaWFtczsgSUVURiBBcHBzIERpc2N1c3M7IHVyaUB3My5vcmcNClN1Ympl Y3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBGd2Q6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWtlcndpbi1maWxlLXNjaGVtZS0xMy50eHQNCg0KT24gMTAgRGVjZW1iZXIgMjAx NCBhdCAwODozNywgUGhpbGxpcHMsIEFkZGlzb24gPGFkZGlzb25AbGFiMTI2LmNvbTxtYWlsdG86 YWRkaXNvbkBsYWIxMjYuY29tPj4gd3JvdGU6DQpBbHRob3VnaCBub3JtYWxpemF0aW9uIGlzIG9m dGVuIGEgZ29vZCBpZGVhLi4uIG5vcm1hbGl6YXRpb24gbWlnaHQgYmUgYSBwcm9ibGVtIGlmIHRo ZSBsb2NhbCBmaWxlc3lzdGVtIGFsbG93cyBub3JtYWxpemVkIGFuZCBub24tbm9ybWFsaXplZCBy ZXByZXNlbnRhdGlvbnMgYm90aCB0byBhcHBlYXIuIFlvdSB3b3VsZG4ndCBiZSBhYmxlIHRvIHNw ZWNpZnkgYSBub24tbm9ybWFsaXplZCByZXByZXNlbnRhdGlvbi4NCg0KRG8geW91IGhhdmUgYW4g ZXhhbXBsZT8gSSdtIHRyeWluZyB0byB0aGluayBpdCB0aHJvdWdoLCBidXQgSSBrZWVwIGdvaW5n IGluIGNpcmNsZXMuIFRoZSBvbmUgSSB0aGluayBvZiBpcyBleHRbMi00XSB3aGVyZSB0aGUgZmls ZXN5c3RlbSBzdG9yZXMgb2N0ZXQgc2VxdWVuY2VzLCBhbmQgc2hlbGwvYXBwbGljYXRpb25zL2V0 Yy4gdXNlIHRoaW5ncyBsaWtlIHRoZSB1c2VyJ3MgbG9jYWxlIGVudmlyb25tZW50IHdoZW4gcmVw cmVzZW50aW5nIHRob3NlIG9jdGV0cyBhcyB0ZXh0IHN0cmluZ3MuIEFyZSB5b3Ugc2F5aW5nIHRo YXQgaWYgd2UgbWFuZGF0ZSBORkMgbm9ybWFsaXNhdGlvbiBvZiBVUklzLCB5b3UgY2FuJ3QgZGlz dGluZ3Vpc2ggYmV0d2VlbiBhIGZpbGVzIHdob3NlIGZpbGVuYW1lIG9jdGV0cyBhcmUgezB4RTR9 IHZzIHsweEMzLCAweEE0fSAoaS5lLiBVKzAwRTQgIsOkIiBpbiBXSW5kb3dzLTEyNTIgLyBVVEYt OCk/DQoNCldvdWxkbid0ICJmaWxlOi8vJUU0PGZpbGU6Ly8vXFwlRTQ+IiB3b3VsZCBjb3ZlciB0 aGF0Pw0KDQoNCi0tDQogIE1hdHRoZXcgS2Vyd2luDQogIGh0dHA6Ly9tYXR0aGV3Lmtlcndpbi5u ZXQuYXUvDQo= --_000_7C0AF84C6D560544A17DDDEB68A9DFB52EAAC3CCex10mbx9007anta_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Okdlb3JnaWE7DQoJcGFu b3NlLTE6MiA0IDUgMiA1IDQgNSAyIDMgMzt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVhaCwgdGhhdOKAmXMgZXhhY3RseSB0aGUg ZXhhbXBsZSBmaWxlc3lzdGVtIEkgaGFkIGluIG1pbmQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BY3R1YWxseSwgbXkg dGhvdWdodCB3YXMgdGhhdCBVJiM0MzswMEU0IGFuZCBVJiM0MzswMDYxLjAzMDggd291bGQgYmU6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj57IDB4QzMuQTQgfSB2cy4geyAweDYxLkNDLjg4IH08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXNl IGFyZSBib3RoIGluIFVURi04LCBhcmUgdmlzdWFsbHkgaW5kaXN0aW5ndWlzaGFibGUsIGFuZCBh cmUgaWRlbnRpY2FsIHVuZGVyIE5GQywgYnV0IGZvcGVuKCkgY2FyZXMgd2hpY2ggYmFnIG9mIGJ5 dGVzIHlvdSBncmFiLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWRkaXNvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHBobHVpZDYxQGdtYWlsLmNvbSBbbWFpbHRvOnBobHVpZDYx QGdtYWlsLmNvbV0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWF0dGhldyBLZXJ3aW48YnI+DQo8Yj5T ZW50OjwvYj4gVHVlc2RheSwgRGVjZW1iZXIgMDksIDIwMTQgMzowMCBQTTxicj4NCjxiPlRvOjwv Yj4gUGhpbGxpcHMsIEFkZGlzb248YnI+DQo8Yj5DYzo8L2I+IE5pY28gV2lsbGlhbXM7IElFVEYg QXBwcyBEaXNjdXNzOyB1cmlAdzMub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbYXBwcy1k aXNjdXNzXSBGd2Q6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWtlcndp bi1maWxlLXNjaGVtZS0xMy50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPk9uIDEwIERl Y2VtYmVyIDIwMTQgYXQgMDg6MzcsIFBoaWxsaXBzLCBBZGRpc29uICZsdDs8YSBocmVmPSJtYWls dG86YWRkaXNvbkBsYWIxMjYuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWRkaXNvbkBsYWIxMjYuY29t PC9hPiZndDsgd3JvdGU6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtHZW9y Z2lhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMwNzM3NjMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5BbHRob3VnaCBub3JtYWxpemF0 aW9uIGlzIG9mdGVuIGEgZ29vZCBpZGVhLi4uIG5vcm1hbGl6YXRpb24gbWlnaHQgYmUgYSBwcm9i bGVtIGlmIHRoZSBsb2NhbCBmaWxlc3lzdGVtIGFsbG93cyBub3JtYWxpemVkIGFuZCBub24tbm9y bWFsaXplZCByZXByZXNlbnRhdGlvbnMgYm90aCB0byBhcHBlYXIuIFlvdSB3b3VsZG4ndCBiZSBh YmxlIHRvIHNwZWNpZnkgYQ0KIG5vbi1ub3JtYWxpemVkIHJlcHJlc2VudGF0aW9uLjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OywmcXVvdDtz ZXJpZiZxdW90Oztjb2xvcjojMDczNzYzIj5EbyB5b3UgaGF2ZSBhbiBleGFtcGxlPyBJJ20gdHJ5 aW5nIHRvIHRoaW5rIGl0IHRocm91Z2gsIGJ1dCBJIGtlZXAgZ29pbmcgaW4gY2lyY2xlcy4gVGhl IG9uZSBJIHRoaW5rIG9mIGlzIGV4dFsyLTRdIHdoZXJlIHRoZSBmaWxlc3lzdGVtIHN0b3JlcyBv Y3RldCBzZXF1ZW5jZXMsIGFuZCBzaGVsbC9hcHBsaWNhdGlvbnMvZXRjLg0KIHVzZSB0aGluZ3Mg bGlrZSB0aGUgdXNlcidzIGxvY2FsZSBlbnZpcm9ubWVudCB3aGVuIHJlcHJlc2VudGluZyB0aG9z ZSBvY3RldHMgYXMgdGV4dCBzdHJpbmdzLiBBcmUgeW91IHNheWluZyB0aGF0IGlmIHdlIG1hbmRh dGUgTkZDIG5vcm1hbGlzYXRpb24gb2YgVVJJcywgeW91IGNhbid0IGRpc3Rpbmd1aXNoIGJldHdl ZW4gYSBmaWxlcyB3aG9zZSBmaWxlbmFtZSBvY3RldHMgYXJlIHsweEU0fSB2cyB7MHhDMywgMHhB NH0gKGkuZS4gVSYjNDM7MDBFNCAmcXVvdDvDpCZxdW90Ow0KIGluIFdJbmRvd3MtMTI1MiAvIFVU Ri04KT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjojMDczNzYzIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMDczNzYz Ij5Xb3VsZG4ndCAmcXVvdDs8YSBocmVmPSJmaWxlOi8vL1xcJUU0Ij5maWxlOi8vJUU0PC9hPiZx dW90OyB3b3VsZCBjb3ZlciB0aGF0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgTWF0dGhldyBLZXJ3aW48YnI+DQombmJzcDsgPGEgaHJl Zj0iaHR0cDovL21hdHRoZXcua2Vyd2luLm5ldC5hdS8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8v bWF0dGhldy5rZXJ3aW4ubmV0LmF1LzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7C0AF84C6D560544A17DDDEB68A9DFB52EAAC3CCex10mbx9007anta_-- From nobody Wed Dec 10 12:20:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8781A8821 for ; Tue, 9 Dec 2014 18:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 matb8Cpestvv for ; Tue, 9 Dec 2014 18:08:11 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60E21A87C3 for ; Tue, 9 Dec 2014 18:08:10 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1XyWh5-00036g-CA; Tue, 09 Dec 2014 21:07:59 -0500 Date: Tue, 9 Dec 2014 21:07:59 -0500 From: John Cowan To: "Phillips, Addison" Message-ID: <20141210020759.GE32263@mercury.ccil.org> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <20141209222714.GL12979@localhost> <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC1D0@ex10-mbx-9007.ant.amazon.com> <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC3CC@ex10-mbx-9007.ant.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC3CC@ex10-mbx-9007.ant.amazon.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/eXjtyjzIL5iyKtkodpa_g0mK_zA X-Mailman-Approved-At: Wed, 10 Dec 2014 12:20:20 -0800 Cc: "uri@w3.org" , 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: Wed, 10 Dec 2014 02:08:14 -0000 Phillips, Addison scripsit: > These are both in UTF-8, are visually indistinguishable, and are > identical under NFC, but fopen() cares which bag of bytes you grab. The same is true on Windows, where filenames are 16-bit code units rather than 8-bit code units. In general, we simply cannot normalize file names, because both Windows and Unix filesystems distinguish between names that are equivalent under canonical equivalence. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org The whole of Gaul is quartered into three halves. --Julius Caesar From nobody Wed Dec 10 12:32:39 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C811A8ADA for ; Wed, 10 Dec 2014 12:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.921 X-Spam-Level: * X-Spam-Status: No, score=1.921 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, MALFORMED_FREEMAIL=2.899, MISSING_HEADERS=1.021, 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 RefXWFGdiPqi for ; Wed, 10 Dec 2014 12:32:32 -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 460191A8AC5 for ; Wed, 10 Dec 2014 12:32:32 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id va2so2780541obc.36 for ; Wed, 10 Dec 2014 12:32:31 -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:cc :content-type; bh=7MNjqvrAqyKM7u4Sb1EA2mmlmIZGtGJEyxYCxoFX7+M=; b=VK/q/CDnJsMgEXYjEhLbw2lxurDYA2zSQkZvI4Du3xgsumYrUxO1LcwqatlU/9dK8t fxHDnilTs04s1jVWAjbLds0t5/o26SijXT54+T3LSo7znXJ49/rGS2GnkoNeauZH7jBo EWVHhRB9kvVu3iprtRKsW3FeQbxPaubZzJgnobwkQODXzjjoxdOG7X7CYWLuypKh3xdQ nZAB03Oxn7S0IaeF4ipb9xru9TwTp6o2vfr3KgdHZ9R7DpmIoosyGrj3Y/ef3yruA6Fl MU7EyF+ZtI7ReiYMHFcrwiFOrAt1HRIH835zW3Bu5hIbmpju+kVVEkHi4wpXS3SFF+PW gKJw== MIME-Version: 1.0 X-Received: by 10.60.115.227 with SMTP id jr3mr3944657oeb.33.1418243551606; Wed, 10 Dec 2014 12:32:31 -0800 (PST) Received: by 10.202.170.138 with HTTP; Wed, 10 Dec 2014 12:32:31 -0800 (PST) In-Reply-To: <20141210020759.GE32263@mercury.ccil.org> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <20141209222714.GL12979@localhost> <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC1D0@ex10-mbx-9007.ant.amazon.com> <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC3CC@ex10-mbx-9007.ant.amazon.com> <20141210020759.GE32263@mercury.ccil.org> Date: Wed, 10 Dec 2014 13:32:31 -0700 Message-ID: From: Doug Royer Cc: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e011842421940000509e28f26 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/DiKUJeXyKc2h6K5R6wr9sB5jp1c 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: Wed, 10 Dec 2014 20:32:33 -0000 --089e011842421940000509e28f26 Content-Type: text/plain; charset=UTF-8 The fopen() API on windows uses 8-bit or 16-bit depending on how you compile your code with non-.NET. However the disk storage is a sequence of 8-bit bytes that could care less what character set you want to view the characters in. The .NET framework defaults to 16-bit UTF-16-like, and that also has nothing to do with the actual file name on the disk that is stored as 8-bit sequences. fopen() does not care how the name looks to you. It only compares the byte sequences to the byte sequences you asked to open. If you show the sequence asUTF-8 it will display a name. If you use a non-UTF-8 compatible character set, you get gibberish on you screen, but you can still open the same file. - Doug Royer DouglasRoyer@gmail.com (714)989-6135 On Tue, Dec 9, 2014 at 7:07 PM, John Cowan wrote: > Phillips, Addison scripsit: > > > These are both in UTF-8, are visually indistinguishable, and are > > identical under NFC, but fopen() cares which bag of bytes you grab. > > The same is true on Windows, where filenames are 16-bit code units rather > than 8-bit code units. In general, we simply cannot normalize file names, > because both Windows and Unix filesystems distinguish between names that > are equivalent under canonical equivalence. > > -- > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > The whole of Gaul is quartered into three halves. > --Julius Caesar > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e011842421940000509e28f26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The fopen() API on windows uses 8-bit or 16-bit depen= ding on how=20 you compile your code with non-.NET. However the disk storage is a=20 sequence of 8-bit bytes that could care less what character set you want to view the characters in.

The .NET framework defaults to 16-bit UTF-16-like, and that also has nothing to do with the actual file name=20 on the disk that is stored as 8-bit sequences.

fopen() does not care how the name looks to you. It only compares the byte=20 sequences to the byte sequences you asked to open. If you show the=20 sequence asUTF-8 it will display a name. If you use a non-UTF-8 compatible = character set, you get gibberish on you screen, but you can still open=C2= =A0 the same file.

-
Doug Ro= yer
(714)989-6135

On Tue, Dec 9, 2014 at 7:07 PM, John Cowan <= span dir=3D"ltr"><cowan@mercury.ccil.org> wrote:
Phillips, Addison scripsit:

> These are both in UTF-8, are visually indistinguishable, and are
> identical under NFC, but fopen() cares which bag of bytes you grab.
The same is true on Windows, where filenames are 16-bit code units r= ather
than 8-bit code units.=C2=A0 In general, we simply cannot normalize file na= mes,
because both Windows and Unix filesystems distinguish between names that are equivalent under canonical equivalence.

--
John Cowan=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ccil.org/~cowan=C2=A0 =C2=A0 =C2= =A0 =C2=A0 cowan@ccil.org
The whole of Gaul is quartered into three halves.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 --Julius Caesar

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

--089e011842421940000509e28f26-- From nobody Wed Dec 10 19:59:50 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9E71A0A6A for ; Wed, 10 Dec 2014 19:59:49 -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 xhHRLyE7Y3Iu for ; Wed, 10 Dec 2014 19:59:46 -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 37B4E1A014A for ; Wed, 10 Dec 2014 19:59:46 -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 31C3732E57C; Thu, 11 Dec 2014 12:59: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 022e_498c_d104d130_1cb8_4591_916e_fb41fd8d7ee1; Thu, 11 Dec 2014 12:58:59 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 9C052BF53E; Thu, 11 Dec 2014 12:58:59 +0900 (JST) Message-ID: <54891681.5080306@it.aoyama.ac.jp> Date: Thu, 11 Dec 2014 12:58:57 +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: Doug Royer References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <20141209222714.GL12979@localhost> <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC1D0@ex10-mbx-9007.ant.amazon.com> <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC3CC@ex10-mbx-9007.ant.amazon.com> <20141210020759.GE32263@mercury.ccil.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/2Ie6xUb0mj9-7_ABUtkw2WicmPw 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, 11 Dec 2014 03:59:49 -0000 On 2014/12/11 05:32, Doug Royer wrote: > The fopen() API on windows uses 8-bit or 16-bit depending on how you > compile your code with non-.NET. Yes. However the disk storage is a sequence of > 8-bit bytes that could care less what character set you want to view the > characters in. Mostly wrong. Windows (since Windows NT as far as I remember) uses 16-bit UTF-16LE internally, and also on newer file systems (but not necessarily e.g. on floppy disks or CDs). Regards, Martin. > The .NET framework defaults to 16-bit UTF-16-like, and that also has > nothing to do with the actual file name on the disk that is stored as 8-bit > sequences. > > fopen() does not care how the name looks to you. It only compares the byte > sequences to the byte sequences you asked to open. If you show the sequence > asUTF-8 it will display a name. If you use a non-UTF-8 compatible character > set, you get gibberish on you screen, but you can still open the same file. > > - > Doug Royer > DouglasRoyer@gmail.com > (714)989-6135 > > On Tue, Dec 9, 2014 at 7:07 PM, John Cowan wrote: > >> Phillips, Addison scripsit: >> >>> These are both in UTF-8, are visually indistinguishable, and are >>> identical under NFC, but fopen() cares which bag of bytes you grab. >> >> The same is true on Windows, where filenames are 16-bit code units rather >> than 8-bit code units. In general, we simply cannot normalize file names, >> because both Windows and Unix filesystems distinguish between names that >> are equivalent under canonical equivalence. >> >> -- >> John Cowan http://www.ccil.org/~cowan cowan@ccil.org >> The whole of Gaul is quartered into three halves. >> --Julius Caesar >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Wed Dec 10 22:34:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6FA1A0AC8 for ; Wed, 10 Dec 2014 22:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.639 X-Spam-Level: X-Spam-Status: No, score=0.639 tagged_above=-999 required=5 tests=[HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 HKlAZg8XYWra for ; Wed, 10 Dec 2014 22:34:11 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A9B1A88BE for ; Wed, 10 Dec 2014 22:34:11 -0800 (PST) Received: from dyn-fg122.sth.netnod.se (dyn-fg122.sth.netnod.se [77.72.226.122]) by mail.frobbit.se (Postfix) with ESMTPSA id B346D22AAF; Thu, 11 Dec 2014 07:34:09 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_69668DD1-3D71-4FD6-9E54-8708DBBE9CF4"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: <54891681.5080306@it.aoyama.ac.jp> Date: Thu, 11 Dec 2014 07:34:10 +0100 Message-Id: <641C0C1E-1281-49F2-971E-B2006238B274@frobbit.se> References: <20140926010029.26660.82167.idtracker@ietfa.amsl.com> <20141209222714.GL12979@localhost> <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC1D0@ex10-mbx-9007.ant.amazon.com> <7C0AF84C6D560544A17DDDEB68A9DFB52EAAC3CC@ex10-mbx-9007.ant.amazon.com> <20141210020759.GE32263@mercury.ccil.org> <54891681.5080306@it.aoyama.ac.jp> To: Martin Duerst X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/jcrU7ZFfaEhlczfr8qFKL-A18Pk Cc: Doug Royer , IETF Apps Discuss Subject: Re: [apps-discuss] 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, 11 Dec 2014 06:34:13 -0000 --Apple-Mail=_69668DD1-3D71-4FD6-9E54-8708DBBE9CF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 There is also here and there normalization that is done in the file = system stack, which you discover when you want to move files/disks = between systems that uses NFD and NFC as normalization forms (Apple and = Linux for example). See switch --iconv for rsync. So, please decide one normalization form (pick NFC please) and say that = that is what is used. Or, if you are working on a higher layer in the = stack (sorry for not having had the time to know) do not touch the bits = because there is normalization done elsewhere and maybe user A want to = have her NFC normalized string go to the file system while someone else = want her NFD normalized string to be passed on. Patrik > On 11 dec 2014, at 04:58, Martin J. D=C3=BCrst = wrote: >=20 > On 2014/12/11 05:32, Doug Royer wrote: >> The fopen() API on windows uses 8-bit or 16-bit depending on how you >> compile your code with non-.NET. >=20 > Yes. >=20 > However the disk storage is a sequence of >> 8-bit bytes that could care less what character set you want to view = the >> characters in. >=20 > Mostly wrong. >=20 > Windows (since Windows NT as far as I remember) uses 16-bit UTF-16LE = internally, and also on newer file systems (but not necessarily e.g. on = floppy disks or CDs). > Regards, Martin. >=20 >=20 >> The .NET framework defaults to 16-bit UTF-16-like, and that also has >> nothing to do with the actual file name on the disk that is stored as = 8-bit >> sequences. >>=20 >> fopen() does not care how the name looks to you. It only compares the = byte >> sequences to the byte sequences you asked to open. If you show the = sequence >> asUTF-8 it will display a name. If you use a non-UTF-8 compatible = character >> set, you get gibberish on you screen, but you can still open the = same file. >>=20 >> - >> Doug Royer >> DouglasRoyer@gmail.com >> (714)989-6135 >>=20 >> On Tue, Dec 9, 2014 at 7:07 PM, John Cowan = wrote: >>=20 >>> Phillips, Addison scripsit: >>>=20 >>>> These are both in UTF-8, are visually indistinguishable, and are >>>> identical under NFC, but fopen() cares which bag of bytes you grab. >>>=20 >>> The same is true on Windows, where filenames are 16-bit code units = rather >>> than 8-bit code units. In general, we simply cannot normalize file = names, >>> because both Windows and Unix filesystems distinguish between names = that >>> are equivalent under canonical equivalence. >>>=20 >>> -- >>> John Cowan http://www.ccil.org/~cowan cowan@ccil.org >>> The whole of Gaul is quartered into three halves. >>> --Julius Caesar >>>=20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>=20 >>=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 --Apple-Mail=_69668DD1-3D71-4FD6-9E54-8708DBBE9CF4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUiTrirMabGguI180RAvOAAKCWXLQBcNqmuAB95lXYXya2Eskj5gCfVz99 MzRQl1FQsttW1o/ykeh6c08= =tmId -----END PGP SIGNATURE----- --Apple-Mail=_69668DD1-3D71-4FD6-9E54-8708DBBE9CF4-- From nobody Mon Dec 15 02:21:52 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528E71A033A for ; Mon, 15 Dec 2014 02:21: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] 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 UUwqKFW7iSxa for ; Mon, 15 Dec 2014 02:21:45 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7886B1A1A42 for ; Mon, 15 Dec 2014 02:21:45 -0800 (PST) Received: from mfilter9-d.gandi.net (mfilter9-d.gandi.net [217.70.178.138]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id E3035A80B0 for ; Mon, 15 Dec 2014 11:21:43 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter9-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter9-d.gandi.net (mfilter9-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id uhLlbBDpqZLi for ; Mon, 15 Dec 2014 11:21:42 +0100 (CET) X-Originating-IP: 91.64.210.128 Received: from [192.168.178.195] (ip5b40d280.dynamic.kabel-deutschland.de [91.64.210.128]) (Authenticated sender: anything@michielbdejong.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id B2557A80AD for ; Mon, 15 Dec 2014 11:21:41 +0100 (CET) Message-ID: <548EB634.8060607@michielbdejong.com> Date: Mon, 15 Dec 2014 11:21:40 +0100 From: Michiel de Jong 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: <20141215100207.28427.4418.idtracker@ietfa.amsl.com> In-Reply-To: <20141215100207.28427.4418.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141215100207.28427.4418.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/L5y2LVgXrOSMZzowi3YI5FI_8ng Subject: [apps-discuss] New Version for draft-dejong-remotestorage-04.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, 15 Dec 2014 10:21:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://www.ietf.org/internet-drafts/draft-dejong-remotestorage-04.txt Abstract: This draft describes a protocol by which client-side applications, running inside a web browser, can communicate with a data storage server that is hosted on a different domain name. This way, the provider of a web application need not also play the role of data storage provider. The protocol supports storing, retrieving, and removing individual documents, as well as listing the contents of an individual folder, and access control is based on bearer tokens. Cheers! Michiel. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUjrYzAAoJECmDVpL5muhKvXcP/RudhEe0GzmVUZ4U5TWg/nmP 9SDFcPWuZlqqWm0vX/Mxhv4J7YRq3ortnSW+5BnanqpShLGouqiVX6TsBVYGs+zQ E90JKh5cZVpFitxRKgOv8RRsKmjV3A3rFv+AXFeHBt6fOP+fdRSyzbOI1U3XrnTa Mue/kKb1VZJfXitF6G/XfbHEWBK5W27+mxdRpPX+poqa8vGexD8weRTz5sph8ZHu y51Jpv6M53k+s4gXF8tuj++VqtsKuGarBADYB1cJJD1dJlrLQKcuWHhxmcvSo0W9 HosLewfJg3UIItK+kuzggTTodSHmc/K57bp0+jxpWeenUnTuy25sjt2Cu1c4E9q5 IJwzIdh0QW8iqjZrmxETyBqlxKwbPE/BqyKAY2yk7p3Z8mqYnlozFkUEnrSxdHEF GOTjfiu9qrSkzoYJ1Hm96FYBxBTN2mCFDB1eMHJa9itIJ/pY8HEH5eLDZA0+r8jO uD/1vbrJVyTCFiqQmBKk9Dt+niO62dNu5+ob8voTp0Y3Afu+mli76EBconHPzfWT U7E7PP3cCWnKyZ43yQ+VLJmpUIAc/0Vk8YAej2EcjiyAuaUsSMBulh6VNXxsIXYU BblWTg0a73EMfT2KtS/xmccUOO9g6dF+Zth+UT0vfHwxiwMXuagWGY3m4upU86pV JgOmYaQYGEvIkMaQlMLZ =afM4 -----END PGP SIGNATURE----- From nobody Mon Dec 15 07:58:11 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45C21A7020; Mon, 15 Dec 2014 07:58:08 -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, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWI46V73PbPf; Mon, 15 Dec 2014 07:58:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 139531A7D83; Mon, 15 Dec 2014 07:58:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Murray Kucherawy" To: barryleiba@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141215155800.12830.89026.idtracker@ietfa.amsl.com> Date: Mon, 15 Dec 2014 07:58:00 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/EX0GixyWp2iBUyfXmKxD_YBbE6c Cc: appsawg-chairs@tools.ietf.org, iesg-secretary@ietf.org, draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] Publication has been requested for draft-ietf-appsawg-multipart-form-data-07 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, 15 Dec 2014 15:58:09 -0000 Murray Kucherawy has requested publication of draft-ietf-appsawg-multipart-form-data-07 as Proposed Standard on behalf of the APPSAWG working group. Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ From nobody Mon Dec 15 08:20:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2001A86E5 for ; Mon, 15 Dec 2014 08:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.012 X-Spam-Level: X-Spam-Status: No, score=-99.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, MANGLED_TOOL=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 OgYpkqXbNAnq for ; Mon, 15 Dec 2014 08:20:42 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7601A802F for ; Mon, 15 Dec 2014 08:20:42 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id AB1B318123F; Mon, 15 Dec 2014 08:20:28 -0800 (PST) To: superuser@gmail.com, barryleiba@computer.org, presnick@qti.qualcomm.com, superuser@gmail.com, alexey.melnikov@isode.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141215162028.AB1B318123F@rfc-editor.org> Date: Mon, 15 Dec 2014 08:20:28 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/uw8CWL2uSyvxvtVfpbd9_22TOIQ Cc: bortzmeyer+rfceditor@nic.fr, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Technical Errata Reported] RFC7001 (4201) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 16:20:44 -0000 The following errata report has been submitted for RFC7001, "Message Header Field for Indicating Message Authentication Status". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7001&eid=4201 -------------------------------------- Type: Technical Reported by: Stéphane Bortzmeyer Section: C.5 Original Text ------------- Authentication-Results: example.com; sender-id=fail header.from=example.com; dkim=pass (good signature) header.d=example.com Corrected Text -------------- No idea Notes ----- The Sender-ID test is OK (header From:) but the DKIM one names a field in the DKIM-Signature: header (d=). Isn't it a violation of section 2.2, which says 'if "ptype" is "header", this indicates from which header field the value being evaluated was extracted' Or is section 2.2 an insufficient description? Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7001 (draft-ietf-appsawg-rfc5451bis-10) -------------------------------------- Title : Message Header Field for Indicating Message Authentication Status Publication Date : September 2013 Author(s) : M. Kucherawy Category : PROPOSED STANDARD Source : Applications Area Working Group Area : Applications Stream : IETF Verifying Party : IESG From nobody Mon Dec 15 11:02:35 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA451A86E0 for ; Mon, 15 Dec 2014 11:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.623 X-Spam-Level: * X-Spam-Status: No, score=1.623 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, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, MANGLED_TOOL=2.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 3U2oZJJcjBcr for ; Mon, 15 Dec 2014 11:02:32 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D0B1A8770 for ; Mon, 15 Dec 2014 11:02:31 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id q1so9877101lam.5 for ; Mon, 15 Dec 2014 11:02:30 -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=o/m31s20hscMd1vz82sjiDDTvfnNrNGQpBQ4R3RfXLQ=; b=NTbyq7ICmhdglqsJRFtqbMIvBoG+xNpeRFPC/WMHyq2i6/yVH5vFHaio69LUOQBdgy rDCDshdaWgB9vozV3ynpBl5QqkgpiLT6fyr9CDq1cAcDRfkyvWrBtG4pT9J7o43Zht2q xcvvfDayhyBGwnTgkee/DoNqFTydhDds1EWJx3V3Rrg/TDQE/s4y3y9JB/PS9Br/c9xy eagD5EZoVcLkwdo/0vBlEm8JHvu94Vx2vV9nHQ0EXGTbFHoJ6I/8GMjkotHkpY+L/l7Q r58Q6pcMcERHg1uEqwllbdBW5u+JffIbgE+5kzhYBdlWiaggm+kh85c3x2jc3oLO/E8U OeIg== MIME-Version: 1.0 X-Received: by 10.152.27.130 with SMTP id t2mr24348825lag.28.1418670150139; Mon, 15 Dec 2014 11:02:30 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Mon, 15 Dec 2014 11:02:30 -0800 (PST) In-Reply-To: <20141215162028.AB1B318123F@rfc-editor.org> References: <20141215162028.AB1B318123F@rfc-editor.org> Date: Mon, 15 Dec 2014 13:02:30 -0600 X-Google-Sender-Auth: Q4yKC-8Jlmiag94V5MEN8OM9cWU Message-ID: From: Barry Leiba To: RFC Errata System Content-Type: multipart/alternative; boundary=089e0160b6d05a475e050a45e248 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Tqlsh25ZeoEqxvTUEo4F6tFUyoc Cc: "presnick@qti.qualcomm.com" , "apps-discuss@ietf.org" , "bortzmeyer+rfceditor@nic.fr" Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7001 (4201) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 19:02:34 -0000 --089e0160b6d05a475e050a45e248 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you're not sure what's wrong or what to do about it, discussion on apps-discuss would be best, before submitting an errata report. Anyway, Murray will respond to this, I'm sure. Barry On Monday, December 15, 2014, RFC Errata System wrote: > The following errata report has been submitted for RFC7001, > "Message Header Field for Indicating Message Authentication Status". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D7001&eid=3D4201 > > -------------------------------------- > Type: Technical > Reported by: St=E9phane Bortzmeyer > > > Section: C.5 > > Original Text > ------------- > Authentication-Results: example.com; > sender-id=3Dfail header.from=3Dexample.com; > dkim=3Dpass (good signature) header.d=3Dexample.com > > Corrected Text > -------------- > No idea > > Notes > ----- > The Sender-ID test is OK (header From:) but the DKIM one names a field > in the DKIM-Signature: header (d=3D). Isn't it a violation of section > 2.2, which says 'if "ptype" is "header", this indicates from which header > field the value being evaluated was extracted' Or is section 2.2 an > insufficient description? > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7001 (draft-ietf-appsawg-rfc5451bis-10) > -------------------------------------- > Title : Message Header Field for Indicating Message > Authentication Status > Publication Date : September 2013 > Author(s) : M. Kucherawy > Category : PROPOSED STANDARD > Source : Applications Area Working Group > Area : Applications > Stream : IETF > Verifying Party : IESG > > --089e0160b6d05a475e050a45e248 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you're not sure what's wrong or what to do about it, discussion = on apps-discuss would be best, before submitting an errata report.=A0 Anywa= y, Murray will respond to this, I'm sure.

Barry

On Monday, December 15, 2014, RFC Errata System <rfc-editor@rfc-editor.org> wro= te:
The following errata report has been = submitted for RFC7001,
"Message Header Field for Indicating Message Authentication Status&quo= t;.

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc= =3D7001&eid=3D4201

--------------------------------------
Type: Technical
Reported by: St=E9phane Bortzmeyer <bortzmeye= r+rfceditor@nic.fr>

Section: C.5

Original Text
-------------
=A0 =A0 =A0 =A0 Authentication-Results: example.com;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sender-id=3Dfail header.from=3Dexample.com;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dkim=3Dpass (good signature) header.d= =3Dexample.com

Corrected Text
--------------
No idea

Notes
-----
The Sender-ID test is OK (header From:) but the DKIM one names a field
in the DKIM-Signature: header (d=3D). Isn't it a violation of section 2.2, which says 'if "ptype" is "header", this indic= ates from which header field the value being evaluated was extracted' O= r is section 2.2 an insufficient description?

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7001 (draft-ietf-appsawg-rfc5451bis-10)
--------------------------------------
Title=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Message Header Field for Indicating M= essage Authentication Status
Publication Date=A0 =A0 : September 2013
Author(s)=A0 =A0 =A0 =A0 =A0 =A0: M. Kucherawy
Category=A0 =A0 =A0 =A0 =A0 =A0 : PROPOSED STANDARD
Source=A0 =A0 =A0 =A0 =A0 =A0 =A0 : Applications Area Working Group
Area=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Applications
Stream=A0 =A0 =A0 =A0 =A0 =A0 =A0 : IETF
Verifying Party=A0 =A0 =A0: IESG

--089e0160b6d05a475e050a45e248-- From nobody Mon Dec 15 11:38:20 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFBC1A8786 for ; Mon, 15 Dec 2014 11:38:15 -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 Yw7iSKol3Q30 for ; Mon, 15 Dec 2014 11:38:10 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DDD71A8759 for ; Mon, 15 Dec 2014 11:38:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 6A2AD62C049; Mon, 15 Dec 2014 14:38:09 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWttDWb8GuDv; Mon, 15 Dec 2014 14:38:09 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 27C1362C03E; Mon, 15 Dec 2014 14:38:07 -0500 (EST) Date: Mon, 15 Dec 2014 14:38:01 -0500 From: Cyrus Daboo To: Alexey Melnikov , apps-discuss@ietf.org Message-ID: In-Reply-To: <8D25F56B-EEEC-4858-9905-999DA0C6D52F@isode.com> References: <8D25F56B-EEEC-4858-9905-999DA0C6D52F@isode.com> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1000 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iDTP4Edsi4ZaT1oJJipCrpEsedQ Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-http-problem-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, 15 Dec 2014 19:38:17 -0000 Hi Alexey, --On December 7, 2014 at 10:44:10 PM +0000 Alexey Melnikov wrote: > This message starts 2 weeks WGLC on draft-ietf-appsawg-http-problem-00 > (Problem Details for HTTP APIs). Please review and send your comments to > the mailing list by December 21st, or state that the document is ready > for publication. I support publication of this draft. A draft I am working on already references it (). One comment: the definition of the "type" member in Section 3.1 and the text in Section 4 both recommend that the "type" resolve to HTML documentation. In tzdist we have a "urn:ietf:params:tzdist:error:" sub-namespace for error codes that the protocol itself defines and that we use for the "type" URI value. I think it may be fairly common for protocols creating new HTTP apis to do something similar, so I wonder if that should be called out as a "recommended" solution too? -- Cyrus Daboo From nobody Mon Dec 15 18:12:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3371AC3D1 for ; Mon, 15 Dec 2014 18:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.063 X-Spam-Level: *** X-Spam-Status: No, score=3.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, J_CHICKENPOX_64=0.6, MANGLED_TOOL=2.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 UF8595nst4Nj for ; Mon, 15 Dec 2014 18:12:20 -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 A7CCC1AC3D0 for ; Mon, 15 Dec 2014 18:12:19 -0800 (PST) Received: (qmail 48810 invoked from network); 16 Dec 2014 02:12:14 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 16 Dec 2014 02:12:14 -0000 Date: 16 Dec 2014 02:11:56 -0000 Message-ID: <20141216021156.3593.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <20141215162028.AB1B318123F@rfc-editor.org> 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/nL-sF8NCOjjRIGE36Br6MnXdud8 Cc: rfc-editor@rfc-editor.org Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7001 (4201) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 02:12:23 -0000 At the least, the wording in section 2.2 could use some work, and we seem to have completely forgotten to document the property subfields. >Notes >----- >The Sender-ID test is OK (header From:) but the DKIM one names a field >in the DKIM-Signature: header (d=). Isn't it a violation of section >2.2, which says 'if "ptype" is "header", this indicates from which header field the value being >evaluated was extracted' Or is section 2.2 an insufficient description? The relevant text in 2.2 says propspec = ptype [CFWS] "." [CFWS] property [CFWS] "=" pvalue ; an indication of which properties of the message ; were evaluated by the authentication scheme being ; applied to yield the reported result The scheme uses a something from the header, idenfified by the property. property = special-smtp-verb / Keyword ; if "ptype" is "smtp", this indicates which [SMTP] ; command provided the value that was evaluated by the ; authentication scheme being applied; if "ptype" is ; "header", this indicates from which header field the ; value being evaluated was extracted; if "ptype" is ; "body", this indicates where in the message body ; a value being evaluated can be found (e.g., a specific ; offset into the message or a reference to a MIME part); ; if "ptype" is "policy", then this indicates the name ; of the policy that caused this header field to be ; added (see below) Oops. "Header field" in RFC 5322-ese indeed means which header, but in this context it's intended to be scheme specific, as something found in a header. There's nothing in this document that actually explains what the property keywords for the various authentication schemes are, other that implicitly and incompletely in the examples. Unless it's lurking in some other document, I'm astonished that we missed that both in 5321 and in 7001. It's not always obvious; for DomainKeys, the header.from is the domain name in the From: header, while for DKIM, the header.xxx is the xxx subfield in the DKIM-Signature header. In SPF, smtp.mailfrom is the domain name in the MAIL FROM command, and the undocumented smtp.helo is the argument to the HELO or EHLO command. The definition in 2.2 of special-smtp-verb should include "helo" in addition to "mailfrom" and "rcptto" since SPF can validate that and the code I adapted from Murray's libraries adds smtp.helo items to its A-R headers. R's, John From nobody Tue Dec 16 06:36:35 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513341A1B6E for ; Tue, 16 Dec 2014 06:36:32 -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, TVD_SPACE_RATIO=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 8MDY4mDMy9Vd; Tue, 16 Dec 2014 06:36:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF7D1A1B53; Tue, 16 Dec 2014 06:36:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: Salvatore.Loreto@ericsson.com, appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141216143630.3408.27629.idtracker@ietfa.amsl.com> Date: Tue, 16 Dec 2014 06:36:30 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/--HbeKnsUw58dOEHC325i9ZWF6Q Subject: [apps-discuss] ID Tracker State Update Notice: 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: Tue, 16 Dec 2014 14:36:32 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ From nobody Tue Dec 16 23:57:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19181A039A; Tue, 16 Dec 2014 23: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] 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 9uWbfDJWM-9X; Tue, 16 Dec 2014 23:57:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC241A6F3B; Tue, 16 Dec 2014 23:57:35 -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.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141217075735.6060.32225.idtracker@ietfa.amsl.com> Date: Tue, 16 Dec 2014 23:57:35 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/jZYa7cuxikDiYdlOijrCK2bbEA8 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-04.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: Wed, 17 Dec 2014 07:57:38 -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 text/markdown Media Type Author : Sean Leonard Filename : draft-ietf-appsawg-text-markdown-04.txt Pages : 14 Date : 2014-12-16 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-text-markdown-04 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 Wed Dec 17 08:37:39 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3441A8BC1 for ; Wed, 17 Dec 2014 08:37: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 rl0GZtlvsVPo for ; Wed, 17 Dec 2014 08:37:36 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDA1D1A8BB7 for ; Wed, 17 Dec 2014 08:37:35 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id l15so16748325wiw.10 for ; Wed, 17 Dec 2014 08:37:34 -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=eWxbwtQDmYNyoBxrbrWQciDrqqdvXQ9Zw13k7K/RBB0=; b=0uUTzFjZaCZAd5CVNDkvoRO4DgIv9QrWI0mX3yEnBiU33kYJoQEcA2OX/QSU8pN9Ua q9OpziUNSMz2l7+HP2VoAHdthnZUrTKVijBJSTbeX8C5sfM6Ojgfbh7AfcenYh42g0Um zrpfE2sPisR0a7WiKax8RMSBvAl7xghLRvHRXOmsTepFuV8I5FJxxsZFRHUMmTxumfez 1gtOVvf+L8M/cUCMd9CfJm7WPq8uQWLYJ6i5RYTPJkes5Af5LiwlVly6A7J7yObq9E7P 0EMr/B1gZdmvxS+5m/Zo6LT4/jlfh4mzuJv2Nl1UOgWU7ZXpOxnDLWbqxfRp5aQfO9mA RhYg== MIME-Version: 1.0 X-Received: by 10.180.218.39 with SMTP id pd7mr16365915wic.21.1418834254617; Wed, 17 Dec 2014 08:37:34 -0800 (PST) Received: by 10.27.8.74 with HTTP; Wed, 17 Dec 2014 08:37:34 -0800 (PST) Date: Wed, 17 Dec 2014 08:37:34 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a1134cd58bde22a050a6c176d Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/pmSd0s15AX00PxQxdVVXJCn4bAE Subject: [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: Wed, 17 Dec 2014 16:37:37 -0000 --001a1134cd58bde22a050a6c176d Content-Type: text/plain; charset=UTF-8 This opens a call for adoption for draft-kerwin-file-scheme, to be processed by APPSAWG. There appears to be enough interest in the work given the feedback it's getting, and it appears to fit within our charter. Please indicate your support or objection by replying to this thread. The call will close on January 9, 2015. -MSK, APPSAWG co-chair --001a1134cd58bde22a050a6c176d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This opens a call for adoption for draft-kerwin-= file-scheme, to be processed by APPSAWG.=C2=A0 There appears to be enough i= nterest in the work given the feedback it's getting, and it appears to = fit within our charter.

Please indicate your support or object= ion by replying to this thread.=C2=A0 The call will close on January 9, 201= 5.

-MSK, APPSAWG co-chair

--001a1134cd58bde22a050a6c176d-- From bortzmeyer+rfceditor@nic.fr Wed Dec 17 00:26:52 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4831A6EFB for ; Wed, 17 Dec 2014 00:26:52 -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_00=-1.9, HELO_EQ_FR=0.35, 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 EeFxHXX4J-FE for ; Wed, 17 Dec 2014 00:26:52 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 051351A6F49 for ; Wed, 17 Dec 2014 00:26:52 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id C4FFB2802C7; Wed, 17 Dec 2014 09:26:50 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id BE9A0280285; Wed, 17 Dec 2014 09:26:50 +0100 (CET) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay1.nic.fr (Postfix) with ESMTP id B1A3B4C0087; Wed, 17 Dec 2014 09:26:20 +0100 (CET) Date: Wed, 17 Dec 2014 09:26:20 +0100 From: "bortzmeyer+rfceditor@nic.fr" To: Barry Leiba Message-ID: <20141217082620.GA32662@nic.fr> References: <20141215162028.AB1B318123F@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 8.0 X-Kernel: Linux 3.16.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ljcJHL0GiOKZ3_Dt0idDL5Z1M5Y X-Mailman-Approved-At: Wed, 17 Dec 2014 08:52:55 -0800 Cc: "apps-discuss@ietf.org" , "presnick@qti.qualcomm.com" , "bortzmeyer+rfceditor@nic.fr" , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7001 (4201) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 08:31:48 -0000 On Mon, Dec 15, 2014 at 01:02:30PM -0600, Barry Leiba wrote a message of 142 lines which said: > If you're not sure what's wrong or what to do about it, discussion > on apps-discuss would be best, before submitting an errata report. Two weeks before submitting the report, I emailed the RFC author. From nobody Wed Dec 17 08:54:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B271A8F4E for ; Wed, 17 Dec 2014 08:54:54 -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 9h6pI173Gnes for ; Wed, 17 Dec 2014 08:54:47 -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 AB6AC1A1BC0 for ; Wed, 17 Dec 2014 08:54:46 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id l18so20513253wgh.26 for ; Wed, 17 Dec 2014 08:54:45 -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=95wXcclt8Ni5JAPF0XKHpT24jppT+kzrOxxyhR5EqwU=; b=qYuYQ59JTjCfDunLqDZJISFR1doCpQ2Ld8edGrLmSijXGSmlIA67RQN/HqfF1GymmK KI3TD181RY/vfbM9FTKvsJgGQFkQR01nJl8eIBnA6P20XFJ1P4RLPPX4PrScdk/wyO4w cvHl7ECBYtmtDleEMFKnV9oAF0T+qEtbpAudCtCKkp2FlB+M0wTy0ehe81HJ0M99sXX4 I5x4Xf6IsdxbLUZrtt0lgC6PoE41uVH9EzncYPiQTC+Gexmhd6tzyYKeohLogOtf3SeT nH4a0di7DsT08mcbXFcZDW6pjpt+r56oAXPVqfR5fHQPqAm39j3lmJlO4rvuvXl5dNbi z1dg== MIME-Version: 1.0 X-Received: by 10.180.211.201 with SMTP id ne9mr16041076wic.30.1418835285402; Wed, 17 Dec 2014 08:54:45 -0800 (PST) Received: by 10.27.8.74 with HTTP; Wed, 17 Dec 2014 08:54:45 -0800 (PST) In-Reply-To: <20141217082620.GA32662@nic.fr> References: <20141215162028.AB1B318123F@rfc-editor.org> <20141217082620.GA32662@nic.fr> Date: Wed, 17 Dec 2014 08:54:45 -0800 Message-ID: From: "Murray S. Kucherawy" To: "bortzmeyer+rfceditor@nic.fr" Content-Type: multipart/alternative; boundary=001a11c266d62e6bd2050a6c55e0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/pecsGG3iEgMunDXeYrJk7KEJ2GM Cc: "presnick@qti.qualcomm.com" , Barry Leiba , "apps-discuss@ietf.org" , RFC Errata System Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7001 (4201) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 16:54:55 -0000 --001a11c266d62e6bd2050a6c55e0 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 17, 2014 at 12:26 AM, bortzmeyer+rfceditor@nic.fr < bortzmeyer+rfceditor@nic.fr> wrote: > On Mon, Dec 15, 2014 at 01:02:30PM -0600, > Barry Leiba wrote > a message of 142 lines which said: > > > If you're not sure what's wrong or what to do about it, discussion > > on apps-discuss would be best, before submitting an errata report. > > Two weeks before submitting the report, I emailed the RFC author. > I received it but given the November and December holidays I had not followed up on it since it didn't seem to be an urgent matter. I agree with John's synopsis upthread, and will reply in more detail ASAP. -MSK --001a11c266d62e6bd2050a6c55e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 17, 2014 at 12:26 AM, bortzmeyer+rfceditor@nic.fr = <bortzm= eyer+rfceditor@nic.fr> wrote:
On Mon, Dec 15, 2014 a= t 01:02:30PM -0600,
=C2=A0Barry Leiba <barryleiba= @computer.org> wrote
=C2=A0a message of 142 lines which said:

> If you're not sure what's wrong or what to do about it, discus= sion
> on apps-discuss would be best, before submitting an errata report.

Two weeks before submitting the report, I emailed the RFC author.

I received it but given the November and = December holidays I had not followed up on it since it didn't seem to b= e an urgent matter.

I agree with John's synopsis upth= read, and will reply in more detail ASAP.

-MSK
<= /div>
--001a11c266d62e6bd2050a6c55e0-- From nobody Wed Dec 17 08:55:10 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA601A8F4C for ; Wed, 17 Dec 2014 08:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 RPWmI8tdBAJE for ; Wed, 17 Dec 2014 08:55:02 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0799.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::799]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D24331A8F51 for ; Wed, 17 Dec 2014 08:55:01 -0800 (PST) Received: from pc6 (81.151.166.145) by DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) with Microsoft SMTP Server (TLS) id 15.1.31.17; Wed, 17 Dec 2014 16:52:56 +0000 Message-ID: <063001d01a19$dd4c15c0$4001a8c0@gateway.2wire.net> From: t.petch To: "Murray S. Kucherawy" , IETF Apps Discuss References: Date: Wed, 17 Dec 2014 16:52:32 +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.166.145] X-ClientProxiedBy: AM3PR01CA028.eurprd01.prod.exchangelabs.com (10.141.191.18) To DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;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: 042857DBB5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(51704005)(189002)(44716002)(47776003)(120916001)(20776003)(84392001)(19580405001)(99396003)(230783001)(64706001)(15975445007)(61296003)(81816999)(19580395003)(40100003)(21056001)(86362001)(101416001)(122386002)(92566001)(42186005)(14496001)(89996001)(1456003)(50226001)(62966003)(107046002)(4396001)(87976001)(76176999)(68736005)(62236002)(97736003)(66066001)(106356001)(50466002)(33646002)(81686999)(46102003)(77156002)(31966008)(77096005)(50986999)(105586002)(23676002)(107886001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB062; H:pc6; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB062; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/paIFWjssYBv7b9uZB6PId6gO3PU 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: Wed, 17 Dec 2014 16:55:08 -0000 I support adoption Tom Petch ----- Original Message ----- From: "Murray S. Kucherawy" To: "IETF Apps Discuss" Sent: Wednesday, December 17, 2014 4:37 PM > This opens a call for adoption for draft-kerwin-file-scheme, to be > processed by APPSAWG. There appears to be enough interest in the work > given the feedback it's getting, and it appears to fit within our charter. > > Please indicate your support or objection by replying to this thread. The > call will close on January 9, 2015. > > -MSK, APPSAWG co-chair > ------------------------------------------------------------------------ -------- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Wed Dec 17 08:57:03 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBF91A9004 for ; Wed, 17 Dec 2014 08:57:01 -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 Z0maYQBaZMJL for ; Wed, 17 Dec 2014 08:57:00 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0D61A8F4C for ; Wed, 17 Dec 2014 08:57:00 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 07D7E350072; Wed, 17 Dec 2014 08:57:00 -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=HkPsOrzQmXsAo8 tdIzgQS11pP6s=; b=JJmuWSfJfse35/MaZ9at9y5xHZNRRGOIzNWsLmYeOPA34X hnftehqB8GPp3p4z1nu+P4vi/YrOSXe4NAmdWSJpzo7Xzsri5cXVRGF5xlk5Qgih XBlEuAIu+L73j+bYezoP8QX8dBltlD94Z8Y9aYklrqvW6zDyz8uEYfd6zPoD8= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPA id B3B3F35005B; Wed, 17 Dec 2014 08:56:59 -0800 (PST) Date: Wed, 17 Dec 2014 10:56:59 -0600 From: Nico Williams To: "Murray S. Kucherawy" Message-ID: <20141217165654.GW3241@localhost> References: 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: http://mailarchive.ietf.org/arch/msg/apps-discuss/4BCnB7JwDuFMeh7ccZSTPGhJUC0 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: Wed, 17 Dec 2014 16:57:01 -0000 On Wed, Dec 17, 2014 at 08:37:34AM -0800, Murray S. Kucherawy wrote: > This opens a call for adoption for draft-kerwin-file-scheme, to be > processed by APPSAWG. There appears to be enough interest in the work > given the feedback it's getting, and it appears to fit within our charter. > > Please indicate your support or objection by replying to this thread. The > call will close on January 9, 2015. I'm in favor. From nobody Wed Dec 17 10:44:57 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9831A1BB1 for ; Wed, 17 Dec 2014 10:44:56 -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 crl1Rv2K-Rf4 for ; Wed, 17 Dec 2014 10:44:52 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EBEA1A1B8B for ; Wed, 17 Dec 2014 10:44:52 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1566A22E257 for ; Wed, 17 Dec 2014 13:44:50 -0500 (EST) Message-ID: <5491CF18.5010005@seantek.com> Date: Wed, 17 Dec 2014 10:44:40 -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: <20141217161408.6513.11896.idtracker@ietfa.amsl.com> In-Reply-To: <20141217161408.6513.11896.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141217161408.6513.11896.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kumXk14oSQhC6yON_u3feFt37c8 Subject: [apps-discuss] New Version Notification for draft-seantek-windows-image-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, 17 Dec 2014 18:44:56 -0000 Hello apps-discuss: See the combined draft that was recently posted. This draft combines draft-seantek-image-wmf-emf-00 and draft-seantek-image-bmp-01. Sean -------- Forwarded Message -------- Subject: New Version Notification for draft-seantek-windows-image-00.txt Date: Wed, 17 Dec 2014 08:14:08 -0800 From: internet-drafts@ietf.org A new version of I-D, draft-seantek-windows-image-00.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-seantek-windows-image Revision: 00 Title: Windows Image Media Types Document date: 2014-12-17 Group: Individual Submission Pages: 12 URL: http://www.ietf.org/internet-drafts/draft-seantek-windows-image-00.txt Status: https://datatracker.ietf.org/doc/draft-seantek-windows-image/ Htmlized: http://tools.ietf.org/html/draft-seantek-windows-image-00 Abstract: This document registers media types for certain image formats promulgated in Microsoft Windows, namely image/wmf, image/x-wmf, image/emf, image/x-emf, and image/bmp for use with Windows Metafile, Enhanced Metafile, and Windows Bitmap formats. Originally designed for Microsoft Windows 2.0 and 3.0, these image files are intended to be portable between applications and devices, and may contain both vector and raster graphics. The IETF Secretariat From nobody Wed Dec 17 10:58:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2B61A1BBE for ; Wed, 17 Dec 2014 10:58:02 -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 zvtWuHpbYkn4 for ; Wed, 17 Dec 2014 10:58:01 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D13C31A6FF0 for ; Wed, 17 Dec 2014 10:58:01 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DA38522E255 for ; Wed, 17 Dec 2014 13:58:00 -0500 (EST) Message-ID: <5491D22E.1060509@seantek.com> Date: Wed, 17 Dec 2014 10:57:50 -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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/b2gkqhGJ0EzirQI1p4bHMp1r4wY 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: Wed, 17 Dec 2014 18:58:03 -0000 On 12/17/2014 8:37 AM, Murray S. Kucherawy wrote: > This opens a call for adoption for draft-kerwin-file-scheme, to be > processed by APPSAWG. I support adoption. Sean From nobody Wed Dec 17 12:30:21 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC551A8AAB for ; Wed, 17 Dec 2014 12:30:20 -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 7j40LAR8f9UP for ; Wed, 17 Dec 2014 12:30:18 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505031A8764 for ; Wed, 17 Dec 2014 12:30:18 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id n12so21445322wgh.20 for ; Wed, 17 Dec 2014 12:30:17 -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=2LIhdiB0ggWpZuqebIRNsDxg08RvGjv9Ns/JnxKjKCk=; b=d0bcjVr4VWLmvESc2bZwx0zdt9CpNk40zpjyTkRGv5VzpwejT96NHpKL4Wab9qj8SP w1+LcQF5+HUlObXj/hWRnB91E7ceJav8NQqlgLEug9NxxtLzqLRvOs5W6se/kgtwHoDX 0WAqCBsyDCig3xuMY0hg8XEKj7SmBwOgMutqKWunXCy/m3fg/lhUxHrxDxeixsvxCKQC DaHdTldVrake9B2MDcVV5hkhKpPvGch/ALqVd+Xk45WDhfg95WXrKInYujVwU8nsr2ph nL32XNVmhh3sYaKg3jyt0iP2r40DIYKfvPl3lmsX4ra4VW+lSMVEMDrzfIdaWTf3asIp SVlw== X-Received: by 10.194.24.103 with SMTP id t7mr75789113wjf.15.1418848216847; Wed, 17 Dec 2014 12:30:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.177.218 with HTTP; Wed, 17 Dec 2014 12:29:56 -0800 (PST) In-Reply-To: References: From: Ira McDonald Date: Wed, 17 Dec 2014 15:29:56 -0500 Message-ID: To: "Murray S. Kucherawy" , Ira McDonald Content-Type: multipart/alternative; boundary=047d7b5d4398f49c19050a6f57d8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zBwM4rSid0sPWMLJIs5__0HHN1M 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: Wed, 17 Dec 2014 20:30:20 -0000 --047d7b5d4398f49c19050a6f57d8 Content-Type: text/plain; charset=UTF-8 Hi, I'm in favor of adoption of this document as an AppsAWG work item. 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 Wed, Dec 17, 2014 at 11:37 AM, Murray S. Kucherawy wrote: > > This opens a call for adoption for draft-kerwin-file-scheme, to be > processed by APPSAWG. There appears to be enough interest in the work > given the feedback it's getting, and it appears to fit within our charter. > > Please indicate your support or objection by replying to this thread. The > call will close on January 9, 2015. > > -MSK, APPSAWG co-chair > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --047d7b5d4398f49c19050a6f57d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

I'm in favor of adoption of this document as an AppsAWG work= item.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)<= br>Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation= Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chai= r - 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= : blueroofmusi= c@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


On Wed, Dec 17, 2014 at 11:37 AM, Murray S. = Kucherawy <superuser@gmail.com> wrote:
This opens a call for adoption for dr= aft-kerwin-file-scheme, to be processed by APPSAWG.=C2=A0 There appears to = be enough interest in the work given the feedback it's getting, and it = appears to fit within our charter.

Please indicate your suppor= t or objection by replying to this thread.=C2=A0 The call will close on Jan= uary 9, 2015.

-MSK, APPSAWG co-chair


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

--047d7b5d4398f49c19050a6f57d8-- From nobody Wed Dec 17 13:14:33 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BA51A9063 for ; Wed, 17 Dec 2014 13:14:31 -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 vHd6Xt43NSEG for ; Wed, 17 Dec 2014 13:14:30 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1D261A86E3 for ; Wed, 17 Dec 2014 13:14:29 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex7so17147278wid.9 for ; Wed, 17 Dec 2014 13:14:28 -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=evHzbvSF8hF68dVgwcK/kElqQSa0v1Asyfcs3yO/Bb0=; b=NMxeRtVC7JsWV5Xx0YMvYfg8zmj93EBcpiycnzu4NygG85WEtW7somj8flyZwOfP4i UmBaozqCCpRxQ3K7IZGmXeoe0cLAlBGk95sANWX17iCtbASA0eP3D3kkD/M4EwH+MaAO uZGocjzkJlgfw2PJwYRWpxxOvBJiYgyA2Bhge/NN1JvaOUu0YkKg3Pu6yVHAZYGv3qS0 zLheVTpxzdduWDqaHl7guupD51wlnsrR+iCvVLrSP9a8y6N3cjmubJC+muqSoJJVuwde Oy631HEtktz6uCj7qlhXoSu13bT+05Pdtmn3yurWD8ETHqCrB8hvOZznKXYHxaVDXIm8 n6Pg== MIME-Version: 1.0 X-Received: by 10.180.85.33 with SMTP id e1mr17793562wiz.61.1418850868565; Wed, 17 Dec 2014 13:14:28 -0800 (PST) Received: by 10.27.8.74 with HTTP; Wed, 17 Dec 2014 13:14:28 -0800 (PST) Date: Wed, 17 Dec 2014 13:14:28 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d04428074029f48050a6ff644 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/HWYhZE0S2q0CVL_EHvxTk4LKo0M Subject: [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: Wed, 17 Dec 2014 21:14:31 -0000 --f46d04428074029f48050a6ff644 Content-Type: text/plain; charset=UTF-8 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. -MSK, APPSAWG co-chair --f46d04428074029f48050a6ff644 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This note starts a Call For Adoption for draft-seante= k-windows-image.=C2=A0 This work was presented as two separate drafts at th= e Honolulu meeting and appeared to have some support and no objection to pr= ocessing through APPSAWG.

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

-MSK, APPSAWG co-chair
--f46d04428074029f48050a6ff644-- From nobody Wed Dec 17 17:23:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C5E1A00FF for ; Wed, 17 Dec 2014 17:23: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 Qb-0ADFyuWYl for ; Wed, 17 Dec 2014 17:23:16 -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 DB5D81A00FB for ; Wed, 17 Dec 2014 17:23:14 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:24959] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 8C/E8-24698-28C22945; Thu, 18 Dec 2014 01:23:14 +0000 Received: from [192.168.1.114] (unknown [192.168.1.114]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id 0141B1400D7; Wed, 17 Dec 2014 20:23:13 -0500 (EST) Message-ID: <54922C81.4030908@intertwingly.net> Date: Wed, 17 Dec 2014 20:23: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: "Murray S. Kucherawy" 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: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZQEt37zkDOSPmymZx8FRwLTX1FM Cc: apps-discuss@ietf.org, 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, 18 Dec 2014 01:23:19 -0000 On 12/17/2014 11:37 AM, Murray S. Kucherawy wrote: > This opens a call for adoption for draft-kerwin-file-scheme, to be > processed by APPSAWG. There appears to be enough interest in the work > given the feedback it's getting, and it appears to fit within our charter. > > Please indicate your support or objection by replying to this thread. > The call will close on January 9, 2015. This is NOT an objection, but I will note that draft-kerwin-file-scheme makes a reference to a document I co-edit: https://tools.ietf.org/html/draft-kerwin-file-scheme-13#ref-WHATWG-URL I further would like APPSAWG to consider the following as input: http://tools.ietf.org/html/draft-ruby-url-problem-00 - Sam Ruby From nobody Wed Dec 17 18:01:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945A41A00BD for ; Wed, 17 Dec 2014 18:01: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 UOhWlGDTD63g for ; Wed, 17 Dec 2014 18:01:53 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25B01A0097 for ; Wed, 17 Dec 2014 18:01:52 -0800 (PST) Received: by mail-qg0-f51.google.com with SMTP id e89so216645qgf.10 for ; Wed, 17 Dec 2014 18:01: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=muXtAWEKzsVrcG00f1H3UkoF/TUzvwwXD0oNiQXExnU=; b=FtDEHJPWF3urOkYoPPLWa2SbBcoSUSQSBbvA0dv6oYKQaq/xhp2VKmySl/b/g5sL1W 8YzA4fN+ETnh/6MoJxj657NV+MpxbRbfuPMHgU7+ySdVDMRqLWXrpOV2hFaD2qSaBwHX mi4KUd4h7XLI7xM7M4nCPHXYO9B3uVij+HzY2o4N8eV6Yw+9iU6bW7+9FqcFXsXA8vQh zi2csLPiJekgtJYvuoUxZ5VP/M6lLe6yg1gDcrUr41Z8X3+a24ThWup0+K3tNoLsOcub OQ1k1flNZAuC+Qo5PRUqlPi1S1ImO59bIcu2RB6semaQ4g0On8WpZkcWE4550yfvVeoy 4aNw== MIME-Version: 1.0 X-Received: by 10.229.249.137 with SMTP id mk9mr46856726qcb.4.1418868112185; Wed, 17 Dec 2014 18:01:52 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.86.163 with HTTP; Wed, 17 Dec 2014 18:01:52 -0800 (PST) In-Reply-To: <54922C81.4030908@intertwingly.net> References: <54922C81.4030908@intertwingly.net> Date: Thu, 18 Dec 2014 12:01:52 +1000 X-Google-Sender-Auth: 1T2GeIg3s6rUGScUxYnVGYGBSbk Message-ID: From: Matthew Kerwin To: Sam Ruby Content-Type: multipart/alternative; boundary=001a11334d90cf5e2a050a73f926 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/vcbzARe3IdpWCHUYiblgz8NHJs0 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, 18 Dec 2014 02:01:54 -0000 --001a11334d90cf5e2a050a73f926 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 18 December 2014 at 11:23, Sam Ruby wrote: > > This is NOT an objection, but I will note that draft-kerwin-file-scheme > makes a reference to a document I co-edit: > > https://tools.ietf.org/html/draft-kerwin-file-scheme-13#ref-WHATWG-URL > > I further would like APPSAWG to consider the following as input: > > http://tools.ietf.org/html/draft-ruby-url-problem-00 > > =E2=80=8BYes, the more this can tie in with other efforts (notably=E2=80=8B= in the W3C and WHATWG) the better. If draft-ruby-url-problem eventually ends up with a BCP we'll definitely do all we can to adhere to it, and even without, I think the principle is worthy and we'll strive anyway. If that involves a reference to a new informational RFC, all well and good. Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11334d90cf5e2a050a73f926 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 18 December 2014 at 11:23, Sam Ruby <rubys@intertwingly.net= > wrote:

This is NOT an objection, but I will note that draft-kerwin-file-scheme mak= es a reference to a document I co-edit:

https://tools.ietf.org/html/draft-kerwin-f= ile-scheme-13#ref-WHATWG-URL

I further would like APPSAWG to consider the following as input:

http://tools.ietf.org/html/draft-ruby-url-problem-00


=E2=80=8B= Yes, the more this can tie in with other efforts (notably=E2=80=8B in the W= 3C and WHATWG) the better. If=C2=A0draft-ruby-url-problem eventually ends u= p with a BCP we'll definitely do all we can to adhere to it, and even w= ithout, I think the principle is worthy and we'll strive anyway. If tha= t involves a reference to a new informational RFC, all well and good.
=
Cheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a11334d90cf5e2a050a73f926-- From nobody Wed Dec 17 18:58:00 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7E21A00E4 for ; Wed, 17 Dec 2014 18:57:58 -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 eCL7eEUxDd82 for ; Wed, 17 Dec 2014 18:57:56 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90EF1A00E1 for ; Wed, 17 Dec 2014 18:57:56 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C4D5222E1F4 for ; Wed, 17 Dec 2014 21:57:55 -0500 (EST) Message-ID: <549242A8.30207@seantek.com> Date: Wed, 17 Dec 2014 18:57:44 -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: <20141217075735.6060.32225.idtracker@ietfa.amsl.com> In-Reply-To: <20141217075735.6060.32225.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/UCFZR1gBWZBN2WdLVbZK4rE4r-M Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-04.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, 18 Dec 2014 02:57:58 -0000 The text/markdown draft has been updated. Please comment. This draft is a continuation fromdraft-ietf-appsawg-text-markdown- 03.txt . These technical changes were made: 1. Removed output-type optional parameter. 2. Renamed syntax optional parameter to variant. 3. Defined variant optional parameter as discussed on mailing list. 4. RemovedSection 3 (which may be replaced with Content- Disposition/preview-type in the future). 5. Redid the fragment identifier considerations, simplifying the specification considerably. 6. Discussed the meaning of "variant" in the context of Markdown. 7. Redefined the IANA registry as "Markdown Variants" and expanded its applicability outside of this particular media type. 8. Drastically simplified the registration template. Sean On 12/16/2014 11:57 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-04.txt > Pages : 14 > Date : 2014-12-16 > > 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. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-text-markdown-04 > > > 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/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Thu Dec 18 02:19:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78C91A6F57 for ; Thu, 18 Dec 2014 02:19:43 -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 jYdRSxavG-I2 for ; Thu, 18 Dec 2014 02:19:42 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0785.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::785]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8D91A6F83 for ; Thu, 18 Dec 2014 02:19:41 -0800 (PST) Received: from pc6 (81.151.166.145) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 18 Dec 2014 10:19:17 +0000 Message-ID: <00e301d01aac$08eea8e0$4001a8c0@gateway.2wire.net> From: t.petch To: Sam Ruby , "Murray S. Kucherawy" References: <54922C81.4030908@intertwingly.net> Date: Thu, 18 Dec 2014 10:16:47 +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.166.145] X-ClientProxiedBy: DB4PR02CA0030.eurprd02.prod.outlook.com (10.242.174.158) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;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: 042957ACD7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(24454002)(51704005)(189002)(377454003)(479174004)(13464003)(89996001)(42186005)(40100003)(101416001)(84392001)(120916001)(62966003)(50466002)(33646002)(23756003)(77156002)(50986999)(50226001)(68736005)(122386002)(62236002)(1456003)(19580395003)(14496001)(77096005)(21056001)(15975445007)(19580405001)(105586002)(31966008)(64706001)(46102003)(107046002)(106356001)(92566001)(76176999)(81686999)(20776003)(66066001)(87976001)(4396001)(97736003)(44716002)(61296003)(81816999)(86362001)(230783001)(1720100001)(47776003)(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 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QFYh4zWdj5A_1FRhTRQnw629no4 Cc: apps-discuss@ietf.org, 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, 18 Dec 2014 10:19:44 -0000 ----- Original Message ----- From: "Sam Ruby" To: "Murray S. Kucherawy" Cc: ; "Larry Masinter" Sent: Thursday, December 18, 2014 1:23 AM > On 12/17/2014 11:37 AM, Murray S. Kucherawy wrote: > > This opens a call for adoption for draft-kerwin-file-scheme, to be > > processed by APPSAWG. There appears to be enough interest in the work > > given the feedback it's getting, and it appears to fit within our charter. > > > > Please indicate your support or objection by replying to this thread. > > The call will close on January 9, 2015. > > This is NOT an objection, but I will note that draft-kerwin-file-scheme > makes a reference to a document I co-edit: > > https://tools.ietf.org/html/draft-kerwin-file-scheme-13#ref-WHATWG-URL > True, it does, but as in Informational Reference as part of the history of the file: scheme. As such, it could easily be removed with no loss to the Normative part of this specification. I have read WHATWG-URL and do not think that it contributes to the objectives of draft-kerwin-file-scheme and so while I am fine with keeping the reference in, I do not think that it should be a factor in the discussions of draft-kerwin-file-scheme. Tom Petch > I further would like APPSAWG to consider the following as input: > > http://tools.ietf.org/html/draft-ruby-url-problem-00 > > - Sam Ruby > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Thu Dec 18 06:06:34 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5271A89F5 for ; Thu, 18 Dec 2014 06:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 GU08TzwJbgjK for ; Thu, 18 Dec 2014 06:06:29 -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 357ED1A89BB for ; Thu, 18 Dec 2014 06:06:29 -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 99CA3C40076; Thu, 18 Dec 2014 08:08:20 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1418911700; bh=6+cwGIO5XPpS7ePyrvDIE0wRr/e61rT/g94ZU43Oc6g=; h=From:To:Subject:Date:In-Reply-To:References:From; b=vZlr6dAYM69o1YZebZ0CX1P5pZO+IqEo811lRVdD7zFD9hR/H+cXFSxaFyg9u/jXV vO/Z+YlLdyq/vH/Vu7B2YjkPvhVXvLU4/V2068sJ1uair9/Eyse0KiD8hCyeI010lR uBHl+7BX66Z112Q3Cxdi51AxswA23lBwWhUVY8H8= From: Scott Kitterman To: apps-discuss@ietf.org Date: Thu, 18 Dec 2014 09:06:27 -0500 Message-ID: <6696385.C9EWBcZ1Pq@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: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/xwSdLIQgJSjw_v9fZHCVjieENM4 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, 18 Dec 2014 14:06:32 -0000 On Wednesday, December 17, 2014 08:37:34 Murray S. Kucherawy wrote: > This opens a call for adoption for draft-kerwin-file-scheme, to be > processed by APPSAWG. There appears to be enough interest in the work > given the feedback it's getting, and it appears to fit within our charter. > > Please indicate your support or objection by replying to this thread. The > call will close on January 9, 2015. > > -MSK, APPSAWG co-chair In its current form, the draft has normative references to two non-IETF documents that don't have clear licensing terms, specifically MS-DTYP and MS- NBTE. As nearly as I can determine, these are not covered by the Microsoft Open Specification Promise [1]. Given that these are normative references, I think it's essential that their IPR status be clear. I don't think it's appropriate on something as fundamental as the file URI scheme to end up with a document that's IPR constrained. Before this document is accepted, it should either be reworked to no require these as normative references or the IPR status of the references should be clarified to make it clear that their use is not encumbered (adding them to the OSP would be a great way to do this). Scott K [1] http://www.microsoft.com/openspecifications/en/us/programs/osp/default.aspx From nobody Thu Dec 18 08:20:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6451A8BAF for ; Thu, 18 Dec 2014 08:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, 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 1Hnuz9F24axc for ; Thu, 18 Dec 2014 08:20:42 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (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 818011A8AEB for ; Thu, 18 Dec 2014 08:20:42 -0800 (PST) Received: from [10.20.30.90] (50-1-99-181.dsl.dynamic.fusionbroadband.com [50.1.99.181]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sBIGKf1F090654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 Dec 2014 09:20:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-99-181.dsl.dynamic.fusionbroadband.com [50.1.99.181] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 18 Dec 2014 08:20:41 -0800 To: 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/xDCPgm7t6ppEGm_U-SjySGotg4M Subject: [apps-discuss] URL definitions and draft-ruby-url-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2014 16:20:47 -0000 This seems like an important document for us to look at, and possibly = adopt. Section 3 is pretty scary, and section 4 seems like a very = reasonable solution. --Paul Hoffman= From nobody Thu Dec 18 11:11:16 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F10B1A6F58 for ; Thu, 18 Dec 2014 11:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNzrnhWNtSfO for ; Thu, 18 Dec 2014 11:11:11 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0132.outbound.protection.outlook.com [207.46.100.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD351A1B8C for ; Thu, 18 Dec 2014 11:11:10 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB410.namprd03.prod.outlook.com (10.141.141.16) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 18 Dec 2014 19:11:08 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0031.000; Thu, 18 Dec 2014 19:11:08 +0000 From: Dave Thaler To: "Murray S. Kucherawy" , IETF Apps Discuss Thread-Topic: [apps-discuss] Call For Adoption: draft-seantek-windows-image Thread-Index: AQHQGj55WW3jBDMDbkuUs9SZKVIIfZyVuAaA Date: Thu, 18 Dec 2014 19:11:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.237.193.222] authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB410; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB410; x-forefront-prvs: 042957ACD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(377454003)(68736005)(107046002)(33656002)(19580395003)(106356001)(54606007)(21056001)(97736003)(19580405001)(77156002)(76576001)(102836002)(107886001)(230783001)(77096005)(74316001)(64706001)(15975445007)(31966008)(16236675004)(40100003)(122556002)(19625215002)(76176999)(99396003)(101416001)(86362001)(4396001)(66066001)(120916001)(54356999)(105586002)(46102003)(86612001)(50986999)(19300405004)(2950100001)(106116001)(62966003)(87936001)(92566001)(54206007)(99286002)(2900100001)(2656002)(20776003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB410; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BY2PR03MB412E241090FF723E7A38CF9A36A0BY2PR03MB412namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/bv05kUf8qZkWFfdP7FILnz-R5JY 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: Thu, 18 Dec 2014 19:11:13 -0000 --_000_BY2PR03MB412E241090FF723E7A38CF9A36A0BY2PR03MB412namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZXZpZXdlZCB0aGUgZHJhZnQsIGFuZCBzdXBwb3J0IGFkb3B0aW9uLg0KDQotRGF2ZQ0KDQpG cm9tOiBhcHBzLWRpc2N1c3MgW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIE11cnJheSBTLiBLdWNoZXJhd3kNClNlbnQ6IFdlZG5lc2RheSwgRGVjZW1i ZXIgMTcsIDIwMTQgMToxNCBQTQ0KVG86IElFVEYgQXBwcyBEaXNjdXNzDQpTdWJqZWN0OiBbYXBw cy1kaXNjdXNzXSBDYWxsIEZvciBBZG9wdGlvbjogZHJhZnQtc2VhbnRlay13aW5kb3dzLWltYWdl DQoNClRoaXMgbm90ZSBzdGFydHMgYSBDYWxsIEZvciBBZG9wdGlvbiBmb3IgZHJhZnQtc2VhbnRl ay13aW5kb3dzLWltYWdlLiAgVGhpcyB3b3JrIHdhcyBwcmVzZW50ZWQgYXMgdHdvIHNlcGFyYXRl IGRyYWZ0cyBhdCB0aGUgSG9ub2x1bHUgbWVldGluZyBhbmQgYXBwZWFyZWQgdG8gaGF2ZSBzb21l IHN1cHBvcnQgYW5kIG5vIG9iamVjdGlvbiB0byBwcm9jZXNzaW5nIHRocm91Z2ggQVBQU0FXRy4N Cg0KUGxlYXNlIHJlcGx5IHdpdGggc3VwcG9ydCBvciBvYmplY3Rpb24gb24gdGhpcyB0aHJlYWQg YnkgSmFudWFyeSA5LCAyMDE1Lg0KLU1TSywgQVBQU0FXRyBjby1jaGFpcg0K --_000_BY2PR03MB412E241090FF723E7A38CF9A36A0BY2PR03MB412namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5 NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9 IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHJldmlld2VkIHRoZSBkcmFmdDxh IG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+LCBhbmQgc3VwcG9ydCBhZG9wdGlvbi48bzpwPjwvbzpw PjwvYT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tRGF2ZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGFw cHMtZGlzY3VzcyBbbWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5NdXJyYXkgUy4gS3VjaGVyYXd5PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5l c2RheSwgRGVjZW1iZXIgMTcsIDIwMTQgMToxNCBQTTxicj4NCjxiPlRvOjwvYj4gSUVURiBBcHBz IERpc2N1c3M8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2FwcHMtZGlzY3Vzc10gQ2FsbCBGb3IgQWRv cHRpb246IGRyYWZ0LXNlYW50ZWstd2luZG93cy1pbWFnZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij5UaGlzIG5vdGUgc3RhcnRzIGEgQ2FsbCBGb3IgQWRvcHRpb24gZm9yIGRyYWZ0 LXNlYW50ZWstd2luZG93cy1pbWFnZS4mbmJzcDsgVGhpcyB3b3JrIHdhcyBwcmVzZW50ZWQgYXMg dHdvIHNlcGFyYXRlIGRyYWZ0cyBhdCB0aGUgSG9ub2x1bHUgbWVldGluZyBhbmQgYXBwZWFyZWQg dG8gaGF2ZSBzb21lIHN1cHBvcnQgYW5kIG5vIG9iamVjdGlvbiB0byBwcm9jZXNzaW5nDQogdGhy b3VnaCBBUFBTQVdHLjxicj4NCjxicj4NClBsZWFzZSByZXBseSB3aXRoIHN1cHBvcnQgb3Igb2Jq ZWN0aW9uIG9uIHRoaXMgdGhyZWFkIGJ5IEphbnVhcnkgOSwgMjAxNS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LU1TSywgQVBQU0FXRyBjby1jaGFpcjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY2PR03MB412E241090FF723E7A38CF9A36A0BY2PR03MB412namprd_-- From nobody Thu Dec 18 20:07:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220CA1A908B for ; Thu, 18 Dec 2014 20:07: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] 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 0h03hpEGojUx for ; Thu, 18 Dec 2014 20:07:37 -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 9F8171A006F for ; Thu, 18 Dec 2014 20:07:37 -0800 (PST) Received: from [173.246.8.145] (port=50864 helo=[10.0.0.81]) by cp.hebergementsolutions.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1Y1opX-0007zg-60; Thu, 18 Dec 2014 23:06:19 -0500 Content-Type: multipart/signed; boundary="Apple-Mail=_FEBDBC5E-6AA5-4DAC-BCC3-C5CD8B61768A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Michel Fortin In-Reply-To: <549242A8.30207@seantek.com> Date: Thu, 18 Dec 2014 23:07:27 -0500 Message-Id: <76A69E11-0325-4222-A8E6-41324E2DA5C2@michelf.ca> References: <20141217075735.6060.32225.idtracker@ietfa.amsl.com> <549242A8.30207@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.1993) X-cPanel-MailScanner-Information: Please contact the ISP for more information X-cPanel-MailScanner-ID: 1Y1opX-0007zg-60 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: http://mailarchive.ietf.org/arch/msg/apps-discuss/4PuW16dPr9SmskhCef4ihhyjLn0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-04.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, 19 Dec 2014 04:07:40 -0000 --Apple-Mail=_FEBDBC5E-6AA5-4DAC-BCC3-C5CD8B61768A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 17-d=C3=A9c.-2014 =C3=A0 21:57, Sean Leonard a = =C3=A9crit : >> http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-04 Section 2:=20 Additionally, implementations SHOULD record syntax and output-type parameters along with the Markdown, such as in extended attributes; however, the exact manner of storage is a local matter Looks outdated. There's no "output-type" in this version of the spec. = Also, "syntax" is now "variant". And to me this sounds like empty = guidance (do this thing we don't know how to do and which you'll likely = end up doing in a non-interoperable way). I'd rather say nothing. 4: Fragment identifiers In my opinion there is no point in having such a section. The = "general-purpose" fragment identifiers are basically undefined. Markdown = doesn't have identifiers, and variants that implement something like = this often do so in different ways, and sometime they're implicitly = generated from title names, footnote numbers, etc, again often in = non-compatible ways. I'd basically replace the whole section 4 with this two-sentence = paragraph: "Markdown doesn't define any fragment identifiers, but some = variants do. Which fragment identifiers are available for a given = document are variant-defined." 4.2: about #line=3Dx I can't find any browser supporting this for text/plain. Is this in = useful anywhere? Beside, take note that it's meaningless in any context = where the Markdown text has been interpreted and rendered as something = else than a plain text document. 5: Example: Content-Type: text/markdown; charset=3DUTF-8; syntax=3DOriginal; output-type=3D"application/xhtml+xml" Can I say "outdated" again? 6: The variant registry I still don't know what to think about this. It's good to have a list of = variants available, but given I don't expect Markdown parser = implementers are going to bother registering things there it looks like = a fertile ground for squatting given that first-come first-served = policy. --=20 Michel Fortin michel.fortin@michelf.ca https://michelf.ca --Apple-Mail=_FEBDBC5E-6AA5-4DAC-BCC3-C5CD8B61768A 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 DQEJBTEPFw0xNDEyMTkwNDA3MzNaMCMGCSqGSIb3DQEJBDEWBBSbBmFxcF9AQQhAV6QRAYsdWqFm vTCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwmYBjCB pwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCZgGMA0G CSqGSIb3DQEBAQUABIIBABpundJxxV4U3GlYNzEnvcm0CUTP+h13O20i7h5zEiY18d/hTJoPPEZU tLJTs20kl8+z+GZCULNLChBMtoEjIukgzfC/v6VU7o2iwne06Wcx6jcxdDGk4eQnTHhpqWgfVHqP eMe6bJ0LUA8qB441w+CbWz7jORJxj/DdkCVuLmm6osTl9JY4+0jajpn8mHyvWPEhbfHsjyT5QK5o HpJMvHgWA3/irscAmAlKsZywooGF31JZv993ZMVx6+s+mIA6lpf51559RY2reFdOboGf+qOMxCBx MZMCwxYEvVRV5JJ9tSEOxk9LV1WrYAc2pFNocA30OCHSy++QdHbE4Jls0c4AAAAAAAA= --Apple-Mail=_FEBDBC5E-6AA5-4DAC-BCC3-C5CD8B61768A-- From nobody Fri Dec 19 10:41:17 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F9D1A8AD4 for ; Fri, 19 Dec 2014 10:41:16 -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 taqflHCmlW-O for ; Fri, 19 Dec 2014 10:41:14 -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 AB9661A1BE4 for ; Fri, 19 Dec 2014 10:41:13 -0800 (PST) Received: from netb ([89.204.153.247]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Ltqmn-1XsS8w3rk5-0119Gf; Fri, 19 Dec 2014 19:41:10 +0100 From: Bjoern Hoehrmann To: Paul Hoffman Date: Fri, 19 Dec 2014 19:41:02 +0100 Message-ID: <00o89a147re95aor21u3l9a7aarrhg0vts@hive.bjoern.hoehrmann.de> References: 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:6hRMa8IAIIG7XAKOarwAqQF5ovU6+aO6R1SROaiU9oU//ZK35Jz tStt9bq4tx/wfrzKNDDMdfMNPKAl/o7LtWTYFEGeV68H7iTqAyDkhN+TgOiR6JERnoQXk0K ecxFPA9JOvqi0xuSAqnwfPZQI03Bw6R4/LVX1UFVjXlHBh8pZqvAAgh/xxYN6R37Z2LWDis jRkhQYqxxMsuqKBwoT5JQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tFUzvF4zFfGgIqJwYkE6UfqAsFI Cc: Apps Discuss Subject: Re: [apps-discuss] URL definitions and draft-ruby-url-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 18:41:16 -0000 * Paul Hoffman wrote: >This seems like an important document for us to look at, and possibly >adopt. Section 3 is pretty scary, and section 4 seems like a very >reasonable solution. I have reviewed this document. Sections 1 and 2 seem reasonable to me. Section 3 has The main problem is conflicting specifications that overlap but don't match each other. Additionally, the following are issues that need to be resolves to make URL processing unambiguous and stable. o Nomenclature: over the years, a number of different sets of terminology has been used. URL / URI / IRI is not the only difference. [tantek-slice] chronicles a number of differences. The latter refers to differences among APIs for manipulating resource identifiers. I do not think that is a problem and does not need solving. o Parameterization: standards in this area need to define such matters as normalization forms and values for parameters such as UseSTD3ASCIIRules. Where the relevant standards allow implementations to choose options, it is usually because there are good reasons to do so. Implementers ought to document their choices properly, and it is a good thing when similar implementations make the same choices, it might even be useful to have a specification saying "Web browsers must use these options: A, B, C", but that would just be a matter of doing it. So I am not sure what problem needs solving in this regard. o Interoperability: even after accounting for the above, there is a demonstrable lack of interoperability across popular libraries and browsers. [whatwg-interop] identifies a number of such differences. There are different classes of problems in this regard, e.g. there may be existing requirements that are widely ignored, there may be ambiguous requirements interpreted differently across implementations, there may be implementation-defined behavior that varies across implementations in a harmful manner, or there may be widely deployed behavior where further standardisation might be useful, to mention a few. I think it would be helpful to discuss these classes of problems separately. 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'). An open question here seems to be how to separate concerns. Can updating specifications for individual schemes be done independently? If so, that also would seem to simply require somebody doing it, so I am not sure of the problem indicated here. As for the "Outline of Potential Solution" in section 4, I agree that a plan should be built. How many specifications, for instance, should we have, what would be their scope, and what would be their contents? With- out a plan, considering the other points in the section seems premature; perhaps some of them are reasonable things to do independently of any plan; in that case, they could simply be done. -- 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 Fri Dec 19 10:42:03 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E161ACC80 for ; Fri, 19 Dec 2014 10:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 cY1qrCORnccg for ; Fri, 19 Dec 2014 10:41: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 E92C21A1BE4 for ; Fri, 19 Dec 2014 10:41: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 1Y22Uv-0007XX-hJ; Fri, 19 Dec 2014 18:41:57 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina-wl.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 1Y22Uv-0001Zi-GU; Fri, 19 Dec 2014 18:41:57 +0000 Message-ID: <54947170.3040200@ninebynine.org> Date: Fri, 19 Dec 2014 18:41: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: Sean Leonard , "apps-discuss@ietf.org" References: <586A4911-2795-4EF6-A4E1-6F14A294E5B2@seantek.com> In-Reply-To: <586A4911-2795-4EF6-A4E1-6F14A294E5B2@seantek.com> 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/0sTnqwroDJkDTfHrZKKSUOt_-no Subject: [apps-discuss] Comments on draft-ietf-appsawg-text-markdown-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: Fri, 19 Dec 2014 18:42:02 -0000 Sean, All, [These are comments I sent initially to Sean, but not in time for the I-D publication, so I'm re-posting here] 1. I think you should update the example before publication - as it stands I think it's confusing (see later). 2. I think section 3 should be renamed and a TODO-style comment added -- see below ... or actually deleted. More detailed comments follow. ... Sect 1.2: "The paradigmatic use case for text/markdown..." doesn't make sense to me. I'm not sure what you mean by "paradigmatic" here. Sect 2, 'charset' parameter. I think some of the commentary (after the first sentence) here belongs under "encoding considerations" Sect 2: Optional parameters. I think the balance here is about right. I have niggle about possible clashes between "other parameters" and other media-type defined parameters (e.g. 'charset') - but I suspect it's a non-problem and I'd wait to see what other feedback you get before worrying too much about that. Sect 2: security considerations: mentions an "output-type" parameter that I don't see described. I think we agreed to drop this as it wasn't really part of the markdown content format. I think the rest of the commentary is still relevant: suggest drop the first sentence: "Security provides a significant motivator for the output-type parameter." Sect 2: Interoperability considerations: mentions "syntax" parameter. Shouldn't this now be "variant"? Maybe also "associated with" rather than "identifier in"? Sect 3: clearly still work to do here (or drop the section) - but that's OK for a draft. Suggest adding a TODO-style note saying that output type is not part of the input format, and may be indicated by some other MIME header in a vein similar to content-disposition. And change the section title. ... Section 4.1, 4.2: I think the discussion here is useful, but I'm not sure if it really belongs, especially with normative content. There's a real danger here of getting in to too much detail. The easy choice is to not introduce named parameters in fragments, and just leave it to the markdown variant. But that's somewhat at odds with the web principle that a MIME type indicates for the fragment identifier should be interpreted. In this case, I'm, not sure how best to square these. I'd probably be OK with a general overarching syntax for fragments, with all details of interpretation left to the Markdown variant used (but being aware that the fate of a lot of Markdown is to be rendered as HTML.). What follow are some more detailed thoughts which should be treated as subservient to this high-order consideration. If the fragment issue becomes contentious, I'd suggest being prepared to simply drop it from the specification (at least in this incarnation). ... Section 4.1: "When encoded in a URI, the production..." I'm not sure what you mean by "production" here, and the term is likely to be confused with the syntax production mentioned subsequently. Maybe just say "the fragment identifier SHALL..." here? (Does this need saying at all? It's already a requirement of RFC3986, but I'm OK if you think the emphasis is useful) I'm wary of "The character set for percent-encoded octets SHALL be the same as the Markdown content, i.e., identified by the charset parameter or by other contextual means." I'm not even sure that it always makes sense. The current tendency is to %-encode URIs via UTF-8 encoding of the underlying characters. In this case, I think it's sufficient that interpretation of the fragment identifier is dependent on the Markdown variant used, which I think is pretty much what you already say. (Example: consider a variant that is presented to a converter as, say "Windows-1252", but which is emitted by a converter as UTF-8-encoded HTML. You have already emphasized Markdown as consisting of characters not codepoints, so having a URI fragment that is expressed with respect to code points in the source seems odd to me.) ... Sections 4.1, 4.2: I think the relationship between these sections is potentially confusing, and could use some work. I'd be inclined to start with a general reference to fragment identifiers containing named parameters (which, BTW, conflicts with what you say about character encoding, as the encoding of the '=' must be independent of the content encoding -- I know it's contrived, but suppose the Markdown is EBCDIC-encoded). Having introduced the general fragment syntax, you can go on to say that its interpretation is dependent on the markdown variant or processor used. I'm uneasy about the choice of "&" as a parameter separator, as it would introduce escaping complications if one just wants to copy the fragment into an XML/HTML-based format (which I suggest may be a common scenario). I'd be inclined to use ';' as proposed in http://w3ctag.github.io/packaging-on-the-web/#fragment-identifiers (you could also exploit the syntax described there). (I note that http://tools.ietf.org/html/rfc5147 doesn't allow multiple parameters.) If you introduce this style of fragment identifier, I think something like "id=" could be defined to refer to whatever maps to HTML id= values in the variant used. I not sure about including line= from the RFC5147 spec, as I think it has the same problems as a character-based specification. ... Section 5: Your example includes parameters not described in the text. I think this is confusing and unhelpful. Update to be in line with text. ... Section 6: I'm not sure that an expiration date serves any useful purpose, and potentially adds administrative overhead. [Later] I see what you're doing. A problem here is that it's not clear how a provisional registration becomes permanent. I think it would be simpler to just avoid provisional registration, but provide an "escape hatch" to allow registrations to be revoked by (e.g.) the IESG I'd be interested to know why you want to include "~" in the registered identifiers. My inclination would be to keep the variant names very restricted (e.g. letters, digits, "_" only) to maximize compatibility with other systems, OR to impose very few restrictions; i.e. exclude just those characters needed for other syntactic purposes similar to the way URI syntax is defined. I think the character set for the other fields should be checked with IANA if they are to maintain the registry. Usually, in my experience, as registration templates often appear in RFCs, just ASCII characters are used. ... That's all! #g -- On 17/12/2014 00:32, Sean Leonard wrote: > Hello Reviewers: > > I worked on draft-ietf-appsawg-text-markdown-04. > > This is a prelim notice before I post it to the IETF Internet-Drafts repository for public comment (probably will happen late tonight or sometime tomorrow). Let me know if you see any glaring problems. > > I tried to stick mostly with what has been discussed publicly. I also took another crack at fragment identifiers but otherwise tried to remain conservative. > > Thanks, > > Sean > From nobody Fri Dec 19 11:47:16 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A8C1A6FE5 for ; Fri, 19 Dec 2014 11:47: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 JTmzPNRy3pVT for ; Fri, 19 Dec 2014 11:47:11 -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 4E65B1ACD88 for ; Fri, 19 Dec 2014 11:47:11 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:52519] helo=rubix) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 0C/F0-29348-EB084945; Fri, 19 Dec 2014 19:47: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 004DE140D25; Fri, 19 Dec 2014 14:47:09 -0500 (EST) Message-ID: <549480BD.6080309@intertwingly.net> Date: Fri, 19 Dec 2014 14:47: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: Bjoern Hoehrmann References: <00o89a147re95aor21u3l9a7aarrhg0vts@hive.bjoern.hoehrmann.de> In-Reply-To: <00o89a147re95aor21u3l9a7aarrhg0vts@hive.bjoern.hoehrmann.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/itrBpLovEnKxe_Rka9WO_vnisJg Cc: Paul Hoffman , Apps Discuss Subject: Re: [apps-discuss] URL definitions and draft-ruby-url-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 19:47:14 -0000 On 12/19/2014 01:41 PM, Bjoern Hoehrmann wrote: > * Paul Hoffman wrote: >> This seems like an important document for us to look at, and possibly >> adopt. Section 3 is pretty scary, and section 4 seems like a very >> reasonable solution. > > I have reviewed this document. Sections 1 and 2 seem reasonable to me. Thanks! > Section 3 has > > The main problem is conflicting specifications that overlap but don't > match each other. > > Additionally, the following are issues that need to be resolves to > make URL processing unambiguous and stable. > > o Nomenclature: over the years, a number of different sets of > terminology has been used. URL / URI / IRI is not the only > difference. [tantek-slice] chronicles a number of differences. > > The latter refers to differences among APIs for manipulating resource > identifiers. I do not think that is a problem and does not need solving. Can I ask why not? To be clear, I'm not suggesting that everybody adopt the same terms. I am suggesting that somewhere we document what terms are in use and how they map. > o Parameterization: standards in this area need to define such > matters as normalization forms and values for parameters such as > UseSTD3ASCIIRules. > > Where the relevant standards allow implementations to choose options, it > is usually because there are good reasons to do so. Implementers ought > to document their choices properly, and it is a good thing when similar > implementations make the same choices, it might even be useful to have a > specification saying "Web browsers must use these options: A, B, C", but > that would just be a matter of doing it. So I am not sure what problem > needs solving in this regard. First, it is not just web browsers. It is runtime libraries that accompany various programming languages. It is code embedded in word processors and web servers. I don't believe that having the URLs mean different things based on the context is in any body's best interests. At a minimum, we should consider clearly documenting the set of URLs that are may be interpreted differently in different contexts. Perhaps we should identify those URLs as non-conforming. However, that's not enough. Consider ICANN approved non-ASCII domain names. Different RFC 3986 compliant libraries handle https URLs with such hostnames differently. We can't simply tell people to avoid such. > o Interoperability: even after accounting for the above, there is a > demonstrable lack of interoperability across popular libraries and > browsers. [whatwg-interop] identifies a number of such > differences. > > There are different classes of problems in this regard, e.g. there may > be existing requirements that are widely ignored, there may be ambiguous > requirements interpreted differently across implementations, there may > be implementation-defined behavior that varies across implementations in > a harmful manner, or there may be widely deployed behavior where further > standardisation might be useful, to mention a few. I think it would be > helpful to discuss these classes of problems separately. I agree! To seed the discussion, I offer the following web page with a number of interesting test cases: https://url.spec.whatwg.org/interop/test-results/ Feel free to propose additional test cases, suggest categorizations, or changes to either specs or to libraries, or even additional libraries that should be included. > 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'). > > An open question here seems to be how to separate concerns. Can updating > specifications for individual schemes be done independently? If so, that > also would seem to simply require somebody doing it, so I am not sure of > the problem indicated here. One thing that is important to recognize is that every modern programming language is going to have a URI or URL parse function, method, subroutine, or whatever. While it may make sense to allow new schemes to impose additional validity requirements specific to their scheme or additional semantics, it is in everybody's best interests if we define a standard way in which URLs which make use of unknown URL schemes are to be parsed. Note: I am *NOT* suggesting that what currently is in the WHATWG URL Living Standard is that definition. I think we need something a bit closer to what RFC 3986 defines. I welcome input on what that behavior should be. Let's work on it together. Meanwhile, https://www.w3.org/Bugs/Public/show_bug.cgi?id=27233 is open on this issue. > As for the "Outline of Potential Solution" in section 4, I agree that a > plan should be built. How many specifications, for instance, should we > have, what would be their scope, and what would be their contents? With- > out a plan, considering the other points in the section seems premature; > perhaps some of them are reasonable things to do independently of any > plan; in that case, they could simply be done. There is indeed a big chicken and egg problem here. My best guess at this moment is that RFC 3987 needs to be retired and work needs to start on a RFC 3986bis, and that probably needs a new Working Group. And that needs the discussion we are currently having to happen. I will say that I'm willing to work with anybody, anywhere. If work on a RFC 3986bis starts, I will contribute. I also am not looking to make this somebody else's problem. If it means I need to step up to be that editor, I will do that too. And in the process, I will actively encourage others to contribute, and by that I mean GitHub pull requests. But I will also say that while we should be having the high level discussion at this time and in parallel to the technical discussions about how various classes of input strings should be parsed, it really is the latter (parser) discussion that we should be doing the deep dive on. Once we have a starter set list of proposed changes, we can circle back and determine whether a set of errata is sufficient or if the overhead of an entire Working Group is required. However, that is just my preference. Should you be interested in suggesting changes to draft-ruby-url-problem, I encourage pull requests for that too. Julian Reschke has already submitted a few. You could be next! - Sam Ruby From nobody Fri Dec 19 12:56:13 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B6E1A7023 for ; Fri, 19 Dec 2014 12:56:12 -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 selhx-suz6vd for ; Fri, 19 Dec 2014 12:56:10 -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 68AA41A7011 for ; Fri, 19 Dec 2014 12:56:10 -0800 (PST) Received: from netb ([89.204.153.247]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MT60g-1YS1xK2iRy-00S4nX; Fri, 19 Dec 2014 21:56:07 +0100 From: Bjoern Hoehrmann To: Sam Ruby Date: Fri, 19 Dec 2014 21:56:02 +0100 Message-ID: References: <00o89a147re95aor21u3l9a7aarrhg0vts@hive.bjoern.hoehrmann.de> <549480BD.6080309@intertwingly.net> In-Reply-To: <549480BD.6080309@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:srBctGU/cU+oAhdi7kJrLwXNZ7hhYkLGXGCNfOH1bqr1KHg+x3n 6tfZ1PR7zxRZEqDCmHutwSUWkAvO9/OQfE5zhO4VsY/CsGF660jtglnjZcz/PO3mNJFjiqn cTlD3ac7rQht//MViggBPnNZTfvBk7AICP3Yh8JdnJUikl9SHLsB6CHXZNldkckHOzO9iHI D9/GGm7wfRDSFLWlLnjSA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/RbnoEmok-GgYIM1CQngID9HsysE Cc: Paul Hoffman , Apps Discuss Subject: Re: [apps-discuss] URL definitions and draft-ruby-url-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 20:56:12 -0000 * Sam Ruby wrote: >On 12/19/2014 01:41 PM, Bjoern Hoehrmann wrote: >> o Nomenclature: over the years, a number of different sets of >> terminology has been used. URL / URI / IRI is not the only >> difference. [tantek-slice] chronicles a number of differences. >> >> The latter refers to differences among APIs for manipulating resource >> identifiers. I do not think that is a problem and does not need solving. > >Can I ask why not? > >To be clear, I'm not suggesting that everybody adopt the same terms. I >am suggesting that somewhere we document what terms are in use and how >they map. Well, as an example, RFC 3986 defines the term "fragment identifier". If we document that some APIs call it `hash` and APIs vary in whether they include the `#` separator, who could do something easily that is hard to do at the moment? >First, it is not just web browsers. It is runtime libraries that >accompany various programming languages. It is code embedded in word >processors and web servers. I don't believe that having the URLs mean >different things based on the context is in any body's best interests. > >At a minimum, we should consider clearly documenting the set of URLs >that are may be interpreted differently in different contexts. Perhaps >we should identify those URLs as non-conforming. > >However, that's not enough. Consider ICANN approved non-ASCII domain >names. Different RFC 3986 compliant libraries handle https URLs with >such hostnames differently. We can't simply tell people to avoid such. Identifying problematic sets of resource identifiers with unstable in- terpretation would be very useful. We could then decide what to do about those cases. >One thing that is important to recognize is that every modern >programming language is going to have a URI or URL parse function, >method, subroutine, or whatever. While it may make sense to allow new >schemes to impose additional validity requirements specific to their >scheme or additional semantics, it is in everybody's best interests if >we define a standard way in which URLs which make use of unknown URL >schemes are to be parsed. > >Note: I am *NOT* suggesting that what currently is in the WHATWG URL >Living Standard is that definition. I think we need something a bit >closer to what RFC 3986 defines. Agreed. >But I will also say that while we should be having the high level >discussion at this time and in parallel to the technical discussions >about how various classes of input strings should be parsed, it really >is the latter (parser) discussion that we should be doing the deep dive on. > >Once we have a starter set list of proposed changes, we can circle back >and determine whether a set of errata is sufficient or if the overhead >of an entire Working Group is required. Sounds good to me. -- 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 Fri Dec 19 16:45:40 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548201A8032 for ; Fri, 19 Dec 2014 16:45: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 DqHHoXgOQPjD for ; Fri, 19 Dec 2014 16:45: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 B8B0E1A1B0D for ; Fri, 19 Dec 2014 16:45:37 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:10091] helo=rubix) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 80/78-17706-0B6C4945; Sat, 20 Dec 2014 00:45: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 BA61E140D25; Fri, 19 Dec 2014 19:45:35 -0500 (EST) Message-ID: <5494C6AF.4070902@intertwingly.net> Date: Fri, 19 Dec 2014 19:45: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: Matthew Kerwin References: <54922C81.4030908@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/C3iiIZoXzX7hF65wRyrgt9R6vVQ Cc: IETF Apps Discuss Subject: [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, 20 Dec 2014 00:45:39 -0000 On 12/17/2014 09:01 PM, Matthew Kerwin wrote: > On 18 December 2014 at 11:23, Sam Ruby >wrote: > > This is NOT an objection, but I will note that > draft-kerwin-file-scheme makes a reference to a document I co-edit: > > https://tools.ietf.org/html/__draft-kerwin-file-scheme-13#__ref-WHATWG-URL > > > I further would like APPSAWG to consider the following as input: > > http://tools.ietf.org/html/__draft-ruby-url-problem-00 > > > ​Yes, the more this can tie in with other efforts (notably​ in the W3C > and WHATWG) the better. If draft-ruby-url-problem eventually ends up > with a BCP we'll definitely do all we can to adhere to it, and even > without, I think the principle is worthy and we'll strive anyway. If > that involves a reference to a new informational RFC, all well and good. Thanks! I'm sure that we can learn much from each other, and the specs we produce will benefit as a result. To start off, I'd like point out one area where there may be some technical issues that you might not be aware of -- and I encourage you to do the same with specs I am working on. So as to not affect the call for adoption, I've changed the subject line. 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 the necessary behavior. I encourage you to explore the following URIs. In particular, I recommend exploring these with the Chrome browser: file://2130706433/foo file://[2001::1]/foo file://ï¼ï¼¸ï½ƒï¼ï¼Žï¼ï¼’５ï¼ï¼Žï¼ï¼‘/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 You may find the following online tool to be handy for exploring cases such as these: https://url.spec.whatwg.org/reference-implementation/liveview.html - Sam Ruby From nobody Sat Dec 20 11:55:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7461A8ADC for ; Sat, 20 Dec 2014 11:55: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 Dzxz7JHkurGG for ; Sat, 20 Dec 2014 11:55:37 -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 ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F4411A1B30 for ; Sat, 20 Dec 2014 11:55:37 -0800 (PST) Received: from DM2PR0201MB0958.namprd02.prod.outlook.com (25.160.216.26) by DM2PR0201MB1006.namprd02.prod.outlook.com (25.160.219.140) with Microsoft SMTP Server (TLS) id 15.1.31.17; Sat, 20 Dec 2014 19:55:36 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0958.namprd02.prod.outlook.com (25.160.216.26) with Microsoft SMTP Server (TLS) id 15.1.31.17; Sat, 20 Dec 2014 19:55: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; Sat, 20 Dec 2014 19:55:31 +0000 From: Larry Masinter To: "Murray S. Kucherawy" , IETF Apps Discuss Thread-Topic: [apps-discuss] Call for Adoption: draft-kerwin-file-scheme Thread-Index: AQHQGhfIlOWNfZCYG0u4zhqMmswUzpyY0uCg Date: Sat, 20 Dec 2014 19:55:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:9:8380:992:3d03:3e2:8556:a1d5] authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB0958;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB0958; x-forefront-prvs: 0431F981D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(107886001)(54206007)(106356001)(105586002)(4396001)(87936001)(21056001)(120916001)(101416001)(33656002)(62966003)(107046002)(2900100001)(2656002)(19580395003)(99396003)(31966008)(76576001)(68736005)(77156002)(122556002)(54356999)(99286002)(40100003)(76176999)(46102003)(74316001)(64706001)(92566001)(230783001)(15975445007)(102836002)(97736003)(20776003)(106116001)(50986999)(86362001)(54606007)(2950100001)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0958; 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-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB1006; X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/n1hQrbf3r79PXMOjPyDawXitIGk 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: Sat, 20 Dec 2014 19:55:39 -0000 PiBUaGlzIG9wZW5zIGEgY2FsbCBmb3IgYWRvcHRpb24gZm9yIGRyYWZ0LWtlcndpbi1maWxlLXNj aGVtZSwgdG8gYmUgcHJvY2Vzc2VkIGJ5IEFQUFNBV0cuwqAgDQoNCkkgZG9uJ3QgdGhpbmsgYXBw cyBhcmVhIHNob3VsZCB0YWtlIHVwIGtlcndpbi1maWxlLXNjaGVtZSBhcyBhbiBpbmRlcGVuZGVu dCB3b3JrIGl0ZW0sIG5vdCBiZWNhdXNlIHRoZSB3b3JrIGlzbid0IGltcG9ydGFudCBidXQgYmVj YXVzZSBhcHBzLWRpc2N1c3MgaXMgdG9vIGNvbmdlc3RlZCB0byBtYW5hZ2UgdGhlIGRpc2N1c3Np b24gKG5vIHJlc3BvbnNlcyB0byBteSBEZWMgOSBjb21tZW50cyBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL2FwcHMtZGlzY3Vzcy9jdXJyZW50L21zZzEzNDYyLmh0bWwgKS4g SW4gZ2VuZXJhbCwgQVBQU0FXRyBzaG91bGRuJ3QgdGFrZSB1cCBVUkwtc2NoZW1lIHBlcm1hbmVu dCByZWdpc3RyYXRpb25zPyBPciBzaG91bGQgaXQ/IFRoaXMgc2hvdWxkIGJlIGFkZHJlc3NlZCBp biB0aGUgc2NoZW1lIHJlZ2lzdHJhdGlvbiBCQ1AuDQoNCkxhcnJ5DQotLQ0KaHR0cDovL2xhcnJ5 Lm1hc2ludGVyLm5ldA0KDQo= From nobody Sat Dec 20 14:09:23 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D3B1A7D82 for ; Sat, 20 Dec 2014 14:09:21 -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 pRi9iBPJm2FM for ; Sat, 20 Dec 2014 14:09:19 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B177B1A710D for ; Sat, 20 Dec 2014 14:09:19 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 98AD722E1FA for ; Sat, 20 Dec 2014 17:09:18 -0500 (EST) Message-ID: <5495F383.6000903@seantek.com> Date: Sat, 20 Dec 2014 14:09: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: <6696385.C9EWBcZ1Pq@scott-latitude-e6320> In-Reply-To: <6696385.C9EWBcZ1Pq@scott-latitude-e6320> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/KyxFLw2FCwv7CSpiWAmLr8Ha7vc 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: Sat, 20 Dec 2014 22:09:22 -0000 On 12/18/2014 6:06 AM, Scott Kitterman wrote: > On Wednesday, December 17, 2014 08:37:34 Murray S. Kucherawy wrote: >> This opens a call for adoption for draft-kerwin-file-scheme, to be >> processed by APPSAWG. There appears to be enough interest in the work= >> given the feedback it's getting, and it appears to fit within our char= ter. >> >> Please indicate your support or objection by replying to this thread. = The >> call will close on January 9, 2015. >> >> -MSK, APPSAWG co-chair > In its current form, the draft has normative references to two non-IETF= > documents that don't have clear licensing terms, specifically MS-DTYP a= nd MS- > NBTE. As nearly as I can determine, these are not covered by the Micro= soft > Open Specification Promise [1]. Given that these are normative referen= ces, I > think it's essential that their IPR status be clear. I don't think it'= s > appropriate on something as fundamental as the file URI scheme to end u= p with a > document that's IPR constrained. > > Before this document is accepted, it should either be reworked to no re= quire > these as normative references or the IPR status of the references shoul= d be > clarified to make it clear that their use is not encumbered (adding the= m to the > OSP would be a great way to do this). This is probably a good non-technical example of why I advocated for the = "local convention" from a technical standpoint (see http://mailarchive.ietf.org/arch/msg/apps-discuss/k80c33MWSWC2lxdGq0YmcrJ= i5Uw ; also echoed in Larry Masinter's second comment http://mailarchive= =2Eietf.org/arch/msg/apps-discuss/NsOYamN15GcMrSV1bBuOrA5XirY). file: should be seen as an "escape hatch" for the (majority of) the strin= g to be processed by an OS-specific filesystem API, with no more than rud= imentary interpolation. Documenting these operating-specific behaviors is all well and good, but = passing normative statements on OS vendors for their own software will no= t get what you want or change the behaviors of these APIs/products. The b= est thing is to say "look to the [OS vendor] documentation for [normative= guidance] on how this is constructed". To pick a non-Microsoft example, consider Apple Mac OS X's handling of fi= le URLs: https://developer.apple.com/library/ios/documentation/FileManagement/Conc= eptual/FileSystemProgrammingGuide/AccessingFilesandDirectories/AccessingF= ilesandDirectories.html The premise that normative documentation by one OS vendor (e.g., Microsof= t) is required to interpret file: for that OS, should not be a barrier to= the file: scheme in general or to an RFC in particular. The right way to= deal with that is to write the RFC in such a way that OS-specific variat= ions are not required for RFC-compliance in the first place. If you want = to write a Linux tool that interprets Microsoft Windows file: URLs, #1 - = why bother? it's not usable; #2 - as the tool author, shouldn't you be lo= oking at Microsoft's documentation anyway, regardless of its licensing te= rms? You want compatibility with actual Windows software, not with some a= rbitrary RFC. -Sean From nobody Sat Dec 20 17:46:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6471C1A00F8 for ; Sat, 20 Dec 2014 17:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_92=0.6, 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 TnV_wFP5GsWq for ; Sat, 20 Dec 2014 17:46:35 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35BDB1A00F7 for ; Sat, 20 Dec 2014 17:46:35 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id ED39922E1FA; Sat, 20 Dec 2014 20:46:33 -0500 (EST) Message-ID: <5496266F.50101@seantek.com> Date: Sat, 20 Dec 2014 17:46:23 -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: Michel Fortin References: <20141217075735.6060.32225.idtracker@ietfa.amsl.com> <549242A8.30207@seantek.com> <76A69E11-0325-4222-A8E6-41324E2DA5C2@michelf.ca> In-Reply-To: <76A69E11-0325-4222-A8E6-41324E2DA5C2@michelf.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/dmC11Y9YWH4RYWDr51bQzR5a3LA Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-04.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, 21 Dec 2014 01:46:37 -0000 On 12/18/2014 8:07 PM, Michel Fortin wrote: > Le 17-d=C3=A9c.-2014 =C3=A0 21:57, Sean Leonard = a =C3=A9crit : >>> http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-04 > Section 2: > > Additionally, implementations > SHOULD record syntax and output-type parameters along with the > Markdown, such as in extended attributes; however, the exact > manner of storage is a local matter > > Looks outdated. Yes--it was missed. It will be addressed/fixed/removed. > 4: Fragment identifiers > > In my opinion there is no point in having such a section. The "general-= purpose" fragment identifiers are basically undefined. Markdown doesn't h= ave identifiers, and variants that implement something like this often do= so in different ways, and sometime they're implicitly generated from tit= le names, footnote numbers, etc, again often in non-compatible ways. > > I'd basically replace the whole section 4 with this two-sentence paragr= aph: "Markdown doesn't define any fragment identifiers, but some variants= do. Which fragment identifiers are available for a given document are va= riant-defined." I thought about this (and also took Graham's comments into=20 consideration). Overall I am leaning towards cutting the section down,=20 but not eliminating it entirely. There should be enough text to provide=20 variant users with guidance that fragment identifiers can be used,=20 without imposing many restrictions. So it will probably be closer to=20 your quote above. > > 4.2: about #line=3Dx > > I can't find any browser supporting this for text/plain. Is this in use= ful anywhere? This is best addressed to the authors and contributors of RFC 5147. I am = not aware of specific deployments. With that said, it is useful (discussed below): > Beside, take note that it's meaningless in any context where the Mark= down text has been interpreted and rendered as something else than a plai= n text document. I am thinking of web-based Markdown editors, among other things.=20 Basically if you go to a web-based Markdown editor like dillinger.io,=20 you can add a fragment to the URI, and the web app will do something.=20 E.g., http://dillinger.io/#installation will jump to the Installation=20 header. I suppose that you could say "hey, that's really a text/html thing!" but = we need to take a slightly more expansive view. A PDF reader implemented = on the client would take the application/pdf data from=20 http://example.com/example.pdf#page=3D5 and jump to the fifth page. A PDF= =20 reader implemented on the server would take=20 http://example.com/example.pdf#page=3D5 and serve a web app in the form o= f=20 a text/html page to the web browser, and then jump to the fifth page. If = the user clicks a "Save to Disk" button in either implementation,=20 they're going to get an application/pdf file on disk. The user=20 experience is the same. Related to this, Graham Klyne said: >> I'm uneasy about the choice of "&" as a parameter separator, as it would = introduce escaping complications if one just wants to copy the fragment=20 into an XML/HTML-based format (which I suggest may be a common=20 scenario). I'd be inclined to use ';' as proposed in=20 http://w3ctag.github.io/packaging-on-the-web/#fragment-identifiers (you=20 could also exploit the syntax described there). (I note that=20 http://tools.ietf.org/html/rfc5147 doesn't allow multiple parameters.) << Part of me wants to simplify this by not discussing parameter separators = (or for that matter, multiple parameters) at all. But then if someone=20 wants to have multiple parameters, it will be much more difficult to get = interoperable agreement on how to separate them. Personally I like &=20 because it is used in HTTP/HTML query strings. I don't find & -> &=20 issues to be salient in the Markdown community, because Markdown has=20 specific rules for interpreting & in URIs and other productions without=20 worrying about XML/HTML escaping. A secure/properly implemented XML/HTML = processor needs to anticipate and deal with & in the query component of=20 URIs anyway, so reusing that in the fragment component does not seem to=20 introduce novel problems. > > > 5: Example: > > Content-Type: text/markdown; charset=3DUTF-8; syntax=3DOriginal; > output-type=3D"application/xhtml+xml" > > Can I say "outdated" again? Yes--that will be fixed. > > > 6: The variant registry > > I still don't know what to think about this. It's good to have a list o= f variants available, but given I don't expect Markdown parser implemente= rs are going to bother registering things there it looks like a fertile g= round for squatting given that first-come first-served policy. Let's see how things go. I doubt that vanity is a strong motivator for=20 putting things in that registry. There is still an infinite number of=20 useful names. The idea is more than anyone "with a need to interoperate" = should be sufficiently motivated to add a registration. Sean From nobody Sun Dec 21 00:47:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F241A0354 for ; Sun, 21 Dec 2014 00:47:03 -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 s0Awjd8Xbycm for ; Sun, 21 Dec 2014 00:47:00 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA601A034F for ; Sun, 21 Dec 2014 00:47:00 -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 530BA22E1F3; Sun, 21 Dec 2014 03:46:57 -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: <54947170.3040200@ninebynine.org> Date: Sun, 21 Dec 2014 00:47:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <586A4911-2795-4EF6-A4E1-6F14A294E5B2@seantek.com> <54947170.3040200@ninebynine.org> To: Graham Klyne X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/MU5-FMIY9m3vkKO7Dgd7TiGRp58 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-text-markdown-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: Sun, 21 Dec 2014 08:47:03 -0000 Hello=97 (Only commenting on things that I did not change in the upcoming = draft-05; all other things were accepted or mostly accepted.) On Dec 19, 2014, at 10:41 AM, Graham Klyne wrote: >=20 > Sect 1.2: "The paradigmatic use case for text/markdown..." doesn't = make sense to me. I'm not sure what you mean by "paradigmatic" here. I mean the model or pattern that is being followed, especially the = conceptual framework from which basic assumptions, ways of thinking, and = methodology can be gleaned. (Which is the definition of = paradigm/paradigmatic.) >=20 > Sect 2, 'charset' parameter. I think some of the commentary (after = the first sentence) here belongs under "encoding considerations=94 I changed =93encoding=94 to =93character set=94 to clarify, but kept it = in the charset parameter. =93Character set=94 technically refers to an abstract set of characters; = a character encoding is the mapping between abstract characters and bits = on the wire. Unicode is (among other things) a character set; UTF-8, = UTF-16LE, and UTF-16BE are some of several encodings to encode = characters in that character set. (It is possible to have a single = encoding usable with multiple character sets, although it=92s a bit = confusing and usually is not what one wants.) Unfortunately the = =93charset=94 parameter conflates the two terms; maybe it should have = been called =93charsetandencoding=94 or some such. Usually in media type registrations, the =93Encoding Considerations=94 = just says something generic like =93text=94 or =93binary=94. I suppose = it could say something like =93gzip works best=94 or =93you will get = better results with quoted-printable than base64 in most cases=94, but I = have never seen character encoding issues discussed in that section. > Section 4.1, 4.2: (As discussed in my response to Michel Fortin, I pared this section = down.) > I'm wary of "The character set for percent-encoded octets SHALL be the = same as the Markdown content, i.e., identified by the charset parameter = or by other contextual means." I'm not even sure that it always makes = sense. The current tendency is to %-encode URIs via UTF-8 encoding of = the underlying characters. In this case, I think it's sufficient that = interpretation of the fragment identifier is dependent on the Markdown = variant used, which I think is pretty much what you already say. >=20 > (Example: consider a variant that is presented to a converter as, say = "Windows-1252", but which is emitted by a converter as UTF-8-encoded = HTML. You have already emphasized Markdown as consisting of characters = not codepoints, so having a URI fragment that is expressed with respect = to code points in the source seems odd to me.) (Take a look at draft-05; I suspect we will revisit this issue.) The key thing here is that the input is marked as Windows-1252, so = without needing to invoke any particular Markdown processor, the MIME = parser can use the input information to understand the fragment. The = fragment is =93addressed=94 to the text/markdown content, not the = text/html content or any other such thing that might have gone through a = Markdown processor. In draft-03, I proposed #o#blahblah (output) and #i#blahblah (input), = which were seen as too complicated (and wrong since # can=92t be used=97I = suppose it should have been =3D instead). This simplified formulation = only looks at input content, and drops the #i# (or #i=3D ) prefix. >=20 > ... >=20 > Sections 4.1, 4.2: >=20 > I think the relationship between these sections is potentially = confusing, and could use some work. >=20 > I'd be inclined to start with a general reference to fragment = identifiers containing named parameters I did=97application/pdf [RFC3778]. :) application/pdf uses & as a = parameter separator. > (which, BTW, conflicts with what you say about character encoding, as = the encoding of the '=3D' must be independent of the content encoding -- = I know it's contrived, but suppose the Markdown is EBCDIC-encoded). It=92s a little complicated=85RFC 3986 actually says that US-ASCII codes = are to be used for the US-ASCII range. If anything, the conflict is a = broader problem with URIs than with this particular proposal. Anyway, we = could go into this in detail for cases where the character set/encoding = is not strictly aligned with US-ASCII in 00h-7Fh, but for the = text/markdown spec I just tried to say that =3D and %?? (representing =3D = ) have distinct reserved and unreserved meanings=97the precise value for = %?? is not this spec=92s job to say. (It=92s RFC 3986=92s job.) > If you introduce this style of fragment identifier, I think something = like "id=3D" could be defined to refer to whatever maps to HTML id=3D = values in the variant used. As discussed above, that was the original idea behind things like = #o#blahblah, #l#blahblah, and #ldef#blahblah in draft-03. Compared to = that syntax, I think it makes more sense to align Markdown-to-HTML = anchors with the same syntax that text/html itself uses=85which is no = prefix. Overall draft-04 and forthcoming -05 exploit the property that certain = characters have different meanings when percent-encoded, which I think = is perfectly reasonable (and nifty). >=20 >=20 > I think the character set for the other fields should be checked with = IANA if they are to maintain the registry. Usually, in my experience, = as registration templates often appear in RFCs, just ASCII characters = are used. I checked. RFC 5226 Section 4.2: Documents that create a new namespace (or modify the definition of an existing space) and that expect IANA to play a role in maintaining that space (e.g., serving as a repository for registered values) MUST provide clear instructions on details of the namespace. In particular, instructions MUST include: =85 4) The size, format, and syntax of registry entries. When creating a new name/number space, authors must describe any technical requirements on registry (and sub-registry) values (e.g., valid ranges for integers, length limitations on strings, etc.) as well as the exact format in which registry values should be displayed. For number assignments, one should specify whether values are to be recorded in decimal, hexadecimal, or some other format. For strings, the encoding format should be specified (e.g., ASCII, UTF8, etc.). Authors should also clearly specify what fields to record in the registry. So, that=92s that=85UTF-8 is okay. Sean= From nobody Mon Dec 22 02:13:52 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C571A033A for ; Mon, 22 Dec 2014 02:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.098 X-Spam-Level: ** X-Spam-Status: No, score=2.098 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 grxmp02KMzjM for ; Mon, 22 Dec 2014 02:13:46 -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 164CF1A8A1F for ; Mon, 22 Dec 2014 02:13:27 -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 9E35C32E50F for ; Mon, 22 Dec 2014 19:12: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 587c_8a7c_07a53db7_6cb0_4bc1_86db_ecffe27988c3; Mon, 22 Dec 2014 19:12:40 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id CD758BF4E7 for ; Mon, 22 Dec 2014 19:12:40 +0900 (JST) Message-ID: <5497EE9A.4030706@it.aoyama.ac.jp> Date: Mon, 22 Dec 2014 19:12:42 +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: Apps Discuss References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/QAQu0zM3DS7nmyA2tC84Pf5R_kQ Subject: Re: [apps-discuss] URL definitions and draft-ruby-url-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 22 Dec 2014 10:13:49 -0000 I have the following comments on draft-ruby-url-problem-00: Overall: I think it's good to have such a document because a lot of people keep mentioning problems related to URIs/IRIs/URLs but often without enough background or in fragments that then get forgotten. If this document can clearly call out these problems, then it will be very valuable. This is separate from whether this document should eventually be published; it could be published after things have settled down, or just be abandoned. Abstract: I'd make sure that URI and IRI are also mentioned, because they clearly are the terminology used widely in the IETF. Details: 1. Brief History of URL standards (http://tools.ietf.org/html/draft-ruby-url-problem-00#section-1) "Although it was quickly determined that it was desirable to allow non-ASCII characters, shoehorning utf-8 into ASCII-only systems was unacceptable; at the time Unicode was not so widely deployed." I'd prefer a less emotional word than "shoehorning", and a more technical word than "unacceptable". Also, UTF-8 doesn't need to be mentioned here, what matters is Unicode. Also, it would be good to know what "at the time" refers to. If it refers to 1994, the statement about Unicode is certainly true, but for that date, the statement "it was quickly determined that it was desirable to allow non-ASCII characters" is clearly false. Actually, even in 2005, and even after that, there were/are people who claim that IRIs should be just "user interface elements", or that ASCII only would be okay. Otherwise, the introduction in RFC 3987 (see http://tools.ietf.org/html/rfc3987#section-1.1) could have been a lot shorter. "The IRI-to-URI transformation specified in [RFC3987] had options; it wasn't a deterministic path." If this is seen as relevant, please move it to section 3, because it's way too small a detail to keep in a section entitled "Brief History of URL standards". Then please explain what the options are, and what the problems are that you see with these options. (Please note that the choice between using ToASCII and UTF-8->%-encode in the conversion, which may be one of the options you refer to, stems from the fact that RFC 3986 allows both %-encoding and Punycode, and therefore if this is a problem, this should be mentioned for RFC 3986.) "The URI-to-IRI transformation was also heuristic, since there was no guarantee that %xx-encoded bytes in the URI were actually meant to be %xx percent-hex-encoded bytes of a utf8 encoding of a Unicode string." Again, if this is seen as relevant, please move it to section 3, because it's way too small a detail to keep in a section entitled "Brief History of URL standards". Also, please change "utf8" to "UTF-8". [As far as I'm aware, this isn't a problem; although it's a heuristic, it's one that works extremely well, and one that browsers use all the time.] "... IDNA specs ([RFC3490] and [RFC5895]) did not fully addressed IRI processing." It would be good to know what this is about. UTS-46 is about how to bridge the differences between IDNA2003 and IDNA2008. 2. Current Organizations and Specs in Development (http://tools.ietf.org/html/draft-ruby-url-problem-00#section-2) "Documents sitting needing update, abandoned now, are three drafts ([iri-3987bis], [iri-comparison], and [iri-bidi-guidelines]), which were originally intended to obsolete [RFC3987]." The problems with Bidi IRIs should definitely be mentioned in section 3. They are well known among experts. What's not known is the solution for these problems. The solution given in RFC 3987 has some obvious errors (how to handle combining marks); it's general approach also probably can be improved on, but it's not sure why. Removing the bidi issues, the problem with the drafts as currently abandoned is that besides the very necessary work of fixing errors,..., there was also an attempt to rewrite some of the more general text. My conclusion from that exercise has been that this isn't productive at all. If I restart on these documents, I'll go back to the original RFC 3987 and integrate errata. Based on this experience, I also strongly suggest that in the event of an attempt to update RFC 3986, updates are done on a strict "need-to" base, rather than attempting to write everything from scratch. "This work is based on [UTS-46], and is intented to obsolete both [RFC3986] and [RFC3987]." s/intented/intended/ UTS-46 doesn't fully cover [RFC3986] and [RFC3987], so I'd suggest splitting the sentence to avoid potential misunderstandings. I have read the phrase "is intended to obsolete both [RFC3986] and [RFC3987]", but in particular in the document at hand, it would be good to say what that's actually supposed to mean. Very specifically, a non-IETF document cannot formally obsolete an IETF document. If (a) the intent is to bring this document to a level of completeness and consensus that would allow the IETF to obsolete the above RFCs with a stump RFC, then it would be good to say so explicitly. On the other hand, if (b) the intent is to allow browser makers and browser-related specs to not have to consult these RFCs, that should be said explicitly. [My current impression is that the goal is supposed to be close to (a), but what's been done is mostly close to (b).] 4. Outline of Potential Solution s/outout/output/ "Other than responsing to any feedback that may be provided, no changes to any Unicode Consortium product is required." My understanding is that the Unicode Consortium plans to adapt UTS-46 as registries (e.g. DENIC) move from IDNA2003 to IDNA2008. So this sentence is not necessarily correct. Regards, Martin. On 2014/12/19 01:20, Paul Hoffman wrote: > This seems like an important document for us to look at, and possibly adopt. Section 3 is pretty scary, and section 4 seems like a very reasonable solution. > > --Paul Hoffman > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Mon Dec 22 03:03:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BC31A8A64 for ; Mon, 22 Dec 2014 03:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.098 X-Spam-Level: ** X-Spam-Status: No, score=2.098 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 QSuV__-QnIq7 for ; Mon, 22 Dec 2014 03:03:12 -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 1A8C91A037B for ; Mon, 22 Dec 2014 03:03:12 -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 58F7332E57C; Mon, 22 Dec 2014 20:02:27 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 587c_90ab_c5a70fd0_fa4c_4759_b7aa_bc578afcde1f; Mon, 22 Dec 2014 20:02:27 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 6F472BF539; Mon, 22 Dec 2014 20:02:26 +0900 (JST) Message-ID: <5497FA44.8090704@it.aoyama.ac.jp> Date: Mon, 22 Dec 2014 20:02:28 +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 , Bjoern Hoehrmann References: <00o89a147re95aor21u3l9a7aarrhg0vts@hive.bjoern.hoehrmann.de> <549480BD.6080309@intertwingly.net> In-Reply-To: <549480BD.6080309@intertwingly.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/jNyxi0XtIE_L-heCj8_L9_2usr4 Cc: Paul Hoffman , Apps Discuss Subject: Re: [apps-discuss] URL definitions and draft-ruby-url-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 22 Dec 2014 11:03:17 -0000 Hello Sam, On 2014/12/20 04:47, Sam Ruby wrote: > On 12/19/2014 01:41 PM, Bjoern Hoehrmann wrote: >> Section 3 has >> o Nomenclature: over the years, a number of different sets of >> terminology has been used. URL / URI / IRI is not the only >> difference. [tantek-slice] chronicles a number of differences. >> >> The latter refers to differences among APIs for manipulating resource >> identifiers. I do not think that is a problem and does not need solvin= g. > > Can I ask why not? > > To be clear, I'm not suggesting that everybody adopt the same terms. I > am suggesting that somewhere we document what terms are in use and how > they map. Good. If that's the case, can you make sure the document says so?=20 Otherwise, many people will interpret it the way Bj=C3=B6rn did. On top of that, doesn't Tantek's blog post already do that? (except for=20 some newer libraries, but we could ask him to add these) >> o Parameterization: standards in this area need to define such >> matters as normalization forms and values for parameters such a= s >> UseSTD3ASCIIRules. >> >> Where the relevant standards allow implementations to choose options, = it >> is usually because there are good reasons to do so. Implementers ought >> to document their choices properly, and it is a good thing when simila= r >> implementations make the same choices, it might even be useful to have= a >> specification saying "Web browsers must use these options: A, B, C", b= ut >> that would just be a matter of doing it. So I am not sure what problem >> needs solving in this regard. > > First, it is not just web browsers. It is runtime libraries that > accompany various programming languages. It is code embedded in word > processors and web servers. I don't believe that having the URLs mean > different things based on the context is in any body's best interests. > > At a minimum, we should consider clearly documenting the set of URLs > that are may be interpreted differently in different contexts. Perhaps > we should identify those URLs as non-conforming. > > However, that's not enough. Consider ICANN approved non-ASCII domain > names. Different RFC 3986 compliant libraries handle https URLs with > such hostnames differently. We can't simply tell people to avoid such. Is that specific to httpS? Is that security related? >> o Interoperability: even after accounting for the above, there is= a >> demonstrable lack of interoperability across popular libraries = and >> browsers. [whatwg-interop] identifies a number of such >> differences. >> >> There are different classes of problems in this regard, e.g. there may >> be existing requirements that are widely ignored, there may be ambiguo= us >> requirements interpreted differently across implementations, there may >> be implementation-defined behavior that varies across implementations = in >> a harmful manner, or there may be widely deployed behavior where furth= er >> standardisation might be useful, to mention a few. I think it would be >> helpful to discuss these classes of problems separately. > > I agree! To seed the discussion, I offer the following web page with a > number of interesting test cases: > > https://url.spec.whatwg.org/interop/test-results/ > > Feel free to propose additional test cases, suggest categorizations, or > changes to either specs or to libraries, or even additional libraries > that should be included. I don't see Ruby (the programming language). I see addressable, and=20 there's a Ruby Gem by that name (http://rubygems.org/gems/addressable),=20 but it would be good to have the builtin functionality, too. Also, on that page, it would be helpful to have a column with the result=20 that was tested against. Also, I don't see any true IRIs. The wide-character digits are a very=20 special case. > One thing that is important to recognize is that every modern > programming language is going to have a URI or URL parse function, > method, subroutine, or whatever. While it may make sense to allow new > schemes to impose additional validity requirements specific to their > scheme or additional semantics, it is in everybody's best interests if > we define a standard way in which URLs which make use of unknown URL > schemes are to be parsed. Yes, definitely. That's the whole idea behind the "generic" in RFC=20 3986's title. > Note: I am *NOT* suggesting that what currently is in the WHATWG URL > Living Standard is that definition. I think we need something a bit > closer to what RFC 3986 defines. That sounds great. > My best guess at this moment is that RFC 3987 needs to be retired and > work needs to start on a RFC 3986bis, Can you explain why you are making this difference between RFC 3986 and=20 3987? As one of the coauthors of RFC 3987, I'm very familiar with its=20 shortcomings, but I don't know of any that couldn't be fixed with an upda= te. > and that probably needs a new > Working Group. And that needs the discussion we are currently having t= o > happen. RFC 3986/3987 where done without a WG, but these days, there is very=20 little the IETF does without a WG. In that sense, I agree. On the other hand, the experience with the IRI WG has shown that trying=20 to pretend urgency and form a WG before some serious draft work may not=20 work for a topic where (as I said in a previous mail) interest is spread=20 wide but thin. > I will say that I'm willing to work with anybody, anywhere. If work on > a RFC 3986bis starts, I will contribute. > > I also am not looking to make this somebody else's problem. If it mean= s > I need to step up to be that editor, I will do that too. And in the > process, I will actively encourage others to contribute, and by that I > mean GitHub pull requests. > > But I will also say that while we should be having the high level > discussion at this time and in parallel to the technical discussions > about how various classes of input strings should be parsed, it really > is the latter (parser) discussion that we should be doing the deep dive= on. > > Once we have a starter set list of proposed changes, we can circle back > and determine whether a set of errata is sufficient or if the overhead > of an entire Working Group is required. > > However, that is just my preference. Should you be interested in > suggesting changes to draft-ruby-url-problem, I encourage pull requests > for that too. Julian Reschke has already submitted a few. You could b= e > next! [Sorry, I prefer to comment in email, because then people can follow the=20 discussion. I hope you'll take this input, too. On the other hand, if=20 you prefer github, I'd indicate that in=20 http://tools.ietf.org/html/draft-ruby-url-problem-00.] Regards, Martin. From nobody Mon Dec 22 04:24:09 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5871A8A7C for ; Mon, 22 Dec 2014 04:24:00 -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, 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 c_CWtWARyeIR for ; Mon, 22 Dec 2014 04:23:58 -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 49A771A8A64 for ; Mon, 22 Dec 2014 04:23:58 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:47041] helo=rubix) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 8A/C8-27060-C5D08945; Mon, 22 Dec 2014 12:23: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 C40DA140D6C; Mon, 22 Dec 2014 07:23:55 -0500 (EST) Message-ID: <54980D5B.6000506@intertwingly.net> Date: Mon, 22 Dec 2014 07:23:55 -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: =?windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= , Apps Discuss References: <5497EE9A.4030706@it.aoyama.ac.jp> In-Reply-To: <5497EE9A.4030706@it.aoyama.ac.jp> Content-Type: text/plain; charset=windows-1252; 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/E356iOSsO4lyxO3-CHHloNoMKHg Subject: Re: [apps-discuss] URL definitions and draft-ruby-url-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 22 Dec 2014 12:24:02 -0000 On 12/22/2014 05:12 AM, "Martin J. Dürst" wrote: > I have the following comments on draft-ruby-url-problem-00: > > Overall: I think it's good to have such a document because a lot of > people keep mentioning problems related to URIs/IRIs/URLs but often > without enough background or in fragments that then get forgotten. If > this document can clearly call out these problems, then it will be very > valuable. This is separate from whether this document should eventually > be published; it could be published after things have settled down, or > just be abandoned. Agreed. I also believe I agree with pretty much all of the below, and feel it is valuable. After all, the current draft is the product of a Sunday afternoon's work based largely on a blog post that Larry wrote over three months ago. Some of the feedback you provide is immediately actionable (example: s/intented/intended/). Some of it requires somebody to actually make a proposal (example: less emotional word than "shoehorning"). Some of it requires more research (example: this sentence is not necessarily correct.) Ultimately these items should result in updates to the draft and/or issues being recorded. I'd encourage you to make pull requests and/or directly open issues. If that doesn't happen, at a minimum, I will address the first set. - Sam Ruby > Abstract: I'd make sure that URI and IRI are also mentioned, because > they clearly are the terminology used widely in the IETF. > > > > Details: > > 1. Brief History of URL standards > (http://tools.ietf.org/html/draft-ruby-url-problem-00#section-1) > > "Although it was quickly determined that it was desirable to allow > non-ASCII characters, shoehorning utf-8 into ASCII-only systems was > unacceptable; at the time Unicode was not so widely deployed." > > I'd prefer a less emotional word than "shoehorning", and a more > technical word than "unacceptable". Also, UTF-8 doesn't need to be > mentioned here, what matters is Unicode. > > Also, it would be good to know what "at the time" refers to. If it > refers to 1994, the statement about Unicode is certainly true, but for > that date, the statement "it was quickly determined that it was > desirable to allow non-ASCII characters" is clearly false. Actually, > even in 2005, and even after that, there were/are people who claim that > IRIs should be just "user interface elements", or that ASCII only would > be okay. Otherwise, the introduction in RFC 3987 (see > http://tools.ietf.org/html/rfc3987#section-1.1) could have been a lot > shorter. > > > "The IRI-to-URI transformation specified in [RFC3987] had options; it > wasn't a deterministic path." > > If this is seen as relevant, please move it to section 3, because it's > way too small a detail to keep in a section entitled "Brief History of > URL standards". Then please explain what the options are, and what the > problems are that you see with these options. > (Please note that the choice between using ToASCII and UTF-8->%-encode > in the conversion, which may be one of the options you refer to, stems > from the fact that RFC 3986 allows both %-encoding and Punycode, and > therefore if this is a problem, this should be mentioned for RFC 3986.) > > > "The URI-to-IRI transformation was also heuristic, since there was no > guarantee that %xx-encoded bytes in the URI were actually meant to be > %xx percent-hex-encoded bytes of a utf8 encoding of a Unicode string." > > Again, if this is seen as relevant, please move it to section 3, because > it's way too small a detail to keep in a section entitled "Brief History > of URL standards". Also, please change "utf8" to "UTF-8". [As far as I'm > aware, this isn't a problem; although it's a heuristic, it's one that > works extremely well, and one that browsers use all the time.] > > > "... IDNA specs ([RFC3490] and [RFC5895]) did not fully addressed IRI > processing." > > It would be good to know what this is about. UTS-46 is about how to > bridge the differences between IDNA2003 and IDNA2008. > > > 2. Current Organizations and Specs in Development > (http://tools.ietf.org/html/draft-ruby-url-problem-00#section-2) > > "Documents sitting needing update, abandoned now, are three drafts > ([iri-3987bis], [iri-comparison], and [iri-bidi-guidelines]), which were > originally intended to obsolete [RFC3987]." > > The problems with Bidi IRIs should definitely be mentioned in section 3. > They are well known among experts. What's not known is the solution for > these problems. The solution given in RFC 3987 has some obvious errors > (how to handle combining marks); it's general approach also probably can > be improved on, but it's not sure why. > > Removing the bidi issues, the problem with the drafts as currently > abandoned is that besides the very necessary work of fixing errors,..., > there was also an attempt to rewrite some of the more general text. My > conclusion from that exercise has been that this isn't productive at > all. If I restart on these documents, I'll go back to the original RFC > 3987 and integrate errata. Based on this experience, I also strongly > suggest that in the event of an attempt to update RFC 3986, updates are > done on a strict "need-to" base, rather than attempting to write > everything from scratch. > > > "This work is based on [UTS-46], and is intented to obsolete both > [RFC3986] and [RFC3987]." > > s/intented/intended/ > > UTS-46 doesn't fully cover [RFC3986] and [RFC3987], so I'd suggest > splitting the sentence to avoid potential misunderstandings. > > I have read the phrase "is intended to obsolete both [RFC3986] and > [RFC3987]", but in particular in the document at hand, it would be good > to say what that's actually supposed to mean. Very specifically, a > non-IETF document cannot formally obsolete an IETF document. If (a) the > intent is to bring this document to a level of completeness and > consensus that would allow the IETF to obsolete the above RFCs with a > stump RFC, then it would be good to say so explicitly. On the other > hand, if (b) the intent is to allow browser makers and browser-related > specs to not have to consult these RFCs, that should be said explicitly. > [My current impression is that the goal is supposed to be close to (a), > but what's been done is mostly close to (b).] > > > 4. Outline of Potential Solution > > s/outout/output/ > > "Other than responsing to any feedback that may be provided, no changes > to any Unicode Consortium product is required." > > My understanding is that the Unicode Consortium plans to adapt UTS-46 as > registries (e.g. DENIC) move from IDNA2003 to IDNA2008. So this sentence > is not necessarily correct. > > > Regards, Martin. > > > On 2014/12/19 01:20, Paul Hoffman wrote: >> This seems like an important document for us to look at, and possibly >> adopt. Section 3 is pretty scary, and section 4 seems like a very >> reasonable solution. >> >> --Paul Hoffman >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Mon Dec 22 04:55:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AC41A8AD9 for ; Mon, 22 Dec 2014 04:55:26 -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, 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 qfOTyqTPuUJ2 for ; Mon, 22 Dec 2014 04:55:24 -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 DFEBD1A8AEA for ; Mon, 22 Dec 2014 04:55:10 -0800 (PST) Received: from [98.27.51.253] ([98.27.51.253:52643] helo=rubix) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 77/D1-32383-DA418945; Mon, 22 Dec 2014 12:55: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 7858E140AC1; Mon, 22 Dec 2014 07:55:08 -0500 (EST) Message-ID: <549814AC.4050404@intertwingly.net> Date: Mon, 22 Dec 2014 07:55: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: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Bjoern Hoehrmann References: <00o89a147re95aor21u3l9a7aarrhg0vts@hive.bjoern.hoehrmann.de> <549480BD.6080309@intertwingly.net> <5497FA44.8090704@it.aoyama.ac.jp> In-Reply-To: <5497FA44.8090704@it.aoyama.ac.jp> 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/xR6Vdanume8nyOgRzfxs27Oz3hY Cc: Paul Hoffman , Apps Discuss Subject: Re: [apps-discuss] URL definitions and draft-ruby-url-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 22 Dec 2014 12:55:26 -0000 On 12/22/2014 06:02 AM, "Martin J. Dürst" wrote: > Hello Sam, > On 2014/12/20 04:47, Sam Ruby wrote: >> On 12/19/2014 01:41 PM, Bjoern Hoehrmann wrote: > >>> Section 3 has > >>> o Nomenclature: over the years, a number of different sets of >>> terminology has been used. URL / URI / IRI is not the only >>> difference. [tantek-slice] chronicles a number of differences. >>> >>> The latter refers to differences among APIs for manipulating resource >>> identifiers. I do not think that is a problem and does not need solving. >> >> Can I ask why not? >> >> To be clear, I'm not suggesting that everybody adopt the same terms. I >> am suggesting that somewhere we document what terms are in use and how >> they map. > > Good. If that's the case, can you make sure the document says so? > Otherwise, many people will interpret it the way Björn did. > > On top of that, doesn't Tantek's blog post already do that? (except for > some newer libraries, but we could ask him to add these) I've taken a stab at updating the draft: >>> o Parameterization: standards in this area need to define such >>> matters as normalization forms and values for parameters such as >>> UseSTD3ASCIIRules. >>> >>> Where the relevant standards allow implementations to choose options, it >>> is usually because there are good reasons to do so. Implementers ought >>> to document their choices properly, and it is a good thing when similar >>> implementations make the same choices, it might even be useful to have a >>> specification saying "Web browsers must use these options: A, B, C", but >>> that would just be a matter of doing it. So I am not sure what problem >>> needs solving in this regard. >> >> First, it is not just web browsers. It is runtime libraries that >> accompany various programming languages. It is code embedded in word >> processors and web servers. I don't believe that having the URLs mean >> different things based on the context is in any body's best interests. >> >> At a minimum, we should consider clearly documenting the set of URLs >> that are may be interpreted differently in different contexts. Perhaps >> we should identify those URLs as non-conforming. >> >> However, that's not enough. Consider ICANN approved non-ASCII domain >> names. Different RFC 3986 compliant libraries handle https URLs with >> such hostnames differently. We can't simply tell people to avoid such. > > Is that specific to httpS? Is that security related? It applies to any scheme that includes a hostname, including file. >>> o Interoperability: even after accounting for the above, there is a >>> demonstrable lack of interoperability across popular libraries >>> and >>> browsers. [whatwg-interop] identifies a number of such >>> differences. >>> >>> There are different classes of problems in this regard, e.g. there may >>> be existing requirements that are widely ignored, there may be ambiguous >>> requirements interpreted differently across implementations, there may >>> be implementation-defined behavior that varies across implementations in >>> a harmful manner, or there may be widely deployed behavior where further >>> standardisation might be useful, to mention a few. I think it would be >>> helpful to discuss these classes of problems separately. >> >> I agree! To seed the discussion, I offer the following web page with a >> number of interesting test cases: >> >> https://url.spec.whatwg.org/interop/test-results/ >> >> Feel free to propose additional test cases, suggest categorizations, or >> changes to either specs or to libraries, or even additional libraries >> that should be included. > > I don't see Ruby (the programming language). I see addressable, and > there's a Ruby Gem by that name (http://rubygems.org/gems/addressable), > but it would be good to have the builtin functionality, too. Such would not be difficult to add. At the moment, my focus has been on libraries that are actively updated and/or are advertised as spec compliant. If adding the Ruby library interests you, can I ask that you help with the capture of the data? The following is already pretty close to what I would need: https://github.com/webspecs/url/blob/develop/evaluate/testaddressable.rb The test data used by the program can be found here: https://url.spec.whatwg.org/interop/urltestdata.json > Also, on that page, it would be helpful to have a column with the result > that was tested against. The table is pretty wide, but I could certainly add a checkboxes that hide or show specific columns. Just so I am clear on what it is that you are proposing: you would like to see a column that includes the value for "href" for the selected baseline? Probably after the column titled "Base" and before the column titled "User Agents with differences"? > Also, I don't see any true IRIs. The wide-character digits are a very > special case. I encourage you to propose specific test cases. The master source for test cases across these efforts is here: https://github.com/w3c/web-platform-tests/blob/master/url/urltestdata.txt >> One thing that is important to recognize is that every modern >> programming language is going to have a URI or URL parse function, >> method, subroutine, or whatever. While it may make sense to allow new >> schemes to impose additional validity requirements specific to their >> scheme or additional semantics, it is in everybody's best interests if >> we define a standard way in which URLs which make use of unknown URL >> schemes are to be parsed. > > Yes, definitely. That's the whole idea behind the "generic" in RFC > 3986's title. > >> Note: I am *NOT* suggesting that what currently is in the WHATWG URL >> Living Standard is that definition. I think we need something a bit >> closer to what RFC 3986 defines. > > That sounds great. > >> My best guess at this moment is that RFC 3987 needs to be retired and >> work needs to start on a RFC 3986bis, > > Can you explain why you are making this difference between RFC 3986 and > 3987? As one of the coauthors of RFC 3987, I'm very familiar with its > shortcomings, but I don't know of any that couldn't be fixed with an > update. You may indeed be better informed than I am on this subject. Your guess, therefore, may be different. >> and that probably needs a new >> Working Group. And that needs the discussion we are currently having to >> happen. > > RFC 3986/3987 where done without a WG, but these days, there is very > little the IETF does without a WG. In that sense, I agree. > > On the other hand, the experience with the IRI WG has shown that trying > to pretend urgency and form a WG before some serious draft work may not > work for a topic where (as I said in a previous mail) interest is spread > wide but thin. There is a bit of a chicken and egg problem here. I'm actively updating the WHATWG URL document, attempting to resolve the differences found in the test-results mentioned above. If those changes can be done in RFC 3986 and/or RFC 3987, and the WHATWG URL document could reference the results, I'll do that. If there are no plans to update those RFCs, then I see the WHATWG URL document continuing on its current path. >> I will say that I'm willing to work with anybody, anywhere. If work on >> a RFC 3986bis starts, I will contribute. >> >> I also am not looking to make this somebody else's problem. If it means >> I need to step up to be that editor, I will do that too. And in the >> process, I will actively encourage others to contribute, and by that I >> mean GitHub pull requests. >> >> But I will also say that while we should be having the high level >> discussion at this time and in parallel to the technical discussions >> about how various classes of input strings should be parsed, it really >> is the latter (parser) discussion that we should be doing the deep >> dive on. >> >> Once we have a starter set list of proposed changes, we can circle back >> and determine whether a set of errata is sufficient or if the overhead >> of an entire Working Group is required. >> >> However, that is just my preference. Should you be interested in >> suggesting changes to draft-ruby-url-problem, I encourage pull requests >> for that too. Julian Reschke has already submitted a few. You could be >> next! > > [Sorry, I prefer to comment in email, because then people can follow the > discussion. I hope you'll take this input, too. On the other hand, if > you prefer github, I'd indicate that in > http://tools.ietf.org/html/draft-ruby-url-problem-00.] These do not need to be mutually exclusive options. Participating exclusively via email is not a problem. I'd encourage concrete suggestions. As an example, I'm not sure how to deal with comments like "I don't see any true IRIs.". By contrast, I very much do know how to deal with pull requests that propose specific changes/additions/deletions. > Regards, Martin. - Sam Ruby From nobody Mon Dec 22 09:36:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F381A8F45 for ; Mon, 22 Dec 2014 09:36:21 -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 VEuS-E9xdp9Q for ; Mon, 22 Dec 2014 09:36:20 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0681.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::681]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6189B1A1B1B for ; Mon, 22 Dec 2014 09:36:19 -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; Mon, 22 Dec 2014 17:35:56 +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; Mon, 22 Dec 2014 17:35:56 +0000 From: Larry Masinter To: Sam Ruby , =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Bjoern Hoehrmann Thread-Topic: [apps-discuss] URL definitions and draft-ruby-url-problem Thread-Index: AQHQGt6YHn3bg9V4TUaew7MJcX0/nJyXQPAAgAASeYCABCRmAIAAH3oAgABMNgA= Date: Mon, 22 Dec 2014 17:35:56 +0000 Message-ID: References: <00o89a147re95aor21u3l9a7aarrhg0vts@hive.bjoern.hoehrmann.de> <549480BD.6080309@intertwingly.net> <5497FA44.8090704@it.aoyama.ac.jp> <549814AC.4050404@intertwingly.net> In-Reply-To: <549814AC.4050404@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:858:47ef:4efa:5126] authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB0957; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB0957; x-forefront-prvs: 0433DB2766 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(20776003)(64706001)(21056001)(93886004)(87936001)(97736003)(230783001)(558084003)(31966008)(122556002)(2656002)(101416001)(15188555004)(54606007)(99396003)(120916001)(50986999)(46102003)(4396001)(54356999)(76176999)(54206007)(92566001)(107046002)(86362001)(33656002)(40100003)(19580395003)(106116001)(105586002)(99286002)(76576001)(2950100001)(15975445007)(102836002)(62966003)(106356001)(2900100001)(68736005)(74316001)(77156002)(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: 22 Dec 2014 17:35:56.3085 (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/mEgtSZcaz8pycRu-EykLFZwTVEo Cc: Paul Hoffman , Apps Discuss Subject: Re: [apps-discuss] URL definitions and draft-ruby-url-problem X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 22 Dec 2014 17:36:22 -0000 RllJDQoNClNvbWUgY29tbWVudHMNCmh0dHA6Ly9saXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGlj L3d3dy1hcmNoaXZlLzIwMTREZWMvMDAwNC5odG1sDQpJJ2xsIGVpdGhlciB1cGRhdGUgdGhlIGRv Y3VtZW50IG9yIGF0IGxlYXN0IHN1Ym1pdCB0aGVzZSBhcyBpc3N1ZXMuDQoNCk5vdGUgYWxzbyBj b250aW51ZWQgZGlzY3Vzc2lvbiBvZiBbdXJsXSBpbiBodHRwOi8vbGlzdHMudzMub3JnL0FyY2hp dmVzL1B1YmxpYy9wdWJsaWMtaWV0Zi13M2MvMjAxNERlYy8NCg0K From nobody Mon Dec 22 15:01:53 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052DA1A6FF1; Mon, 22 Dec 2014 15: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] 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 5WCjXWst4h1x; Mon, 22 Dec 2014 15:01:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0641A88B7; Mon, 22 Dec 2014 15:01:49 -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 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141222230149.31980.3522.idtracker@ietfa.amsl.com> Date: Mon, 22 Dec 2014 15:01:49 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/DgCLmIY1Nsp7G-anoLa3QkWpd0s Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-05.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, 22 Dec 2014 23:01:52 -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 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-text-markdown-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 22 15:21:39 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1B91A6FFC for ; Mon, 22 Dec 2014 15:21:37 -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 nCvsYsEa1ql9 for ; Mon, 22 Dec 2014 15:21:35 -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 787631A6FF1 for ; Mon, 22 Dec 2014 15:21:35 -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 3916122E262 for ; Mon, 22 Dec 2014 18:21:33 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <20141222230149.31980.3522.idtracker@ietfa.amsl.com> Date: Mon, 22 Dec 2014 15:21:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141222230149.31980.3522.idtracker@ietfa.amsl.com> To: IETF Apps Discuss X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/t5_O7PtcncUb0tR0r4MLmo_ddpA 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: Mon, 22 Dec 2014 23:21:37 -0000 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: >=20 > 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. >=20 > Title : The text/markdown Media Type > Author : Sean Leonard > Filename : draft-ietf-appsawg-text-markdown-05.txt > Pages : 14 > Date : 2014-12-22 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-text-markdown-05 >=20 From nobody Wed Dec 24 11:47:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA131A1A6C for ; Wed, 24 Dec 2014 11:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.963 X-Spam-Level: *** X-Spam-Status: No, score=3.963 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MANGLED_TOOL=2.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 3Lh7VG4G5cZV for ; Wed, 24 Dec 2014 11:47:38 -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 2E9F81A1A69 for ; Wed, 24 Dec 2014 11:47:37 -0800 (PST) Received: (qmail 26230 invoked from network); 24 Dec 2014 19:47:36 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 24 Dec 2014 19:47:36 -0000 Date: 24 Dec 2014 19:47:14 -0000 Message-ID: <20141224194714.27569.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: http://mailarchive.ietf.org/arch/msg/apps-discuss/fAvHIjyV69BOpe_6tZjKjObHxqw Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7001 (4201) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Dec 2014 19:47:39 -0000 >I received it but given the November and December holidays I had not >followed up on it since it didn't seem to be an urgent matter. > >I agree with John's synopsis upthread, and will reply in more detail ASAP. So what should we do about this? I'm thinking that the gaps are large enough that it'd be worth doing a new revision that includes the missing stuff, replacing 7001. R's, John PS: Yes. I'll help. From nobody Wed Dec 24 15:25:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0C11A1EFC for ; Wed, 24 Dec 2014 15:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 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, MANGLED_TOOL=2.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 PrT0D3Yb5jqj for ; Wed, 24 Dec 2014 15:25:34 -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 59B9B1A1F16 for ; Wed, 24 Dec 2014 15:25:34 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id em10so14511118wid.5 for ; Wed, 24 Dec 2014 15:25:33 -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=jbjpQaiVnWSPPGVIBf/ARGqiPQD/YKFwr4g5MOXFJNM=; b=PkKCTXVv2KMWz27q1+nmfb88vaLIzhpuVWoIwVKUAkfaa4jhCnpFC8Ja6HMxwfjSRN f4dNZOJxpUUS8tTKCVM96F/RAwUHZidGK8vhE8JD9kdZEEfhUPqKcb539hHg6omgzUSG mjz137YwxdwFOXDErn8FaHG7IDuCrciTx6ob2T1cWc4tVIhDmUQrT2Pos8izlYsggaCi 4QNKyE0+br9FwmxDtLdMgEbpkBAvKPRVBkFVmj8YyEGj9vGZium903T1+NAcuWXQBJd2 cxaon79cSuEKPuj8gt+C1EZfIsLqfZ6LTaQjXkJZjA4atRR/I5HRfHOWj664fV7y+mMF 5zDg== MIME-Version: 1.0 X-Received: by 10.194.62.76 with SMTP id w12mr67685312wjr.5.1419463533158; Wed, 24 Dec 2014 15:25:33 -0800 (PST) Received: by 10.27.204.198 with HTTP; Wed, 24 Dec 2014 15:25:33 -0800 (PST) In-Reply-To: <20141224194714.27569.qmail@ary.lan> References: <20141224194714.27569.qmail@ary.lan> Date: Wed, 24 Dec 2014 18:25:33 -0500 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=047d7ba977a4aa674a050afe9b09 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/T1oHo2thNpQHBsWtS6Th6g12pn8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7001 (4201) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Dec 2014 23:25:36 -0000 --047d7ba977a4aa674a050afe9b09 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 24, 2014 at 2:47 PM, John Levine wrote: > >I received it but given the November and December holidays I had not > >followed up on it since it didn't seem to be an urgent matter. > > > >I agree with John's synopsis upthread, and will reply in more detail ASAP. > > So what should we do about this? I'm thinking that the gaps are large > enough that it'd be worth doing a new revision that includes the missing > stuff, replacing 7001. > > R's, > John > > PS: Yes. I'll help. > Happy to spin up a full update once the holidays are over. I had been planning to do that already, but the main issue I had was resolved with RFC7410. -MSK --047d7ba977a4aa674a050afe9b09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 24, 2014 at 2:47 PM, John Levine <johnl@taugh.c= om> wrote:
>I received it bu= t given the November and December holidays I had not
>followed up on it since it didn't seem to be an urgent matter.
>
>I agree with John's synopsis upthread, and will reply in more detai= l ASAP.

So what should we do about this?=C2=A0 I'm thinking that the gap= s are large
enough that it'd be worth doing a new revision that includes the missin= g
stuff, replacing 7001.

R's,
John

PS: Yes. I'll help.

Happy to spin up a = full update once the holidays are over.=C2=A0 I had been planning to do tha= t already, but the main issue I had was resolved with RFC7410.

-MSK
--047d7ba977a4aa674a050afe9b09-- From nobody Fri Dec 26 16:51:11 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2B51AD403 for ; Fri, 26 Dec 2014 16:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 0KkdpAvdcxXK for ; Fri, 26 Dec 2014 16:51:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1601AD401 for ; Fri, 26 Dec 2014 16:51:07 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQM92748; Sat, 27 Dec 2014 00:51:05 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 27 Dec 2014 00:51:04 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.118]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Sat, 27 Dec 2014 08:51:00 +0800 From: Bert Greevenbosch To: Dave Thaler , "Murray S. Kucherawy" , IETF Apps Discuss Thread-Topic: [apps-discuss] Call For Adoption: draft-seantek-windows-image Thread-Index: AQHQGj54CTMYXL5zbEWGQqtHEBzwYJyVMigAgA13nOA= Date: Sat, 27 Dec 2014 00:50:59 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB66CB32781@SZXEMA510-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.174.121] Content-Type: multipart/alternative; boundary="_000_46A1DF3F04371240B504290A071B4DB66CB32781SZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Z7fOgpsjWTvN1oy9zEI-g_NX3o4 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: Sat, 27 Dec 2014 00:51:10 -0000 --_000_46A1DF3F04371240B504290A071B4DB66CB32781SZXEMA510MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KRnJvbTogYXBwcy1kaXNjdXNzIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZlIFRoYWxlcg0KU2VudDogMTkgRGVjZW1iZXIgMjAxNCAw MzoxMQ0KVG86IE11cnJheSBTLiBLdWNoZXJhd3k7IElFVEYgQXBwcyBEaXNjdXNzDQpTdWJqZWN0 OiBSZTogW2FwcHMtZGlzY3Vzc10gQ2FsbCBGb3IgQWRvcHRpb246IGRyYWZ0LXNlYW50ZWstd2lu ZG93cy1pbWFnZQ0KDQpJIHJldmlld2VkIHRoZSBkcmFmdCwgYW5kIHN1cHBvcnQgYWRvcHRpb24u DQoNCi1EYXZlDQoNCkZyb206IGFwcHMtZGlzY3VzcyBbbWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTXVycmF5IFMuIEt1Y2hlcmF3eQ0KU2VudDogV2Vk bmVzZGF5LCBEZWNlbWJlciAxNywgMjAxNCAxOjE0IFBNDQpUbzogSUVURiBBcHBzIERpc2N1c3MN ClN1YmplY3Q6IFthcHBzLWRpc2N1c3NdIENhbGwgRm9yIEFkb3B0aW9uOiBkcmFmdC1zZWFudGVr LXdpbmRvd3MtaW1hZ2UNCg0KVGhpcyBub3RlIHN0YXJ0cyBhIENhbGwgRm9yIEFkb3B0aW9uIGZv ciBkcmFmdC1zZWFudGVrLXdpbmRvd3MtaW1hZ2UuICBUaGlzIHdvcmsgd2FzIHByZXNlbnRlZCBh cyB0d28gc2VwYXJhdGUgZHJhZnRzIGF0IHRoZSBIb25vbHVsdSBtZWV0aW5nIGFuZCBhcHBlYXJl ZCB0byBoYXZlIHNvbWUgc3VwcG9ydCBhbmQgbm8gb2JqZWN0aW9uIHRvIHByb2Nlc3NpbmcgdGhy b3VnaCBBUFBTQVdHLg0KDQpQbGVhc2UgcmVwbHkgd2l0aCBzdXBwb3J0IG9yIG9iamVjdGlvbiBv biB0aGlzIHRocmVhZCBieSBKYW51YXJ5IDksIDIwMTUuDQotTVNLLCBBUFBTQVdHIGNvLWNoYWly DQo= --_000_46A1DF3F04371240B504290A071B4DB66CB32781SZXEMA510MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlrovk vZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L 5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93 dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiYjNDM7MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gYXBwcy1kaXNjdXNzIFttYWls dG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkRh dmUgVGhhbGVyPGJyPg0KPGI+U2VudDo8L2I+IDE5IERlY2VtYmVyIDIwMTQgMDM6MTE8YnI+DQo8 Yj5Ubzo8L2I+IE11cnJheSBTLiBLdWNoZXJhd3k7IElFVEYgQXBwcyBEaXNjdXNzPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbYXBwcy1kaXNjdXNzXSBDYWxsIEZvciBBZG9wdGlvbjogZHJhZnQt c2VhbnRlay13aW5kb3dzLWltYWdlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkg cmV2aWV3ZWQgdGhlIGRyYWZ0PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj4sIGFuZCBzdXBwb3J0 IGFkb3B0aW9uLjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1EYXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gYXBwcy1kaXNjdXNzIFttYWlsdG86YXBwcy1kaXNjdXNzLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk11cnJheSBTLiBLdWNoZXJhd3k8 YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBEZWNlbWJlciAxNywgMjAxNCAxOjE0IFBNPGJy Pg0KPGI+VG86PC9iPiBJRVRGIEFwcHMgRGlzY3Vzczxicj4NCjxiPlN1YmplY3Q6PC9iPiBbYXBw cy1kaXNjdXNzXSBDYWxsIEZvciBBZG9wdGlvbjogZHJhZnQtc2VhbnRlay13aW5kb3dzLWltYWdl PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoaXMgbm90ZSBzdGFydHMgYSBDYWxs IEZvciBBZG9wdGlvbiBmb3IgZHJhZnQtc2VhbnRlay13aW5kb3dzLWltYWdlLiZuYnNwOyBUaGlz IHdvcmsgd2FzIHByZXNlbnRlZCBhcyB0d28gc2VwYXJhdGUgZHJhZnRzIGF0IHRoZSBIb25vbHVs dSBtZWV0aW5nIGFuZCBhcHBlYXJlZCB0byBoYXZlIHNvbWUgc3VwcG9ydCBhbmQgbm8gb2JqZWN0 aW9uIHRvIHByb2Nlc3NpbmcNCiB0aHJvdWdoIEFQUFNBV0cuPGJyPg0KPGJyPg0KUGxlYXNlIHJl cGx5IHdpdGggc3VwcG9ydCBvciBvYmplY3Rpb24gb24gdGhpcyB0aHJlYWQgYnkgSmFudWFyeSA5 LCAyMDE1LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tTVNL LCBBUFBTQVdHIGNvLWNoYWlyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_46A1DF3F04371240B504290A071B4DB66CB32781SZXEMA510MBXchi_-- From nobody Sat Dec 27 06:31:55 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B121A6FD5 for ; Sat, 27 Dec 2014 06:31:54 -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 hz-569yD_Pdf for ; Sat, 27 Dec 2014 06:31:52 -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 B37A51A6FD0 for ; Sat, 27 Dec 2014 06:31:52 -0800 (PST) Received: from [192.168.0.131] (unknown [96.244.170.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 14D7922E260; Sat, 27 Dec 2014 09:31:30 -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: Sat, 27 Dec 2014 09:31:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D25F56B-EEEC-4858-9905-999DA0C6D52F@isode.com> To: Cyrus Daboo X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZfxMZ59Bo0SDaqGcrxgdML4IEZU Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-http-problem-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: Sat, 27 Dec 2014 14:31:54 -0000 > On 15 Dec 2014, at 2:38 pm, Cyrus Daboo wrote: >=20 > One comment: the definition of the "type" member in Section 3.1 and = the text in Section 4 both recommend that the "type" resolve to HTML = documentation. In tzdist we have a "urn:ietf:params:tzdist:error:" = sub-namespace for error codes that the protocol itself defines and that = we use for the "type" URI value. I think it may be fairly common for = protocols creating new HTTP apis to do something similar, so I wonder if = that should be called out as a "recommended" solution too? I don=E2=80=99t know if I=E2=80=99d go as far as to recommend that as a = practice; most users of this draft will not be creating IETF protocols, = I think.=20 That said, I=E2=80=99m happy to add more context here to make it clear = that it=E2=80=99s a general recommendation, with exceptions such as the = one you mention. Cheers, -- Mark Nottingham http://www.mnot.net/ From nobody Mon Dec 29 00:28:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C278B1A0013 for ; Mon, 29 Dec 2014 00:28: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 KnE1496udfdA for ; Mon, 29 Dec 2014 00:28: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 472721A0011 for ; Mon, 29 Dec 2014 00:28: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 21DA522E265 for ; Mon, 29 Dec 2014 03:28:11 -0500 (EST) Message-ID: <54A11093.1010100@seantek.com> Date: Mon, 29 Dec 2014 00:28:03 -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: <20141228232409.13727.85741.idtracker@ietfa.amsl.com> In-Reply-To: <20141228232409.13727.85741.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141228232409.13727.85741.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7fVQElTYBrElxzY1L0Umzv8ZAvY Subject: [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: Mon, 29 Dec 2014 08:28:14 -0000 The Markdown use cases I-D has been updated. Among other things, the preservation strategies are more robust, and the exemplary registrations have been updated to use the draft-ietf-appsawg-text-markdown-05 template. Regards, Sean -------- Forwarded Message -------- Subject: New Version Notification for draft-seantek-text-markdown-use-cases-01.txt Date: Sun, 28 Dec 2014 15:24:09 -0800 From: internet-drafts@ietf.org A new version of I-D, draft-seantek-text-markdown-use-cases-01.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-seantek-text-markdown-use-cases Revision: 01 Title: text/markdown Use Cases Document date: 2014-12-28 Group: Individual Submission Pages: 18 URL: http://www.ietf.org/internet-drafts/draft-seantek-text-markdown-use-cases-01.txt Status: https://datatracker.ietf.org/doc/draft-seantek-text-markdown-use-cases/ Htmlized: http://tools.ietf.org/html/draft-seantek-text-markdown-use-cases-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-seantek-text-markdown-use-cases-01 Abstract: This document elaborates upon 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. Background information, local storage strategies, and additional syntax registrations are supplied. From nobody Mon Dec 29 21:59:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4721A0545 for ; Mon, 29 Dec 2014 21:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 BZJJTWDvLs97 for ; Mon, 29 Dec 2014 21:58:58 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003: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 C4FB91A044F for ; Mon, 29 Dec 2014 21:58:58 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id wp4so43868477obc.6 for ; Mon, 29 Dec 2014 21:58:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mygrid.org.uk; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=fRtCw3ZwDY+wx8G4bWwACjbAGBgDAX7VrYm3UZvrv28=; b=Rju3fwhhSOeHsKJX2ypZGQmTJb26x6TssJa1ltplh5nnEi2TjHgie/kdzAKeKI4+VK 5IANrPvX63dMt+w6SFtCNhXfAVUAm7AGrbON1/FK4EL43RLcQcGLFMxqKALcJVG5guI0 t0jnVjSWWOgxYQSfNwA7sc62PNQxbChrA+bAM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=fRtCw3ZwDY+wx8G4bWwACjbAGBgDAX7VrYm3UZvrv28=; b=RIFaWp/ZY3PTLUGcb7f4KAQPNOKARJCpsUW/YNSYqY4mHocz8AIKQ4hLdqMzxJK3eQ KaDy8OHOv+fRcyLdiOEVKJa0z2YkpaNAILgyi3Dmtj3M0DrtnfooIVsMEcgg1CelNTFz HmYT6HPedsIEmfl/fMpV3scfVcBbHrp+VpIReNphX3Vt45JMB+BvS9qzaZB+BJOJBbHB 6LCcnAc8iDVu5Rck2Jvvft4A53Af3TqGkgGMzPEuKhM5EkDe5zwyUZFJqX6RfCKnj6On zFUpqDn3moiar+a5rQ4UEOiMs2KtDptga3tG5BKr//GJgD+d1ADzv5iHwqbkQ5Bw6im1 NOtA== X-Gm-Message-State: ALoCoQkjDo3oj3msYDFOUdyDY4x7anS+w0ePMQ8qJuxqnkpITAjoxKbzpR9kBeAKmDTaedxuBYNJ X-Received: by 10.182.56.70 with SMTP id y6mr21998715obp.55.1419919137837; Mon, 29 Dec 2014 21:58:57 -0800 (PST) MIME-Version: 1.0 Sender: stian@mygrid.org.uk Received: by 10.76.91.230 with HTTP; Mon, 29 Dec 2014 21:58:37 -0800 (PST) In-Reply-To: References: From: Stian Soiland-Reyes Date: Mon, 29 Dec 2014 23:58:37 -0600 X-Google-Sender-Auth: 9p94zsV4ttaAk4GvjH7qtHOocTc Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/eY27rhwPta5EBOC75uZhWAWAT44 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: Tue, 30 Dec 2014 05:59:01 -0000 Hi - what's the status of the chartering of the arcmedia WG? I don't see that it has been added to http://datatracker.ietf.org/wg/ and there is no further emails on the arcmedia mailing list. On 13 November 2014 at 21:02, Murray S. Kucherawy wro= te: > Some text I threw together for a possible arcmedia charter. Feel free to > hack on it. > > Also, if anyone is interested in participating in the management of this > working group, please let Barry know. It is likely at this point that th= is > will be a short-lived working group which will never actually meet. > > --- snip --- > > There has been recent work to register media types for archive formats su= ch > as =E2=80=9Ctar=E2=80=9D (a POSIX standard format). There are already se= veral similar media > types for archive formats, such as =E2=80=9Cgzip=E2=80=9D and =E2=80=9Czi= p=E2=80=9D (see, for example, > RFC6713), all of which are registered under the top-level media type > =E2=80=9Capplication=E2=80=9D. > > We create top-level media types only rarely, only with Standards Track RF= Cs, > and only when one or more media types get special (or common, in the case= of > more than one) handling that does not fit under an existing top-level med= ia > type. RFC6838 defines this process. > > This working group will create an =E2=80=9Carchive=E2=80=9D top-level med= ia type in a > Standards Track document, using draft-seantek-kerwin-arcmedia-type as its > initial input. It will specify rules for registering subtypes under that > new top-level type. All of the usual things will be considered, includin= g > type suffixes, fragment identifiers, and internationalization. > > Either in that same document or in a second one, it will produce an initi= al > set of registrations under the new top-level media type. > > The main document will include an Implementation Status section, describe= d > by RFC6982, to record known projects that will either produce or consume > content using the new media type. If by the first milestone there appear= s > to be no implementations of the new media type expected, the working grou= p > will fold having produced no RFCs. > > No other work is in scope for this working group. > > Milestones: > - June 2015: Base document > - December 2015: Registrations document (if separate) > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --=20 Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718 From nobody Tue Dec 30 10:13:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F0A1A1A0C; Tue, 30 Dec 2014 10:13:23 -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 J9sCRYXPgqz8; Tue, 30 Dec 2014 10:13:21 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2137F1A00FD; Tue, 30 Dec 2014 10:13:21 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex7so24496973wid.3; Tue, 30 Dec 2014 10:13:19 -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=aDBNvwbSpJgQnSO1cdQ3ZVGQe4pvZ3rTkY3XUvVDUY8=; b=eJHDqQwVXcDNIIzi5IEem8tb2fx9IBzzK9Ta955dEhYIJF9bM5VIlLdoA6IojMG8Hp X+7NElTQsGpoZL3gbAUxmLbIh3CjofHncOT6kkj1utOoHUoKbMxZd2ZYQLz/XrtqY5bJ QULnTtP+lekKttS8ZK6r09QfDpfg5zPUT2MlQC9zMh2KMfJ4BdwQm950BJXyvCZe3lnn NOfFl1m2B8OBrVohYc2GS3HPx3CE1qfcTs1bLB6TQ010JlSwopvF+9avlzVvi0WWT9ra 5siDxYUrEGEkYal36Jr4yLaeqLJwfhwpE9VBkJmng06kf0g99kzLKFOL1K2mv2QBW/2W MbrA== MIME-Version: 1.0 X-Received: by 10.180.218.39 with SMTP id pd7mr109673431wic.21.1419963193221; Tue, 30 Dec 2014 10:13:13 -0800 (PST) Received: by 10.27.204.198 with HTTP; Tue, 30 Dec 2014 10:13:13 -0800 (PST) In-Reply-To: References: Date: Tue, 30 Dec 2014 10:13:13 -0800 Message-ID: From: "Murray S. Kucherawy" To: Stian Soiland-Reyes Content-Type: multipart/alternative; boundary=001a1134cd58b9e76c050b72f1d0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/r7Jl5AcXge66HwG07du6NH28Qf0 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: Tue, 30 Dec 2014 18:13:23 -0000 --001a1134cd58b9e76c050b72f1d0 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 29, 2014 at 9:58 PM, Stian Soiland-Reyes < soiland-reyes@cs.manchester.ac.uk> wrote: > Hi - what's the status of the chartering of the arcmedia WG? I don't > see that it has been added to http://datatracker.ietf.org/wg/ and > there is no further emails on the arcmedia mailing list. > A mailing list was created shortly after the November meeting, and the proposed charter was posted there and here. There has been no response of any kind. -MSK --001a1134cd58b9e76c050b72f1d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 29, 2014 at 9:58 PM, Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk> wrote:
Hi - what's the status of the chartering of the arcmedia WG? I d= on't
see that it has been added to http://datatracker.ietf.org/wg/ and
there is no further emails on the arcmedia mailing list.

A mailing list was created shortly after the November mee= ting, and the proposed charter was posted there and here.=C2=A0 There has b= een no response of any kind.

-MSK
--001a1134cd58b9e76c050b72f1d0-- From nobody Tue Dec 30 10:43:55 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353271A1A38 for ; Tue, 30 Dec 2014 10:43:54 -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 ff3kHupcCrci for ; Tue, 30 Dec 2014 10:43:52 -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 2A4DD1A1A2F for ; Tue, 30 Dec 2014 10:43:52 -0800 (PST) Received: from [172.29.109.11] (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 sBUIhmgJ009546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 30 Dec 2014 10:43:51 -0800 Message-ID: <54A2F25D.5070902@dcrocker.net> Date: Tue, 30 Dec 2014 10:43:41 -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: apps-discuss@ietf.org References: 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]); Tue, 30 Dec 2014 10:43:51 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/m_ZqJLnRu9pjtFaHMlPPBtJLSms Subject: Re: [apps-discuss] Proposed charter for arcmedia 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: Tue, 30 Dec 2014 18:43:54 -0000 On 12/30/2014 10:13 AM, Murray S. Kucherawy wrote: > A mailing list was created shortly after the November meeting, and the > proposed charter was posted there and here. There has been no response > of any kind. For completeness: https://www.ietf.org/mailman/listinfo/arcmedia d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From n.theodore.matavka.files@gmail.com Tue Dec 30 15:54:47 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682891A8978 for ; Tue, 30 Dec 2014 15:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 zF2-E6klu_bf for ; Tue, 30 Dec 2014 15:54:44 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7890C1A896A for ; Tue, 30 Dec 2014 15:54:44 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id at20so14332022iec.19 for ; Tue, 30 Dec 2014 15:54:43 -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=qdGvIPWSonN5yU8vYdMb9hu3yzLQWmS/ztPDNBKYfFY=; b=Vbzvj2EJAsQ+3oIhPLM2TvffFCHzfy6dHlQENIz2HsFfp74oOwCtWnGGXS6EGWnltq uajv1jE3gE0mBTJ7ItNJmsizQvmNNMxt28/MyLtMCRGFbv+mRoZCCyo+ew+WbDYc+TGJ XcDRwj6Y/2Nq4uNiB58x5+pxOx+vVu7emkfk8sJ+5HnllEI9for2ywi3jp0M2lzzkqz0 arOJ7hLBlGx4C1AhdHnD7F7awv3vMBHm+5JW+taiaP2qi9ztgRUBU8MpTsQs4kdd1xG4 Qk2W1ZjC5JUwBCMXbArg9KuuWs0w4wQvYHwMgZ2L16rAiBjo0VDdHWdqVr7MzmypXxq8 LYmA== MIME-Version: 1.0 X-Received: by 10.107.162.67 with SMTP id l64mr58737356ioe.14.1419983683305; Tue, 30 Dec 2014 15:54:43 -0800 (PST) Received: by 10.107.130.33 with HTTP; Tue, 30 Dec 2014 15:54:43 -0800 (PST) Date: Tue, 30 Dec 2014 18:54:43 -0500 Message-ID: From: Nick Matavka To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=001a113e964207c767050b77b745 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/busuM1lHNHVtZWM7UIulNhvyNpA Subject: [apps-discuss] Request for RFC draft review X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 31 Dec 2014 02:52:28 -0000 --001a113e964207c767050b77b745 Content-Type: text/plain; charset=UTF-8 Hello, world! I'm writing a second RFC for the Gopher protocol, with some other people. I'll most probably send it to the ISE as an independent submission. Before I do that, though, I would sincerely appreciate some informal review, just to make sure it has everything it needs. It is on piratepad, and can be seen at the address below: http://piratepad.net/gopher Edward Matavka --001a113e964207c767050b77b745 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello, world!

I'm writing a seco= nd RFC for the Gopher protocol, with some other people.=C2=A0 I'll most= probably send it to the ISE as an independent submission.=C2=A0 Before I d= o that, though, I would sincerely appreciate some informal review, just to = make sure it has everything it needs.

It is on piratepad, and = can be seen at the address below:

http://piratepad.net/gopher

Edward Matavka
=


--001a113e964207c767050b77b745-- From nobody Wed Dec 31 02:42:35 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4EF1A8ACA; Wed, 31 Dec 2014 02:42:28 -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 BhiTQK_qxUIA; Wed, 31 Dec 2014 02:42:26 -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 DA1831A8AC6; Wed, 31 Dec 2014 02:42:25 -0800 (PST) Received: internal info suppressed Date: Wed, 31 Dec 2014 11:42:20 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: appsdir@ietf.org, Nick Matavka In-Reply-To: Message-ID: References: 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=1420022541; bh=HIP9UOe2d2z+rr4owg1bja9KRm8Tc9zvi+selekrOCI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=M9uMUv6VBD3IGwZfgzKX4RG6OnYKFp8Gh7jFH2SQBfEHLnY5UDNyFnsCOIpnwlKj7 RCJy4lYB3IlzLjz/NR7CepSf7uaToAQwVJWibGpHnK1fVn4LkqkugpeGRSGGm0EpQQ gQJS5gVw/mNgoHg+M6MfZa5MVdojDGemEJ5/da4E= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/L-t4P0sJTPZbqVBmPyGMYOTxXE4 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Request for RFC draft review X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 31 Dec 2014 10:42:28 -0000 Hello... Folks at appsdir... some one volunteers for this review? Some of us "old boys" are indeed old enough to remember the v1.0 of gopher, so we can help.. :-) Please let Nick know! and happy 2015 ! On Tue, 30 Dec 2014, Nick Matavka wrote: > Hello, world! > > I'm writing a second RFC for the Gopher protocol, with some other people. > I'll most probably send it to the ISE as an independent submission. Before > I do that, though, I would sincerely appreciate some informal review, just > to make sure it has everything it needs. > > It is on piratepad, and can be seen at the address below: > > http://piratepad.net/gopher > > Edward Matavka > ------------------------------------------------------------------------------ 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 Dec 31 05:50:52 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8541A8AF3; Wed, 31 Dec 2014 05:50:28 -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 I4EiTmW9OoWa; Wed, 31 Dec 2014 05:50:27 -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 4D2601A8AF2; Wed, 31 Dec 2014 05:50:27 -0800 (PST) Received: internal info suppressed Date: Wed, 31 Dec 2014 14:50:19 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: Arnt Gulbrandsen In-Reply-To: <9b6c920a21905ea700d699f3dc27013a00e8d756b230cfb32b5d4de702cc95e2.sha-256@android.antelope.email> Message-ID: References: <9b6c920a21905ea700d699f3dc27013a00e8d756b230cfb32b5d4de702cc95e2.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=1420033820; bh=a2rA9Tje1n1dS0c5YwXQDgfYAT5X6OquGH8cz9VgmCc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kuikWcxqZPVJn8EC/+6X1HvjXRqtnUFBZ4A+222XEE5mW7ukYbDmjAXSb4mKgRgBR Bj1tvJKmyGd4uXYJhknUXwtrYSserymdoR2FJl3IanuYyowtIwwWI+XxVheBLhXFBj F9bl6/4ShmjCrUfJ53cwQR21ORKwmDAqlNKsnvMk= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/AWfFOte7GHBDKy5h191_7S95xFw Cc: appsdir@ietf.org, apps-discuss@ietf.org, Nick Matavka Subject: Re: [apps-discuss] Request for RFC draft review X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 31 Dec 2014 13:50:29 -0000 On Wed, 31 Dec 2014, Arnt Gulbrandsen wrote: > What is the point of this? > > This isn't a rhetorical question, I actually am intrigued. My guess is to document what as become "common practice" but was not inside the original standard, and to make it standardized. As there are quite a number of "extensions" which are not officially documented, it is worth to document them. At least this is my understanding of the point for making it. But Nick can add much more for sure. > > Arnt > ------------------------------------------------------------------------------ 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 Dec 31 06:16:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD851A8AF0 for ; Wed, 31 Dec 2014 06:16:01 -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 XnJtz7V9iUy0 for ; Wed, 31 Dec 2014 06:16:00 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B481A8AF3 for ; Wed, 31 Dec 2014 06:15:59 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wp18so48297759obc.1 for ; Wed, 31 Dec 2014 06:15:59 -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=4u2n6QsJo3bho5F4hPw0YkPPFYc1yB2A6MQaha8/+6I=; b=fNT8Mh6gUF4Gk9yaXrE9QG42vduEq92QVYgPt7dSwRH1YZWHFjhx3+8EPc80TeQtOq 7gYSrPso98lbD56CCPUymcaVDq02dxwOCnG9Ar1/CpKJNh4P/GxVCxr1vr6Yk3L+rUar xWf9t7pwCwy1WmpnrRj2JigSzVUwveBF98rCc= 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=4u2n6QsJo3bho5F4hPw0YkPPFYc1yB2A6MQaha8/+6I=; b=J8OrwKkp4Ct8URoyS6r3sZs/d2epaKDPxrdRh0XKwV/q/RyvMqnX/ftYYgnP/bx13a TjB0N7/TtSUzRsVmeX9MMn3iE1mqTmQilJbZydFroyniiCk+3qYFKrT3HRbxkPobzMx5 ZhiXRYOS79vZFEBA2T1sax1wln2Br3zcpl5PKrwhk8g3zjYR39Vg7yJvwKjEjd31D+vH Gspji3WRYHk/kzyOODyNZjwhYLXI5OZnBzY8CwpPyqLzXRCi1G/Arbjery9c8jc2cHjW P96OfXFNTh/1BJtpYsBzAtisGCKcKyaQtcgorYnPilp6cuxLb7Ei1qgmVWbteHvrNZUv GEAg== X-Gm-Message-State: ALoCoQnPAxkShAAjQJVFajYKnj9gtGvLjQ7lvnzZsJ2hUUAS+rNWhT8kAER8n1KcIyKLLx8Q7NJd MIME-Version: 1.0 X-Received: by 10.202.185.69 with SMTP id j66mr37497142oif.86.1420035359120; Wed, 31 Dec 2014 06:15:59 -0800 (PST) Received: by 10.60.84.171 with HTTP; Wed, 31 Dec 2014 06:15:59 -0800 (PST) In-Reply-To: References: <9b6c920a21905ea700d699f3dc27013a00e8d756b230cfb32b5d4de702cc95e2.sha-256@android.antelope.email> Date: Wed, 31 Dec 2014 14:15:59 +0000 Message-ID: From: Dave Cridland To: Claudio Allocchio Content-Type: multipart/alternative; boundary=001a113ce612263747050b83bfa2 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/A322PUD2KvTVAtWSSp4Fv8d5_Tg Cc: appsdir@ietf.org, "apps-discuss@ietf.org" , Nick Matavka Subject: Re: [apps-discuss] [appsdir] Request for RFC draft review X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 31 Dec 2014 14:16:01 -0000 --001a113ce612263747050b83bfa2 Content-Type: text/plain; charset=UTF-8 On 31 December 2014 at 13:50, Claudio Allocchio wrote: > On Wed, 31 Dec 2014, Arnt Gulbrandsen wrote: > > What is the point of this? >> >> This isn't a rhetorical question, I actually am intrigued. >> > > My guess is to document what as become "common practice" but was not > inside the original standard, and to make it standardized. > > As there are quite a number of "extensions" which are not officially > documented, it is worth to document them. > > At least this is my understanding of the point for making it. But Nick can > add much more for sure. > But, I mean, gopher? I thought I was weird running an ACAP server. :-) I've skimmed the document; I didn't immediately see any ABNF or similar formal syntax, struggled to figure out what the syntax of a selector string is, and I thought I noticed a casual mention that textual types were 7-bit only. Is this really the case? Dave. --001a113ce612263747050b83bfa2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 31 December 2014 at 13:50, Claudio Allocchio <<= a href=3D"mailto:Claudio.Allocchio@garr.it" target=3D"_blank">Claudio.Alloc= chio@garr.it> wrote:
On Wed= , 31 Dec 2014, Arnt Gulbrandsen wrote:

What is the point of this?

This isn't a rhetorical question, I actually am intrigued.

My guess is to document what as become "common practice" but was = not inside the original standard, and to make it standardized.

As there are quite a number of "extensions" which are not officia= lly documented, it is worth to document them.

At least this is my understanding of the point for making it. But Nick can = add much more for sure.

But, I mean, go= pher? I thought I was weird running an ACAP server. :-)

I've skimmed the document; I didn't immediately see any ABNF = or similar formal syntax, struggled to figure out what the syntax of a sele= ctor string is, and I thought I noticed a casual mention that textual types= were 7-bit only. Is this really the case?

Dave.
--001a113ce612263747050b83bfa2-- From nobody Wed Dec 31 07:59:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD991A90C5; Wed, 31 Dec 2014 07:59:32 -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 1OxCIiGFEHBp; Wed, 31 Dec 2014 07:59:30 -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 A27F21A90C4; Wed, 31 Dec 2014 07:59:29 -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 1Y6LgE-0007FM-et; Wed, 31 Dec 2014 15:59:26 +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 1Y6LgE-0004cC-L4; Wed, 31 Dec 2014 15:59:26 +0000 Message-ID: <54A41D6C.9010501@ninebynine.org> Date: Wed, 31 Dec 2014 15:59: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: "Murray S. Kucherawy" , Stian Soiland-Reyes 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/Qlg1famAo5g4c8Q_60xw0Okeu_c 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: Wed, 31 Dec 2014 15:59:33 -0000 Re: http://www.ietf.org/mail-archive/web/arcmedia/current/msg00001.html I think the suggested charter looks pretty good. The work seems well-scoped to me. I'd expect to review at least the proposed base document, and maybe some of the initial registrations. #g -- On 30/12/2014 18:13, Murray S. Kucherawy wrote: > On Mon, Dec 29, 2014 at 9:58 PM, Stian Soiland-Reyes < > soiland-reyes@cs.manchester.ac.uk> wrote: > >> Hi - what's the status of the chartering of the arcmedia WG? I don't >> see that it has been added to http://datatracker.ietf.org/wg/ and >> there is no further emails on the arcmedia mailing list. >> > > A mailing list was created shortly after the November meeting, and the > proposed charter was posted there and here. There has been no response of > any kind. > > -MSK > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Wed Dec 31 08:11:11 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8E61A911E for ; Wed, 31 Dec 2014 08:11:04 -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 jA-0kVF_qQ1t for ; Wed, 31 Dec 2014 08:10: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 6DD091A9121 for ; Wed, 31 Dec 2014 08:10:45 -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 1Y6Lr4-0000Ny-hk; Wed, 31 Dec 2014 16:10: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 1Y6Lr4-0006Ez-HG; Wed, 31 Dec 2014 16:10:38 +0000 Message-ID: <54A4200C.2040706@ninebynine.org> Date: Wed, 31 Dec 2014 16:10: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: Sean Leonard , apps-discuss@ietf.org References: <20141228232409.13727.85741.idtracker@ietfa.amsl.com> <54A11093.1010100@seantek.com> In-Reply-To: <54A11093.1010100@seantek.com> 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/ZU9ve1aby_aU8fvme3CA8FeOvXY 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: Wed, 31 Dec 2014 16:11:04 -0000 Hi, 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!). 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 flavours. (Does this also suggest a tweak to the registration template?) #g -- On 29/12/2014 08:28, Sean Leonard wrote: > The Markdown use cases I-D has been updated. Among other things, the > preservation strategies are more robust, and the exemplary registrations have > been updated to use the draft-ietf-appsawg-text-markdown-05 template. > > Regards, > > Sean > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-seantek-text-markdown-use-cases-01.txt > Date: Sun, 28 Dec 2014 15:24:09 -0800 > From: internet-drafts@ietf.org > > > > A new version of I-D, draft-seantek-text-markdown-use-cases-01.txt > has been successfully submitted by Sean Leonard and posted to the > IETF repository. > > Name: draft-seantek-text-markdown-use-cases > Revision: 01 > Title: text/markdown Use Cases > Document date: 2014-12-28 > Group: Individual Submission > Pages: 18 > URL: > http://www.ietf.org/internet-drafts/draft-seantek-text-markdown-use-cases-01.txt > Status: > https://datatracker.ietf.org/doc/draft-seantek-text-markdown-use-cases/ > Htmlized: http://tools.ietf.org/html/draft-seantek-text-markdown-use-cases-01 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-seantek-text-markdown-use-cases-01 > > Abstract: > This document elaborates upon 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. > Background information, local storage strategies, and additional > syntax registrations are supplied. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Wed Dec 31 12:42:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DB21A1AA1; Wed, 31 Dec 2014 12:42:54 -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 IslfUdrbSn0t; Wed, 31 Dec 2014 12:42:53 -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 8A17C1A1A7D; Wed, 31 Dec 2014 12:42:53 -0800 (PST) Received: from [172.29.108.161] (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 sBVKghDI013980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 31 Dec 2014 12:42:47 -0800 Message-ID: <54A45FBD.1070701@dcrocker.net> Date: Wed, 31 Dec 2014 12:42:37 -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: Stian Soiland-Reyes References: <54A41D6C.9010501@ninebynine.org> In-Reply-To: <54A41D6C.9010501@ninebynine.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 31 Dec 2014 12:42:48 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/HrNBz0MJ4pUVNdwi31OnQDLciio 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 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: Wed, 31 Dec 2014 20:42:55 -0000 The proffered text is all reasonable, but it needs a small bit of enhancement, for broader readership and a bit of IETF formality: I suggest adding an opening sentence that sets the context a little more. Something like: Archive formats are used to aggregate multiple files and other data into a single object, often with data compression and/or confidentiality protection (encryption). > There has been recent work to register media types for archive > formats such as “tar” (a POSIX standard format). There are already > several similar media types for archive formats, such as “gzip” and > “zip” (see, for example, RFC6713), all of which are registered under > the top-level media type “application”. In order for the first paragraph to be able to stand alone, per formal IETF requirements -- that paragraph is circulated as a description of the intended effort -- I suggest moving some text to be its last sentence: This working group will create an “archive” top-level media type. > > We create top-level media types only rarely, only with Standards > Track RFCs, and only when one or more media types get special (or > common, in the case of more than one) handling that does not fit > under an existing top-level media type. RFC6838 defines this > process. > > This working group will create an “archive” top-level media type in a > Standards Track document, using draft-seantek-kerwin-arcmedia-type as Replace this sentence with: The working group will use draft-seantek-kerwin-arcmedia-type as initial input. (It doesn't help the charter to cite intended status.) > 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. > Either in that same document or in a second one, it will produce an > initial set of registrations under the new top-level media type. > > The main document will include an Implementation Status section, > described by RFC6982, to record known projects that will either > produce or consume content using the new media type. If by the first > milestone there appears to be no implementations of the new media > type expected, the working group will fold having produced no RFCs. > > No other work is in scope for this working group. > > Milestones: - June 2015: Base document - December 2015: Registrations > document (if separate) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Dec 31 16:01:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF591A1A54; Wed, 31 Dec 2014 16:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_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 lT5GMJmzNcZE; Wed, 31 Dec 2014 16:00:58 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0079.outbound.protection.outlook.com [65.55.169.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87AE01A1A4A; Wed, 31 Dec 2014 16:00:58 -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; Thu, 1 Jan 2015 00:00:56 +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; Thu, 1 Jan 2015 00:00:56 +0000 From: Larry Masinter To: Graham Klyne , "Murray S. Kucherawy" , Stian Soiland-Reyes Thread-Topic: [apps-discuss] Proposed charter for arcmedia Thread-Index: AQHP/7eASsRovqcZ0kWKs9S5yPX4A5yn69+AgADNPoCAAW0FAIAAhhxQ Date: Thu, 1 Jan 2015 00:00:54 +0000 Message-ID: References: <54A41D6C.9010501@ninebynine.org> In-Reply-To: <54A41D6C.9010501@ninebynine.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2601:9:8380:992:a493:742f:219e:8233] authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB0957; x-forefront-prvs: 04433051BF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(479174004)(13464003)(24454002)(199003)(377454003)(51704005)(62966003)(2900100001)(92566001)(76176999)(99286002)(2950100001)(19580405001)(105586002)(19580395003)(106116001)(102836002)(68736005)(15975445007)(107046002)(54356999)(20776003)(74316001)(33656002)(77156002)(106356001)(54206007)(76576001)(64706001)(86362001)(101416001)(99396003)(120916001)(93886004)(4396001)(87936001)(2656002)(50986999)(97736003)(40100003)(54606007)(21056001)(122556002)(46102003)(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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jan 2015 00:00:55.0415 (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/j_zDDxr5iMgMLNL1IctTAXVLRos 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 00:01:02 -0000 I think the arcmedia WG charter should take into the W3C TAG work on packag= ing/archives http://w3ctag.github.io/packaging-on-the-web/ (W3c-tag bcc) > -----Original Message----- > From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of > Graham Klyne > Sent: Wednesday, December 31, 2014 8:00 AM > To: Murray S. Kucherawy; Stian Soiland-Reyes > Cc: arcmedia@ietf.org; IETF Apps Discuss > Subject: Re: [apps-discuss] Proposed charter for arcmedia >=20 > Re: http://www.ietf.org/mail-archive/web/arcmedia/current/msg00001.html >=20 > I think the suggested charter looks pretty good. The work seems well-sco= ped to > me. >=20 > I'd expect to review at least the proposed base document, and maybe some = of > the initial registrations. >=20 > #g > -- >=20 >=20 > On 30/12/2014 18:13, Murray S. Kucherawy wrote: > > On Mon, Dec 29, 2014 at 9:58 PM, Stian Soiland-Reyes < > > soiland-reyes@cs.manchester.ac.uk> wrote: > > > >> Hi - what's the status of the chartering of the arcmedia WG? I don't > >> see that it has been added to http://datatracker.ietf.org/wg/ and > >> there is no further emails on the arcmedia mailing list. > >> > > > > A mailing list was created shortly after the November meeting, and the > > proposed charter was posted there and here. There has been no > > response of any kind. > > > > -MSK > > > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Wed Dec 31 16:59:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9F01A1AF2; Wed, 31 Dec 2014 16:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, 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 ZK7BALsOKFIG; Wed, 31 Dec 2014 16:59: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 D3B8F1A1AA8; Wed, 31 Dec 2014 16:59:47 -0800 (PST) Received: from [192.168.0.131] (unknown [71.179.211.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E4E8922E260; Wed, 31 Dec 2014 19:59:44 -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: Wed, 31 Dec 2014 19:59:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <86C96FDF-9A48-43A3-B38A-468F4407AD82@mnot.net> References: <54A41D6C.9010501@ninebynine.org> To: Larry Masinter X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/AonrkGv199V7IDmV6uqGDf3VQVU Cc: IETF Apps Discuss , "arcmedia@ietf.org" , Graham Klyne , Public TAG List 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 00:59:50 -0000 =E2=80=A6 which isn=E2=80=99t yet final, BTW. Cheers, > On 31 Dec 2014, at 7:00 pm, Larry Masinter wrote: >=20 > I think the arcmedia WG charter should take into the W3C TAG work on = packaging/archives >=20 > http://w3ctag.github.io/packaging-on-the-web/ >=20 > (W3c-tag bcc) >=20 >=20 >> -----Original Message----- >> From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf = Of >> Graham Klyne >> Sent: Wednesday, December 31, 2014 8:00 AM >> To: Murray S. Kucherawy; Stian Soiland-Reyes >> Cc: arcmedia@ietf.org; IETF Apps Discuss >> Subject: Re: [apps-discuss] Proposed charter for arcmedia >>=20 >> Re: = http://www.ietf.org/mail-archive/web/arcmedia/current/msg00001.html >>=20 >> I think the suggested charter looks pretty good. The work seems = well-scoped to >> me. >>=20 >> I'd expect to review at least the proposed base document, and maybe = some of >> the initial registrations. >>=20 >> #g >> -- >>=20 >>=20 >> On 30/12/2014 18:13, Murray S. Kucherawy wrote: >>> On Mon, Dec 29, 2014 at 9:58 PM, Stian Soiland-Reyes < >>> soiland-reyes@cs.manchester.ac.uk> wrote: >>>=20 >>>> Hi - what's the status of the chartering of the arcmedia WG? I = don't >>>> see that it has been added to http://datatracker.ietf.org/wg/ and >>>> there is no further emails on the arcmedia mailing list. >>>>=20 >>>=20 >>> A mailing list was created shortly after the November meeting, and = the >>> proposed charter was posted there and here. There has been no >>> response of any kind. >>>=20 >>> -MSK >>>=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 >=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 Wed Dec 31 17:45:12 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF261A1B1B for ; Wed, 31 Dec 2014 17:45:01 -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 R9HLb_bIJygB for ; Wed, 31 Dec 2014 17:44:57 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001: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 66A631A01E1 for ; Wed, 31 Dec 2014 17:44:57 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id y20so15459686ier.18 for ; Wed, 31 Dec 2014 17:44:56 -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=j252+PJftvfDAJcpnLfbLJFuKV5sBwS5YpjAVeMCzC8=; b=rZMXOsFloZ/VdE0VVzPb6uJC8E2VZk4noR1kRJJHqsalToXVXQ+sMePjhft6eFd50x OI533mzw9y1VoEvCTkRyCgHj5xLbPW0NAihCBnVoIDjKLKCE3IYKZlHlmRsN6uUeUNn1 ymz8jcLd085nM9GoHmhbfTW9nRUIXSD+VsKTE9L0lyI5y94BWBZFVhNcregTAj4IjTrz MOn79hBa/o46iPCjBWfQOf6WsLElr4SxqHBoQWXOjUKDCVVrdfTuZT+vKkUxZTgOjnmU 25l38big9NRGmD4fvw+9MnUPf15YrePimPAYiE3XSdBeyc1+iMmvmGujPREEyplaarU3 lBrw== MIME-Version: 1.0 X-Received: by 10.107.8.149 with SMTP id h21mr61164080ioi.74.1420076696387; Wed, 31 Dec 2014 17:44:56 -0800 (PST) Received: by 10.107.130.33 with HTTP; Wed, 31 Dec 2014 17:44:56 -0800 (PST) Received: by 10.107.130.33 with HTTP; Wed, 31 Dec 2014 17:44:56 -0800 (PST) In-Reply-To: References: Date: Wed, 31 Dec 2014 20:44:56 -0500 Message-ID: From: Nick Matavka To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=001a113f92100ac68d050b8d5f38 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/gLz5MhRIuGiMLns1v_x285PQTZo Subject: [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 01:45:01 -0000 --001a113f92100ac68d050b8d5f38 Content-Type: text/plain; charset=UTF-8 Hello, world! 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. Cordially N E Matavka --001a113f92100ac68d050b8d5f38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello, world!

I made a few rather substantial edits to that gopher spec, f= or the dinosaurs that still care.=C2=A0 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 subm= issions stream.

Cordially

N E Matavka

--001a113f92100ac68d050b8d5f38-- From nobody Wed Dec 31 20:24:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8AA1A1B38; Wed, 31 Dec 2014 20:24: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 jNHgNseqr81C; Wed, 31 Dec 2014 20:24:11 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D3421A1B36; Wed, 31 Dec 2014 20:24:08 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id k14so22760005wgh.1; Wed, 31 Dec 2014 20:24: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=9BZ4UbGuo3fKvBS1LN87bWhvWYUvmlwxdPSlMAR6Amk=; b=Vvt+ChkEpSq+wXWXekpazECXX7PnSum3dOF1k7GlcUzQ8saFpuCOXY02NEJRas5H46 g18RGccLt/cWCTEr1lJY4myrprgpQWc7Ovx1hRmLq8EwTuHwpdZI5lOjc8MkOG0wLBpd qHQGYzkKhq25x2QPCv5dtqErKGm79OH2XB0pVjwT6j/+sfEFfy+5ofhgeGUJZfcptbPC Y9t7ja7bWu8ZSab7jjalQbj0KXpRFOvtKLp/QTpy6iOueKWd9yn47YlzVrohdeSCTc90 aOwQg57B+moFh4SsvbRMEWzF0kWZTUbeXGNjZGeOlheDafj3LFaVtjrMh+e/AX8rOwPX tC5A== MIME-Version: 1.0 X-Received: by 10.180.105.68 with SMTP id gk4mr20800507wib.30.1420086246974; Wed, 31 Dec 2014 20:24:06 -0800 (PST) Received: by 10.27.204.198 with HTTP; Wed, 31 Dec 2014 20:24:06 -0800 (PST) In-Reply-To: <86C96FDF-9A48-43A3-B38A-468F4407AD82@mnot.net> References: <54A41D6C.9010501@ninebynine.org> <86C96FDF-9A48-43A3-B38A-468F4407AD82@mnot.net> Date: Wed, 31 Dec 2014 20:24:06 -0800 Message-ID: From: "Murray S. Kucherawy" To: Mark Nottingham Content-Type: multipart/alternative; boundary=f46d04426a604d2b3a050b8f9872 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/4m68by9z2UOvxdr92xIzlP0pvEg Cc: IETF Apps Discuss , Graham Klyne , Larry Masinter , "arcmedia@ietf.org" , Public TAG List 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 04:24:15 -0000 --f46d04426a604d2b3a050b8f9872 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 31, 2014 at 4:59 PM, Mark Nottingham wrote: > =E2=80=A6 which isn=E2=80=99t yet final, BTW. > Here's the latest edit, based on today's feedback: https://github.com/mskucherawy/docs/blob/master/charter-arcmedia Anything else? -MSK --f46d04426a604d2b3a050b8f9872 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 31, 2014 at 4:59 PM, Mark Nottingham <mnot@mnot.n= et> wrote:
=E2=80=A6 which is= n=E2=80=99t yet final, BTW.

Here's = the latest edit, based on today's feedback:

https://github.com= /mskucherawy/docs/blob/master/charter-arcmedia

Anythi= ng else?

-MSK
--f46d04426a604d2b3a050b8f9872-- From nobody Wed Dec 31 20:39:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C051A1B36; Wed, 31 Dec 2014 20:39: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 Ha0FIs5bVYer; Wed, 31 Dec 2014 20:39:22 -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 0F5671A1B2C; Wed, 31 Dec 2014 20:39:22 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id b13so13418256qcw.20; Wed, 31 Dec 2014 20:39: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=AQe0uKzqU79Axb46S0+rVitub0ebR4nNO10Y3EvB6eY=; b=kgwIysHrPWgQQifMs6YqsbUouav2M6XmhBUthkiqhfd9V3ijTdGW33Xvhijwvb+IBG gPqH2VteHW+YbN1fJGj5Jh0ZUi+gxa/OG1zMqHN42mPbO/lnl5XtULDO6XSSeSyottV1 RalGgIhmvPYi+jTJi+GmSGNxnau93OnRyPXfR9lqMHF4mSs4EQTB5QoE/HxJleMPRQOP Xoc7WWGQuxis+e4KQxyAWzbD1ViMIWlSfRPR9gpssDGj8BriKLooYzzkW861OWimG57M 6sV9nVZTXbPO0ED3zFeD+GM4xSpuZ47PsRS9D7RMM080H2UE1bUuPzT1ieQ/9e5la9Xr B7tQ== MIME-Version: 1.0 X-Received: by 10.140.35.114 with SMTP id m105mr96773275qgm.79.1420087161287; Wed, 31 Dec 2014 20:39:21 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.86.163 with HTTP; Wed, 31 Dec 2014 20:39:21 -0800 (PST) In-Reply-To: References: <54A41D6C.9010501@ninebynine.org> <86C96FDF-9A48-43A3-B38A-468F4407AD82@mnot.net> Date: Thu, 1 Jan 2015 14:39:21 +1000 X-Google-Sender-Auth: a0VJJ1SjMrh1ipR_wAp_t1_Maw8 Message-ID: From: Matthew Kerwin To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a11c003c0cc7a64050b8fcecc Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/sPweSaoRAslOJgMzYt2a5ZFV5NQ Cc: Graham Klyne , IETF Apps Discuss , "arcmedia@ietf.org" , Larry Masinter , 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: Thu, 01 Jan 2015 04:39:23 -0000 --001a11c003c0cc7a64050b8fcecc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 1 January 2015 at 14:24, Murray S. Kucherawy wrote= : > On Wed, Dec 31, 2014 at 4:59 PM, Mark Nottingham wrote: > >> =E2=80=A6 which isn=E2=80=99t yet final, BTW. >> > > Here's the latest edit, based on today's feedback: > > https://github.com/mskucherawy/docs/blob/master/charter-arcmedia > > Anything else? > > =E2=80=8BLooks good to me.=E2=80=8B --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11c003c0cc7a64050b8fcecc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1 January 2015 at 14:24, Murray S. Kucherawy <superuser@gmail.com> wrote:
On W= ed, Dec 31, 2014 at 4:59 PM, Mark Nottingham <mnot@mnot.net> wr= ote:
=E2=80=A6 whic= h isn=E2=80=99t yet final, BTW.

= Here's the latest edit, based on today's feedback:

https://github.com/mskucherawy/docs/blob/master/charter-arcmed= ia

Anything else?


=E2=80=8BLooks good to me= .=E2=80=8B


--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/=
--001a11c003c0cc7a64050b8fcecc-- From nobody Wed Dec 31 20:51:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E00A1A1B40 for ; Wed, 31 Dec 2014 20:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.428 X-Spam-Level: * X-Spam-Status: No, score=1.428 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, FRT_ADOBE2=2.455, 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 8BVxe5ioNaB3 for ; Wed, 31 Dec 2014 20:51:01 -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 86D131A1B32 for ; Wed, 31 Dec 2014 20:51:01 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id f12so10413904qad.32 for ; Wed, 31 Dec 2014 20:51: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=L7sHv6PF5tmwO4L7BghNQADbzhTGbCNlniZdda6bjvY=; b=PZtBEYKNxqiDXPit3Di0s5VUC+oSBAI3M6ikCNKQjvL6rG6hdOTQuenfEdPf0K5V+l sP38Vwb9yxWQqLV0O830no/jvP9cf4V4cJzZWWGfwVFJg+ugFp6dPkIBIT6RQtVWgbXm G+bUdwunG0R9PGGGuX/RADQMuFRnw2cvY3A5swSHZkCSxzg9rI4D1yOKDiqjSJ+0js2N o2cJEGEbve9bNjjpIXQ5cLDWb+EBWZCYmW2HqoNT01wNQryrNngX2xNJ/XYew7FAQCqa HyOekmzXKwYLWSiNqiJW/Re1na0yvxslkLwa1QPqeJWQK7O7xDt5uY5xTJ2k5SPPlXZi T7cg== MIME-Version: 1.0 X-Received: by 10.224.25.139 with SMTP id z11mr80066247qab.17.1420087860638; Wed, 31 Dec 2014 20:51:00 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.86.163 with HTTP; Wed, 31 Dec 2014 20:51:00 -0800 (PST) In-Reply-To: References: Date: Thu, 1 Jan 2015 14:51:00 +1000 X-Google-Sender-Auth: 873IYAUmYL1IMeqt1ojTF_CWv2I Message-ID: From: Matthew Kerwin To: Larry Masinter Content-Type: multipart/alternative; boundary=047d7bea31c47bbccd050b8ff83c Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/brA2CLYtUxvdrNLCkNiRSV0qn4U 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: Thu, 01 Jan 2015 04:51:04 -0000 --047d7bea31c47bbccd050b8ff83c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 m= y > 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. =E2=80=8BCheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --047d7bea31c47bbccd050b8ff83c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 21 December 2014 at 05:55, Larry Masinter <masinter@adobe.com>= ; w= rote:
> This opens a call for= adoption for draft-kerwin-file-scheme, to be processed by APPSAWG.=C2=A0
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-archi= ve/web/apps-discuss/current/msg13462.html ). In general, APPSAWG should= n't take up URL-scheme permanent registrations? Or should it? This shou= ld 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 an= d messages to aggregate and process.

Regar= ding adoption of URL schemes by this WG, what alternatives would you propos= e? I could instead try to make it an individual submission, but this partic= ular scheme has a lot of political and emotional history, and there seems t= o be more and more work involved with developing the spec, so I'd rathe= r have much more buy-in through the whole process (such as you get from a w= orking 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 appropr= iate than here.

=E2=80= =8BCheers
--
=C2= =A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--047d7bea31c47bbccd050b8ff83c-- From nobody Wed Dec 31 22:14:39 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6FA1A0066; Wed, 31 Dec 2014 22:11:08 -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 KCa8Af6qXiGw; Wed, 31 Dec 2014 22:11:06 -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 D34031A005D; Wed, 31 Dec 2014 22:11:06 -0800 (PST) Received: from [192.168.6.2] (ip-64-134-16-147.public.wayport.net [64.134.16.147]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t016Awng019009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 31 Dec 2014 22:11:01 -0800 Message-ID: <54A4E4EB.2030809@dcrocker.net> Date: Wed, 31 Dec 2014 22:10:51 -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: "Murray S. Kucherawy" , Mark Nottingham References: <54A41D6C.9010501@ninebynine.org> <86C96FDF-9A48-43A3-B38A-468F4407AD82@mnot.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 31 Dec 2014 22:11:02 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/oQpuDQnAwGo2IpD9YM8MuXtcWUE Cc: "arcmedia@ietf.org" , Graham Klyne , Public TAG List , IETF Apps Discuss , Larry Masinter Subject: Re: [apps-discuss] Proposed charter for arcmedia 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 06:11:08 -0000 On 12/31/2014 8:24 PM, Murray S. Kucherawy wrote: > On Wed, Dec 31, 2014 at 4:59 PM, Mark Nottingham > wrote: > > … which isn’t yet final, BTW. > > > Here's the latest edit, based on today's feedback: > > https://github.com/mskucherawy/docs/blob/master/charter-arcmedia > > Anything else? I'll celebrate the new year by being uncharacteristically agreeable about the latest version. I'm sure it doesn't matter that you seem to have included all my suggested changes. HNY. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Dec 31 22:40:10 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855591A006F for ; Wed, 31 Dec 2014 22:37: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 Il98azE0tIZV for ; Wed, 31 Dec 2014 22:37:08 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A691A006D for ; Wed, 31 Dec 2014 22:37:07 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id bs8so27804272wib.3 for ; Wed, 31 Dec 2014 22:37:06 -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=FsFxUuxGglK0DEZbZEUxoFWgN8dl24nI+RAq9CBYN60=; b=LrrGeqjb/U6vmxhzB6KmMlMxclaGOS3JiMWzDCNg54Fn3Xg6WujLI7lQnmVrMYQfst u5HTsRupG8z8J0Gn8cZ5Ptj4+7qSBaG7G1AMvuhgavJXZ5HQ1tu664QBu0SyURe/BpYC Yt98oZFelzDRfP7o967dcrIQT3OVKMn0+8XTkOARRMoH/Q+5GnixYwoJeCjfJHKpbe4f DCfOlROw2zUECUSpte4Fywe0RifdRHEqe8th7ed4UsUJZn9Lp/vdXzG3e5hwDl1ZnjoX pcEtKJpKwzX/qSsRTe0ym8DvGrqt4TShp0Hx/VqP8aeiNr4UzwRM0pAwiNuxDrU8dnRi KScg== MIME-Version: 1.0 X-Received: by 10.180.75.199 with SMTP id e7mr122956992wiw.21.1420094226571; Wed, 31 Dec 2014 22:37:06 -0800 (PST) Received: by 10.27.204.198 with HTTP; Wed, 31 Dec 2014 22:37:06 -0800 (PST) In-Reply-To: References: Date: Wed, 31 Dec 2014 22:37:06 -0800 Message-ID: From: "Murray S. Kucherawy" To: Matthew Kerwin Content-Type: multipart/alternative; boundary=f46d04389577ec2770050b9173dd Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/OOSTmWWDGujkx4OYXui-gsRF9To 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 06:37:14 -0000 --f46d04389577ec2770050b9173dd Content-Type: text/plain; charset=UTF-8 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 --f46d04389577ec2770050b9173dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 31, 2014 at 8:51 PM, Matthew Kerwin <mat= thew@kerwin.net.au> wrote:
On 21 December 2014 at 05:55= , Larry Masinter <masinter@adobe.com> wrote:
> This opens a call for adoption for draft-kerwin-file-scheme, = to be processed by APPSAWG.=C2=A0

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-archi= ve/web/apps-discuss/current/msg13462.html ). In general, APPSAWG should= n't take up URL-scheme permanent registrations? Or should it? This shou= ld be addressed in the scheme registration BCP.


Sorry for not responding = sooner, I've been a bit overwhelmed with real life, and there's qui= te 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 t= ry to make it an individual submission, but this particular scheme has a lo= t of political and emotional history, and there seems to be more and more w= ork 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&#= 39;m not aware of any others that would be more appropriate than here.

The BCP for registering schem= es 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 r= egistered, or if Standards Track status seems to be worthwhile or even nece= ssary, then a working group (this one or a new one) makes sense.=C2=A0 On t= he other hand, if it's mostly just documenting and then registering som= ething already quite well understood, I think the independent stream is wor= th considering.=C2=A0 Even better: If the required documentation could simp= ly be included in the registration template, then just do that, and then th= ere's no need to produce an RFC through any stream.

An individua= l submission requires AD sponsorship, and I don't think this has been s= hopped to any ADs yet (has it?).

All that said, one of th= e 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.=C2=A0 = If we want to spin off a WG for it, that's for Barry to consider (anyon= e feel like writing a charter?).

All THAT said, Larry'= ;s earlier message (URI cited above) does still need a reply, I believe.=C2= =A0 If this draft does get adopted, that will be necessary before we can pr= ogress the document.

-MSK
--f46d04389577ec2770050b9173dd--