From nobody Sun Nov 1 19:30:50 2015 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 968831B32E3; Sun, 1 Nov 2015 19:30:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151102033047.12329.13925.idtracker@ietfa.amsl.com> Date: Sun, 01 Nov 2015 19:30:47 -0800 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-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: Mon, 02 Nov 2015 03:30:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ART Area General Applications Working Group Working Group of the IETF. Title : The file URI Scheme Author : Matthew Kerwin Filename : draft-ietf-appsawg-file-scheme-04.txt Pages : 20 Date : 2015-11-01 Abstract: This document specifies the "file" Uniform Resource Identifier (URI) scheme, obsoleting the definition in RFC 1738. It attempts to define a common core which is intended to interoperate across the broad spectrum of existing implementations, while at the same time documenting other current practices. Note to Readers (To be removed by the RFC Editor) This draft should be discussed on the IETF Applications Area Working Group discussion list . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-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 Sun Nov 1 19:50:13 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D841AD0C7 for ; Sun, 1 Nov 2015 19:50:11 -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 AzgAw292Oj0V for ; Sun, 1 Nov 2015 19:50:10 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E732F1AD0C6 for ; Sun, 1 Nov 2015 19:50:09 -0800 (PST) Received: by wijp11 with SMTP id p11so43135334wij.0 for ; Sun, 01 Nov 2015 19:50:08 -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=9cBz5dNt2MPxvEzbH8sw2gB9sDa1fzsvRYSj1WZhASk=; b=O2sNlDNIXO2Rc+ylbQWCrBAA42IZ4OVcDeZgAzatv1hB7HhI3BRPpiWSEsOymo1Fu+ CyjWXKgeRdPLHQE0JoSKjRWOJ+ZmjzyTX+kRVY00q4AIdU9cM8MJTrmo6fZEMA9UUibN XtVRFC453HmuzhwBNgfuRF8STiUwRk4fb+qItNVaxI0lki6PpmRLseMZP8AQQwAdTiBm 9QRYjY79756++V5e7nfzhEnmIlxAehWQQDGkcMWCC/BrQcS1esPmUSiixSr201LO3M/B lCIRJuX9l9RNEdVLX6JkOpuDhxz6p5XIFwLeU4sx78Sux0vwCp2GwDz2knjIx0WMc6Pj MueA== MIME-Version: 1.0 X-Received: by 10.194.60.179 with SMTP id i19mr20713452wjr.135.1446436208569; Sun, 01 Nov 2015 19:50:08 -0800 (PST) Received: by 10.27.175.104 with HTTP; Sun, 1 Nov 2015 19:50:08 -0800 (PST) Date: Mon, 2 Nov 2015 12:50:08 +0900 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7ba973ce66f0d5052386ac12 Archived-At: Subject: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 03:50:12 -0000 --047d7ba973ce66f0d5052386ac12 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Colleagues, This note starts a Working Group Last Call for draft-ietf-appsawg-file-scheme. This document has been with us for a while and feedback has fallen to a trickle. We've gotten all the feedback from W3C that we expect, so we'd like to move it toward publication. Please provide review comments or expressions of support for the current version either on this list or privately to draft-ietf-appsawg-file-scheme.all@tools.ietf.org on or before November 20, 2015. Be as detailed as possible. The co-chairs need to determine if the document has working group consensus, which means we need to know people have read the latest version and agree with its content and with the idea that it is ready to proceed. A simple =E2=80=9C+1=E2=80=9D doesn=E2=80=99t= tell us anything. Also, if any participant has knowledge of IPR that needs to be declared on this work, please do so, as required by BCPs 78 and 79. Dave Crocker is fulfilling the duties of document shepherd. -MSK, APPSAWG co-chair --047d7ba973ce66f0d5052386ac12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

This note starts a Working Group Last C= all for draft-ietf-appsawg-file-scheme.=C2=A0 This document has been with u= s for a while and feedback has fallen to a trickle.=C2=A0 We've gotten = all the feedback from W3C that we expect, so we'd like to move it towar= d publication.

Please provide review comments or expressions of supp= ort for the current version either on this list or privately to draft-ietf-appsaw= g-file-scheme.all@tools.ietf.org on or before November 20, 2015.=C2=A0 = Be as detailed as possible.=C2=A0 The co-chairs need to determine if the do= cument has working group consensus, which means we need to know people have= read the latest version and agree with its content and with the idea that = it is ready to proceed.=C2=A0 A simple =E2=80=9C+1=E2=80=9D doesn=E2=80=99t= tell us anything.

Also, if any participant has knowledge of IPR tha= t needs to be declared on this work, please do so, as required by BCPs 78 a= nd 79.

Dave Crocker is fulfilling the duties of document shepherd.
-MSK, APPSAWG co-chair
--047d7ba973ce66f0d5052386ac12-- From nobody Mon Nov 2 14:12:30 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BBD1A88BD for ; Mon, 2 Nov 2015 14:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNOHsRo0TYHL for ; Mon, 2 Nov 2015 14:12:28 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id D67431A88B6 for ; Mon, 2 Nov 2015 14:12:27 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PSN42BU89C0189JO@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 2 Nov 2015 14:07:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1446502044; bh=F6wwRX5Y+BEp27WAvWNSjoUKVmlfzQb3griGPlqJVdA=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=Oxifsh53as729LVUK+38BMed/t4KhCcZyrOwJ3FRo/SFctijEjAffR+tmS2Ti5h3D RyS3VcskxwoENdqAHMHzsknUPA7KGNOIg6mgh4MHmrsCvNbV6tGvgxjxa5JUGcbJd1 wbToPNt1/zPgefAszruXTXlZTymFL88P/um40UxU= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PSLDDS4JS001729W@mauve.mrochek.com>; Mon, 02 Nov 2015 14:07:22 -0800 (PST) Message-id: <01PSN42ACKJS01729W@mauve.mrochek.com> Date: Mon, 02 Nov 2015 13:42:06 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 02 Nov 2015 12:50:08 +0900" References: To: "Murray S. Kucherawy" Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 22:12:29 -0000 I scanned the document, and maybe I'm missing something obvious, but it looks to me like the material about the "authority" field is a bit mixed up. The document starts by importing the "authority" production from RFC 3986, but AFAICT never actually uses the production. That production is: authority = [ userinfo "@" ] host [ ":" port ] The reason it's not used is the [ ":" port ] part is unneeded and unwanted. (I think I agree with that assessment, but even so this difference from the generic syntax should be stated somwhere.) The production that's used instead is: file-auth = [ userinfo "@" ] host Which is a fine way to get rid of the unwanted optional port clause. But then the document speaks of things in terms of use or non-use of the "authority" field, when that field does not in fact appear in the file: URI ABNF. I can think of a bunch of different ways of addressing this problem, e.g., changing file-auth back to authority and noting the difference between it here and in RFC 3986, but since I'm not familiar with the document history and how it has arrived at this point it would be a bit presumptious of me to suggest a specific course of action. I also found the directions in section 3.1, "Translating Local File Path to file URI", regarding the authority field to be a bit confusing. Step 3 says: 3. If including an empty authority field, append the "//" sigil to the URI. No explanation given as to why I might - or might not - want to include an empty authority (file-auth) field. Some elaboration here would be nice. It also took me a minute to figure out that when the text talks about a local versus non-local file path, it's really talking about the sort of file: URL that's being output. The way I think of it is that you start with a local file path and either do or don't add host information to make it into a local or non-local file: URI. Or, to put it another way, while some systems, e.g. OpenVMS, have a special syntax for a "non-local file path", most systems don't. What you have instead is two (or more) separate pieces of information, usually a host name and absolute file path, that you then combine to create a non-local file: URI. In regards to this last I'm not actually advocating any change, mostly because I can't think a better way to say it, but I did want to make note of the potential issue. Ned From nobody Mon Nov 2 16:10:11 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957711A9155 for ; Mon, 2 Nov 2015 16:10:09 -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 8yhC0jnMEtit for ; Mon, 2 Nov 2015 16:10:07 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F6B1A916A for ; Mon, 2 Nov 2015 16:10:06 -0800 (PST) Received: by qkcn129 with SMTP id n129so274327qkc.1 for ; Mon, 02 Nov 2015 16:10:06 -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=ownepHVAVcReWJFi++fqSiD5WJo3pmtWhkuDXk0Knss=; b=h4sS3KQJ0MxYPQghsZdjC6F+8UpW2HpQZpSTil9CL86gDfPBPI+gqQAZd4+4oSH2Pv fhIxx0FfRNIaTcRpFkV0ZLSUgIpxk9hCGI6WzlcbTY+RykIfT3qXF91DmTfDYwPhf+8d a8aagIohGq0MZd5gMgsO8WcY+6yI4F5QlI9MBjtrK7ueZdDycLzLdfM2XBj1jfZgvuaC 4i1UPLCGjKO1MQlgCd62bLZ+Nt2GOlMZn9mNM2a8IVFu7yHop/bEAyfNWW2fpc1PuVW5 vHI26Pgby+njM3s2TgTKCdUo1gccMX/TNTkeTzxBU+KPpwDUjVPnYlVuVlGYdPCPIJzL ikCQ== MIME-Version: 1.0 X-Received: by 10.55.79.214 with SMTP id d205mr33655655qkb.22.1446509405305; Mon, 02 Nov 2015 16:10:05 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.55.70.76 with HTTP; Mon, 2 Nov 2015 16:10:05 -0800 (PST) In-Reply-To: <01PSN42ACKJS01729W@mauve.mrochek.com> References: <01PSN42ACKJS01729W@mauve.mrochek.com> Date: Tue, 3 Nov 2015 10:10:05 +1000 X-Google-Sender-Auth: 8jXX3AL__15Mju59bFwaD7WEiOE Message-ID: From: Matthew Kerwin To: Ned Freed Content-Type: multipart/alternative; boundary=001a114a8260448070052397b7b0 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-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, 03 Nov 2015 00:10:09 -0000 --001a114a8260448070052397b7b0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3 November 2015 at 07:42, Ned Freed wrote: > I scanned the document, and maybe I'm missing something obvious, but it > looks > to me like the material about the "authority" field is a bit mixed up. > > The document starts by importing the "authority" production from RFC 3986= , > but AFAICT never actually uses the production. That production is: > > authority =3D [ userinfo "@" ] host [ ":" port ] > > The reason it's not used is the [ ":" port ] part is unneeded and > unwanted. (I > think I agree with that assessment, but even so this difference from the > generic syntax should be stated somwhere.) > > The production that's used instead is: > > file-auth =3D [ userinfo "@" ] host > > Which is a fine way to get rid of the unwanted optional port clause. But > then > the document speaks of things in terms of use or non-use of the "authorit= y" > field, when that field does not in fact appear in the file: URI ABNF. > > =E2=80=8BYou're right, the text in Section 2 wasn't updated when the ABNF s= topped directly using the "authority" rule. I'll fix that up, and make sure the right things are imported. Throughout the document I used both "path" and "authority" to refer to functional components of the URI, rather than syntactic, even though both of those words are also used as ABNF rules in RFC 3986. If we remove the import, does that resolve the issue? (Would we then need a definition of "authority", or is the ref to RFC 3986 enough?) > I can think of a bunch of different ways of addressing this problem, e.g.= , > changing file-auth back to authority and noting the difference between it > here > and in RFC 3986, but since I'm not familiar with the document history and > how > it has arrived at this point it would be a bit presumptious of me to > suggest a > specific course of action. > > I also found the directions in section 3.1, "Translating Local File Path = to > file URI", regarding the authority field to be a bit confusing. Step 3 > says: > > 3. If including an empty authority field, append the "//" sigil to > the URI. > > No explanation given as to why I might - or might not - want to include a= n > empty authority (file-auth) field. Some elaboration here would be nice. > > =E2=80=8BHmm, yes. How about something in the relevant paragraph in section= 2, to the effect of: "To maximise compatibility with previous specifications, implementations MAY include an empty file-auth." ? Incidentally I just noticed another mistake; in that paragraph it says 'the "auth-path" rule can match...' instead of 'the "file-auth" rule...'. I've fixed that in github[1]=E2=80=8B. > It also took me a minute to figure out that when the text talks about a > local > versus non-local file path, it's really talking about the sort of file: U= RL > that's being output. The way I think of it is that you start with a local > file > path and either do or don't add host information to make it into a local = or > non-local file: URI. > > Or, to put it another way, while some systems, e.g. OpenVMS, have a speci= al > syntax for a "non-local file path", most systems don't. What you have > instead > is two (or more) separate pieces of information, usually a host name and > absolute file path, that you then combine to create a non-local file: URI= . > > In regards to this last I'm not actually advocating any change, mostly > because I can't think a better way to say it, but I did want to make note > of the potential issue. > > That's a fair observation. Yes, the distinction is between 'URIs with no authority, or a blank authority, or where the authority eq "localhost"' vs any others. I couldn't think of better names then "local" and "non-local." OpenVMS was an interesting case for me, because before that the only non-local paths I'd seen were SMB shares/UNC paths, which already look a bit like URLs. Since we're all living in hypervirtualised cloud-based distributed computing environments these days, I really tried not to talk about the actual location of the file; all I really wanted to know was "can you turn this URI into a Unix file path?" and the obvious signal for that, harking back to RFC 1738 (or even 1630) was whether there's a non-localhost "host" in the authority. Inversely, then, a "local file path" would be one that can be losslessly turned into a URI like "file:/path". This is purely syntactic, although it could become a bit more semantic if the question changes to "can you open() it?" I tried to sum that up in a single sentence in section 1.3, but that might not have been sufficient. ;) =E2=80=8B=E2=80=8B[1]: http://phluid61.github.io/internet-drafts/file-schem= e/=E2=80=8B --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a114a8260448070052397b7b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 3 November 2015 at 07:42, Ned Freed <ned.freed@m= rochek.com> wrote:
I scanned the document= , and maybe I'm missing something obvious, but it looks
to me like the material about the "authority" field is a bit mixe= d up.

The document starts by importing the "authority" production from = RFC 3986,
but AFAICT never actually uses the production. That production is:

=C2=A0 authority=C2=A0 =C2=A0 =C2=A0=3D [ userinfo "@" ] host [ &= quot;:" port ]

The reason it's not used is the [ ":" port ] part is unneeded= and unwanted. (I
think I agree with that assessment, but even so this difference from the generic syntax should be stated somwhere.)

The production that's used instead is:

=C2=A0 file-auth=C2=A0 =C2=A0 =C2=A0 =3D [ userinfo "@" ] host
Which is a fine way to get rid of the unwanted optional port clause. But th= en
the document speaks of things in terms of use or non-use of the "autho= rity"
field, when that field does not in fact appear in the file: URI ABNF.


=E2=80=8BYou're right, th= e text in Section 2 wasn't updated when the ABNF stopped directly using= the "authority" rule. I'll fix that up, and make sure the ri= ght things are imported.

Throughout the do= cument I used both "path" and "authority" to refer to f= unctional components of the URI, rather than syntactic, even though both of= those words are also used as ABNF rules in RFC 3986. If we remove the impo= rt, does that resolve the issue? (Would we then need a definition of "= authority", or is the ref to RFC 3986 enough?)
=C2=A0<= /div>
I can think of a bunch of different ways of addressing this problem, e.g.,<= br> changing file-auth back to authority and noting the difference between it h= ere
and in RFC 3986, but since I'm not familiar with the document history a= nd how
it has arrived at this point it would be a bit presumptious of me to sugges= t a
specific course of action.

I also found the directions in section 3.1, "Translating Local File Pa= th to
file URI", regarding the authority field to be a bit confusing. Step 3= says:

=C2=A03.=C2=A0 If including an empty authority field, append the "//&q= uot; sigil to
=C2=A0 =C2=A0 =C2=A0 =C2=A0the URI.

No explanation given as to why I might - or might not - want to include an<= br> empty authority (file-auth) field. Some elaboration here would be nice.


=E2=80=8BHmm, yes. How about = something in the relevant paragraph in section 2, to the effect of: "T= o maximise compatibility with previous specifications, implementations MAY = include an empty file-auth." ?

Incide= ntally I just noticed another mistake; in that paragraph it says 'the &= quot;auth-path" rule can match...' instead of 'the "file-= auth" rule...'. I've fixed that in github[1]=E2=80=8B.

=C2=A0
It also took me a minute to figure out that when the text talks about a loc= al
versus non-local file path, it's really talking about the sort of file:= URL
that's being output. The way I think of it is that you start with a loc= al file
path and either do or don't add host information to make it into a loca= l or
non-local file: URI.

Or, to put it another way, while some systems, e.g. OpenVMS, have a special=
syntax for a "non-local file path", most systems don't. What = you have instead
is two (or more) separate pieces of information, usually a host name and absolute file path, that you then combine to create a non-local file: URI.<= br>
In regards to this last I'm not actually advocating any change, mostly<= br> because I can't think a better way to say it, but I did want to make no= te
of the potential issue.


That's a fair observati= on. Yes, the distinction is between 'URIs with no authority, or a blank= authority, or where the authority eq "localhost"' vs an= y others. I couldn't think of better names then "local" and &= quot;non-local."

OpenVMS was an interesting case for me, because before that the only non= -local paths I'd seen were SMB shares/UNC paths, which already look a b= it like URLs. Since we're all living in hypervirtualised cloud-based di= stributed computing environments these days, I really tried not to talk abo= ut the actual location of the file; all I really wanted to know was = "can you turn this URI into a Unix file = path?" and the obvious signal for that, harking back to RFC 1738 (or e= ven 1630) was whether there's a non-localhost "host" in the a= uthority. Inversely, then, a "local file path" would be one that = can be losslessly turned into a URI like "file:/path". This is purely syntactic, although it could become a bit more semantic i= f the question changes to "can you open() it?"
<= div class=3D"gmail_default" style=3D"color:rgb(7,55,99)">
I tried to sum that up in a singl= e sentence in section 1.3, but that might not have been sufficient. ;)


=E2=80=8B=E2=80=8B[1= ]: http:= //phluid61.github.io/internet-drafts/file-scheme/=E2=80=8B

-- =
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a114a8260448070052397b7b0-- From nobody Mon Nov 2 22:52:54 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5866C1B2ECF for ; Mon, 2 Nov 2015 22:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziubFjNWjQCn for ; Mon, 2 Nov 2015 22:52:53 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 04C9B1B2EC6 for ; Mon, 2 Nov 2015 22:52:53 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PSNM8JY0340065OB@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 2 Nov 2015 22:47:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1446533269; bh=kpBlhqSBSHDYjDCoUNdauF8U0fD2Zr+Cc4Vn1WB0mtE=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=KQokUqdFWoRWMv0C0960jNWbt5n1uBKsKdIXTg63vjWW1cp253wNlFQOq30RxqVia 6oVphc6j4yqf0r+TDeL4ly3qTUZpKI0fici1BC/wvhVcqPJ33VZH8NCpEQc+QpmVAW isQWsnxU93wJShNbC8WJHAHUkZDwxBi95Apulibs= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=UTF-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PSLDDS4JS001729W@mauve.mrochek.com>; Mon, 02 Nov 2015 22:47:46 -0800 (PST) Message-id: <01PSNM8H9MCO01729W@mauve.mrochek.com> Date: Mon, 02 Nov 2015 22:44:59 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 03 Nov 2015 10:10:05 +1000" References: <01PSN42ACKJS01729W@mauve.mrochek.com> To: Matthew Kerwin Archived-At: Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-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, 03 Nov 2015 06:52:54 -0000 > On 3 November 2015 at 07:42, Ned Freed wrote: > > I scanned the document, and maybe I'm missing something obvious, but it > > looks > > to me like the material about the "authority" field is a bit mixed up. > > > > The document starts by importing the "authority" production from RFC 3986, > > but AFAICT never actually uses the production. That production is: > > > > authority = [ userinfo "@" ] host [ ":" port ] > > > > The reason it's not used is the [ ":" port ] part is unneeded and > > unwanted. (I > > think I agree with that assessment, but even so this difference from the > > generic syntax should be stated somwhere.) > > > > The production that's used instead is: > > > > file-auth = [ userinfo "@" ] host > > > > Which is a fine way to get rid of the unwanted optional port clause. But > > then > > the document speaks of things in terms of use or non-use of the "authority" > > field, when that field does not in fact appear in the file: URI ABNF. > > > > > ​You're right, the text in Section 2 wasn't updated when the ABNF stopped > directly using the "authority" rule. I'll fix that up, and make sure the > right things are imported. > Throughout the document I used both "path" and "authority" to refer to > functional components of the URI, rather than syntactic, even though both > of those words are also used as ABNF rules in RFC 3986. If we remove the > import, does that resolve the issue? No, not really. If anything it makes it worse, because now you're talking about something that's effectively undefined. > (Would we then need a definition of > "authority", or is the ref to RFC 3986 enough?) You need to link whatever term you use to the component of URL it refers to. > > I can think of a bunch of different ways of addressing this problem, e.g., > > changing file-auth back to authority and noting the difference between it > > here > > and in RFC 3986, but since I'm not familiar with the document history and > > how > > it has arrived at this point it would be a bit presumptious of me to > > suggest a > > specific course of action. > > > > I also found the directions in section 3.1, "Translating Local File Path to > > file URI", regarding the authority field to be a bit confusing. Step 3 > > says: > > > > 3. If including an empty authority field, append the "//" sigil to > > the URI. > > > > No explanation given as to why I might - or might not - want to include an > > empty authority (file-auth) field. Some elaboration here would be nice. > > > > > ​Hmm, yes. How about something in the relevant paragraph in section 2, to > the effect of: "To maximise compatibility with previous specifications, > implementations MAY include an empty file-auth." ? That sounds OK to me. Ned From nobody Tue Nov 3 12:21:08 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3C91B2DD9 for ; Mon, 2 Nov 2015 20:50:38 -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 jXsD54a-wtDx for ; Mon, 2 Nov 2015 20:50:36 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0620.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::620]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63FD81B2DEC for ; Mon, 2 Nov 2015 20:50:22 -0800 (PST) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1035.eurprd04.prod.outlook.com (10.162.26.144) with Microsoft SMTP Server (TLS) id 15.1.312.18; Tue, 3 Nov 2015 04:50:04 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) with mapi id 15.01.0312.014; Tue, 3 Nov 2015 04:50:04 +0000 From: Natasha Rooney To: "apps-discuss@ietf.org" Thread-Topic: SLIM Report Thread-Index: AQHRFfMbZLEq3SLBC0ufomgIzpNoWA== Date: Tue, 3 Nov 2015 04:50:04 +0000 Message-ID: <8F32CB3B-5A94-4517-8FF7-C4C0294EBEC9@gsma.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [133.93.38.240] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1035; 5:LlBq5Qic4kMZTssPcKdYMIO1gohoV7iVNDJgmMDb1wwgfSztB/EPRno4EMosy4E9MQAlN9i91yFxlHM1NyQc8QsQi95Ia8BrJkdgIrVM3U/Q/zV55oxaOsm6qkA8cmaq0zQAoAFaHaAKMl91P7QzvA==; 24:NG2Vs8FSLOQbL9dh7UfT+X1zjoyehQgVD2Ewis/KUkZWOexvhjm4EVaViCY3KMGfJ25sDgk9YCrUQhx1LPAwLYp9iDYHxnPe9ZRa3U84keI=; 20:bg+jILSAh5wh7lqzWeoJ0mpMBsRfsNDmCdVwSCPhKwoEZAQ4n6T/G/9Uh9T+ahtQaSatfZS1PFpnDByzd2mKQA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1035; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(260367931017790)(161861816099999); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:HE1PR04MB1035; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1035; x-forefront-prvs: 0749DC2CE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(189002)(199003)(5007970100001)(50226001)(5004730100002)(5890100001)(33656002)(77096005)(40100003)(5002640100001)(105586002)(106116001)(57306001)(36756003)(19580405001)(16236675004)(50986999)(82746002)(83716003)(2900100001)(106356001)(15975445007)(5001960100002)(102836002)(19580395003)(189998001)(107886002)(110136002)(92566002)(450100001)(87936001)(86362001)(19617315012)(221733001)(10400500002)(2501003)(229853001)(66066001)(81156007)(5008740100001)(97736004)(101416001)(11100500001)(2351001)(122556002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1035; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_8F32CB3B5A9445178FF7C4C0294EBEC9gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2015 04:50:04.8971 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1035 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 133.93.38.240 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1035.eurprd04.prod.outlook.com Archived-At: X-Mailman-Approved-At: Tue, 03 Nov 2015 12:21:06 -0800 Subject: [apps-discuss] SLIM Report X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 04:50:38 -0000 --_000_8F32CB3B5A9445178FF7C4C0294EBEC9gsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IHN1cmUgaWYgQVJUIGRvZXMgdGhlIHNhbWUgYXMgU0FBRyBidXQgSeKAmW0gc2VuZGluZyBh IFNMSU0gcmVwb3J0IHRvIEFSVCBqdXN0IGluIGNhc2UhOg0KDQpTTElNIGhhZCBpdOKAmXMgZmly c3QgbWVldGluZyB0aGlzIHdlZWsgKE1vbmRheSwgQWZ0ZXJub29uIFNlc3Npb24gSUlJKSBhZnRl ciBoYXZpbmcgb3VyIENoYXJ0ZXIgYXBwcm92ZWQgc29tZXRpbWUgaW4gdGhlIGxhc3QgbW9udGgu DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3NsaW0vY2hhcnRlci8NCg0KV2UgYWdy ZWVkIHRvIGFjY2VwdCBvdXIgdHdvIHByb3Bvc2VkIGRyYWZ0cyBhbmQgV0cgRG9jdW1lbnRzLiBP bmUgbG9va3MgaW50byB0aGUgc2VsZWN0aW9uIG9mIGxhbmd1YWdlIGluIHJlYWwgdGltZSB1c2Ug Y2FzZXMgYW5kIHRoZSBvdGhlciBsb29rcyBhdCBub24tcmVhbCB0aW1lIChzcGVjaWZpY2FsbHkg ZW1haWwpLiBMaW5rIGFuZCBkcmFmdHMgYXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy93Zy9zbGltL2RvY3VtZW50cy8NCg0KZHJhZnQtaWV0Zi1zbGltLW5lZ290aWF0aW5nLWh1bWFu LWxhbmd1YWdlLTAwDQpOZWdvdGlhdGluZyBIdW1hbiBMYW5ndWFnZSBpbiBSZWFsLVRpbWUgQ29t bXVuaWNhdGlvbnMNCg0KZHJhZnQtdG9ta2luc29uLXNsaW0tbXVsdGlsYW5nY29udGVudC0wMg0K TXVsdGlwbGUgTGFuZ3VhZ2UgQ29udGVudCBUeXBlDQoNCmRyYWZ0LXRvbWtpbnNvbi1zbGltLW11 bHRpbGFuZ2NvbnRlbnQtMDIgaGFzIGEgbGlzdCBvZiBjaGFuZ2VzIG9mIHdoaWNoIHRoZSBhdXRo b3JzIGFyZSB0YWNrbGluZyBub3cuIGRyYWZ0LWlldGYtc2xpbS1uZWdvdGlhdGluZy1odW1hbi1s YW5ndWFnZS0wMCBpcyB1bmRlcmdvaW5nIGEgdXNlIGNhc2UgZmVhc2liaWxpdHkgZGlzY3Vzc2lv biBvbiBtdWx0aSBtb2RhbGl0eS4gV2XigJlsbCB0YWtlIHRoZXNlIGl0ZW1zIHRvIHRoZSBsaXN0 Lg0KDQpUaGFua3MhDQoNCk5hdGFzaGENCg0KDQpOYXRhc2hhIFJvb25leSB8IFRlY2hub2xvZ2lz dCwgV2ViIGFuZCBJbnRlcm5ldCwgVzNDICYgSUVURiB8IEdTTUEgfCBucm9vbmV5QGdzbWEuY29t PG1haWx0bzpucm9vbmV5QGdzbWEuY29tPiB8ICs0NCAoMCkgNzczMCAyMTkgNzY1IHwgQHRoaXNO YXRhc2hhIHwgU2t5cGU6IG5yb29uZXlAZ3NtLm9yZzxtYWlsdG86bnJvb25leUBnc20ub3JnPg0K VG9reW8sIEphcGFuDQoNCg0KDQpUaGlzIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGlu dGVuZGVkIGZvciB0aGUgYWJvdmUgbmFtZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4g SWYgdGhleSBoYXZlIGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9u IGJhc2VkIG9uIHRoZW0sIG5vciBtdXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7 IHBsZWFzZSByZXBseSB0byB0aGlzIGVtYWlsIG9yIGNhbGwgKzQ0IDIwNyAzNTYgMDYwMCBhbmQg aGlnaGxpZ2h0IHRoZSBlcnJvci4NCg== --_000_8F32CB3B5A9445178FF7C4C0294EBEC9gsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: <9AEA6AFC7D8E74418C926B74C12084FC@eurprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KTm90IHN1cmUgaWYgQVJUIGRvZXMg dGhlIHNhbWUgYXMgU0FBRyBidXQgSeKAmW0gc2VuZGluZyBhIFNMSU0gcmVwb3J0IHRvIEFSVCBq dXN0IGluIGNhc2UhOg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+U0xJTSBoYWQgaXTigJlzIGZpcnN0IG1lZXRpbmcgdGhpcyB3ZWVrIChNb25kYXks IEFmdGVybm9vbiBTZXNzaW9uIElJSSkgYWZ0ZXIgaGF2aW5nIG91ciBDaGFydGVyIGFwcHJvdmVk IHNvbWV0aW1lIGluIHRoZSBsYXN0IG1vbnRoLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3NsaW0vY2hhcnRlci8iIGNsYXNzPSIi Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvc2xpbS9jaGFydGVyLzwvYT48YnIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVy Ij4NCjwvZGl2Pg0KPGRpdiBhcHBsZS1jb250ZW50LWVkaXRlZD0idHJ1ZSIgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBi cmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazog YWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCldlIGFncmVlZCB0byBhY2NlcHQgb3VyIHR3 byBwcm9wb3NlZCBkcmFmdHMgYW5kIFdHIERvY3VtZW50cy4gT25lIGxvb2tzIGludG8gdGhlIHNl bGVjdGlvbiBvZiBsYW5ndWFnZSBpbiByZWFsIHRpbWUgdXNlIGNhc2VzIGFuZCB0aGUgb3RoZXIg bG9va3MgYXQgbm9uLXJlYWwgdGltZSAoc3BlY2lmaWNhbGx5IGVtYWlsKS4gTGluayBhbmQgZHJh ZnRzIGFyZTo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdl YmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9zbGltL2RvY3VtZW50cy8iIGNsYXNzPSIi Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvc2xpbS9kb2N1bWVudHMvPC9hPjwvZGl2 Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3Jh cDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJl YWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB3aWRvd3M6IGF1dG87IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNw LW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xh c3M9IiI+DQpkcmFmdC1pZXRmLXNsaW0tbmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UtMDAmbmJz cDs8YnIgY2xhc3M9IiI+DQpOZWdvdGlhdGluZyBIdW1hbiBMYW5ndWFnZSBpbiBSZWFsLVRpbWUm bmJzcDtDb21tdW5pY2F0aW9uczxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCmRyYWZ0LXRv bWtpbnNvbi1zbGltLW11bHRpbGFuZ2NvbnRlbnQtMDImbmJzcDs8YnIgY2xhc3M9IiI+DQpNdWx0 aXBsZSBMYW5ndWFnZSBDb250ZW50IFR5cGU8L2Rpdj4NCjxkaXYgc3R5bGU9Im9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB3aWRvd3M6IGF1dG87IHdv cmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxp bmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB3aWRvd3M6IGF1dG87IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtp dC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNl OyIgY2xhc3M9IiI+DQpkcmFmdC10b21raW5zb24tc2xpbS1tdWx0aWxhbmdjb250ZW50LTAyIGhh cyBhIGxpc3Qgb2YgY2hhbmdlcyBvZiB3aGljaCB0aGUgYXV0aG9ycyBhcmUgdGFja2xpbmcgbm93 LiBkcmFmdC1pZXRmLXNsaW0tbmVnb3RpYXRpbmctaHVtYW4tbGFuZ3VhZ2UtMDAgaXMgdW5kZXJn b2luZyBhIHVzZSBjYXNlIGZlYXNpYmlsaXR5IGRpc2N1c3Npb24gb24gbXVsdGkgbW9kYWxpdHku IFdl4oCZbGwgdGFrZSB0aGVzZSBpdGVtcyB0byB0aGUgbGlzdC4mbmJzcDs8L2Rpdj4NCjxkaXYg c3R5bGU9Im9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB3aWRvd3M6IGF1dG87IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6 IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB3aWRvd3M6IGF1dG87IHdvcmQtd3JhcDog YnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpUaGFua3MhPC9kaXY+DQo8ZGl2IHN0eWxl PSJvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgd2lk b3dzOiBhdXRvOyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFj ZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KTmF0YXNoYTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCk5hdGFzaGEgUm9vbmV5IHwgVGVjaG5vbG9naXN0LCBXZWIgYW5kIEludGVybmV0LCBX M0MgJmFtcDsgSUVURiB8Jm5ic3A7R1NNQSB8IDxhIGhyZWY9Im1haWx0bzpucm9vbmV5QGdzbWEu Y29tIiBjbGFzcz0iIj4NCm5yb29uZXlAZ3NtYS5jb208L2E+IHwgJiM0Mzs0NCAoMCkmbmJzcDs3 NzMwIDIxOSA3NjUgfCBAdGhpc05hdGFzaGEgfCBTa3lwZTombmJzcDs8YSBocmVmPSJtYWlsdG86 bnJvb25leUBnc20ub3JnIiBjbGFzcz0iIj5ucm9vbmV5QGdzbS5vcmc8L2E+Jm5ic3A7PGJyIGNs YXNzPSIiPg0KVG9reW8sIEphcGFuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPHAgc3R5bGU9ImZvbnQtZmFtaWx5OiBB cmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB4O2NvbG9yOiM5OTk5OTk7Ij48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCxzYW5zLXNlcmlmO2NvbG9yOiM5OTk5 OTk7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWZhcmVhc3QtdGhlbWUtZm9u dDogbWlub3ItbGF0aW47IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAmcXVvdDtBcmlhbCZxdW90Ozsg bXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogRU4tR0I7IG1z by1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+VGhpcw0KIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMg YXJlIGludGVuZGVkIGZvciB0aGUgYWJvdmUgbmFtZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVu dGlhbC4gSWYgdGhleSBoYXZlIGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8g YWN0aW9uIGJhc2VkIG9uIHRoZW0sIG5vciBtdXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBh bnlvbmU7IHBsZWFzZSByZXBseSB0byB0aGlzIGVtYWlsIG9yIGNhbGwgJiM0Mzs0NCAyMDcgMzU2 IDA2MDANCiBhbmQgaGlnaGxpZ2h0IHRoZSBlcnJvci4gPC9zcGFuPjwvcD4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_8F32CB3B5A9445178FF7C4C0294EBEC9gsmacom_-- From nobody Tue Nov 3 16:51:42 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B673A1A700A for ; Tue, 3 Nov 2015 16:51:40 -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 DyZlidM--bqq for ; Tue, 3 Nov 2015 16:51:40 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D549D1A6F53 for ; Tue, 3 Nov 2015 16:51:39 -0800 (PST) Received: by ioll68 with SMTP id l68so38324268iol.3 for ; Tue, 03 Nov 2015 16:51:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oIG4ZVHKXMLtZSmAw2n6NL/xWN5qU5YpArqAA3b2qaM=; b=Y4lTBF9iny3NZbz3UkRUR54ztPIk0KG44CXAbed/903DN3hLLlHj6QATbHTUEQ7BTt vdu4Kv6VcNa9EF1Ml23VMkYekwsill3VG42AU1R7OftFu8BDQ8zIG9lfooQOhwj4HFUy X6x35WbV9UVUT2lvAs4kstebakThlcVURbVyDFQHNOFYVeojay89qgLh29QsUkRzDWVE 8PJ/ujhORcq45+MCsxGzolzYteGIBvJ9SJ1k5fTFIo5019QWQ39FdgfemRFA2Dp1E/BT RBDD0jQK/PuYIB1zoCl8I8SDsMtbZixGXvQdm6hdsghWZwjbILTExnmJgevbs6perkwz /pEQ== MIME-Version: 1.0 X-Received: by 10.107.137.202 with SMTP id t71mr46143ioi.119.1446598299297; Tue, 03 Nov 2015 16:51:39 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.181.202 with HTTP; Tue, 3 Nov 2015 16:51:39 -0800 (PST) Date: Wed, 4 Nov 2015 01:51:39 +0100 X-Google-Sender-Auth: cL84owbN70Yb8FAKVNIeHB-Gk1M Message-ID: From: Barry Leiba To: Natasha Rooney Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] Working group session reports X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Nov 2015 00:51:40 -0000 Natasha said... > Not sure if ART does the same as SAAG but I=E2=80=99m sending a SLIM repo= rt > to ART just in case! I think such reports are a fine thing, and very much encourage them. I did try asking for them explicitly for a meeting or two, with mixed results; perhaps we can try again. So I'll ask ART chairs, at least those for whose working groups I'm responsible (but others can do it too), to post brief session reports to apps-discuss this week, in the interest of better communication. Note "ask", not "require" -- please do try to find a few minutes to do it. Thanks, Barry From nobody Mon Nov 9 18:17:59 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFBE1B2CEC for ; Mon, 9 Nov 2015 18:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 t5xEvHr4JLCF for ; Mon, 9 Nov 2015 18:17:57 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7F11B2CCC for ; Mon, 9 Nov 2015 18:17:54 -0800 (PST) Received: from pool-173-76-33-163.bstnma.fios.verizon.net ([173.76.33.163] helo=[192.168.1.152]) by raoul.w3.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZvyVM-000Ehr-1v; Tue, 10 Nov 2015 02:17:52 +0000 To: apps-discuss@ietf.org From: Wendy Seltzer X-Enigmail-Draft-Status: N1110 Organization: W3C Message-ID: <564153CD.3010108@w3.org> Date: Mon, 9 Nov 2015 21:17:49 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Chris Lilley Subject: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 02:17:59 -0000 As discussed at the DISPATCH meeting last week, we propose this draft charter for a WG with the sole purpose of defining the "font" top-level media type, with input from the W3C WebFonts WG. http://datatracker.ietf.org/doc/charter-ietf-justfont/ Thanks, --Wendy, proposed co-chair, with Mark Nottingham -- Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office) Policy Counsel and Domain Lead, World Wide Web Consortium (W3C) http://wendy.seltzer.org/ +1.617.863.0613 (mobile) From nobody Tue Nov 10 00:25:31 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153301A87EE for ; Tue, 10 Nov 2015 00:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ai9wCKPBUuoQ for ; Tue, 10 Nov 2015 00:25:28 -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 B14931A87E7 for ; Tue, 10 Nov 2015 00:25:27 -0800 (PST) Received: (qmail 50081 invoked from network); 10 Nov 2015 08:25:26 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Nov 2015 08:25:26 -0000 Date: 10 Nov 2015 08:25:04 -0000 Message-ID: <20151110082504.64458.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <564153CD.3010108@w3.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 08:25:29 -0000 In article <564153CD.3010108@w3.org> you write: >As discussed at the DISPATCH meeting last week, we propose this draft >charter for a WG with the sole purpose of defining the "font" top-level >media type, with input from the W3C WebFonts WG. > > http://datatracker.ietf.org/doc/charter-ietf-justfont/ > >Thanks, >--Wendy, proposed co-chair, with Mark Nottingham I realize it goes against the modern IETF way not to nitpick this, but it's fine. Ship it, and we can do the work. R's, John From nobody Tue Nov 10 01:01:51 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF081B2DBD for ; Tue, 10 Nov 2015 01:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNLI2EUu0hRb for ; Tue, 10 Nov 2015 01:01:48 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id AC3BF1B2B3C for ; Tue, 10 Nov 2015 01:01:48 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PSXIRUKAA8001BFR@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 10 Nov 2015 00:56:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1447145806; bh=R0ZjkhHobqa5e9uxe1CmHRua6ERKOI7A2y42rKbX4kU=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=ows6qnM/GQmWqniWA6rb+zBfc94MDuSpnTZDYNnPrcCy8V9q/NRC2V6vLfNBbwN0r aTu9D2hGyd0Q8IuoWDnbIUoyM0P9W8nVQ+F9Duq9tZW4O1m9gLRmX7TaAokoNuR7WZ jpSa8cMudvD/DzWj7reQFqRP7Q6oB62FcXp+4eW0= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PSXB005A6801729W@mauve.mrochek.com>; Tue, 10 Nov 2015 00:56:44 -0800 (PST) Message-id: <01PSXIRT1PN001729W@mauve.mrochek.com> Date: Tue, 10 Nov 2015 00:53:47 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 09 Nov 2015 21:17:49 -0500" <564153CD.3010108@w3.org> References: <564153CD.3010108@w3.org> To: Wendy Seltzer Archived-At: Cc: Chris Lilley , apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 09:01:50 -0000 > As discussed at the DISPATCH meeting last week, we propose this draft > charter for a WG with the sole purpose of defining the "font" top-level > media type, with input from the W3C WebFonts WG. > http://datatracker.ietf.org/doc/charter-ietf-justfont/ What's there is fine, and given the high quality of the starting draft, it's really all you need. While I personally prefer charters that simply describe what a group is going to do, experience has shown that justification for the activity needs to be part of it. As such, I think it may be a good idea to copy some of the justification for the top-level font type from draft-lilley-font-toplevel, or maybe a pointer to that justification text is sufficient. Ned From nobody Tue Nov 10 01:16:37 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E941B3492 for ; Tue, 10 Nov 2015 01:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8KWiD-5MB-n for ; Tue, 10 Nov 2015 01:16:30 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0125.outbound.protection.outlook.com [104.47.124.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5AC61B3490 for ; Tue, 10 Nov 2015 01:16:28 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS2PR01MB0140.jpnprd01.prod.outlook.com (10.161.77.148) with Microsoft SMTP Server (TLS) id 15.1.318.15; Tue, 10 Nov 2015 09:16:25 +0000 To: Ned Freed , Wendy Seltzer References: <564153CD.3010108@w3.org> <01PSXIRT1PN001729W@mauve.mrochek.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <5641B5E0.4050307@it.aoyama.ac.jp> Date: Tue, 10 Nov 2015 18:16:16 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <01PSXIRT1PN001729W@mauve.mrochek.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR06CA0040.apcprd06.prod.outlook.com (25.164.91.50) To OS2PR01MB0140.jpnprd01.prod.outlook.com (25.161.77.148) X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0140; 2:6pvURRgglp1hrkYho0FKkgtA4Z8sRPfSs1FRzG8ubNRfhSm1MIvGb2vKDoR0z6Kc386/O48YuzWVanGAr4heEAhyp+Z4i5WDeisACqXikw7lJKE3Bdy/GDPlOJpMi9T8wFhX+xSvS/SUM6lQ+jL972abpc4/7mx5CSXczm3GP+U=; 3:MvP5qHl1+X9P4yG084TpN3azxCK8TWVSTFMI04oeffY1uHgjkw7K4po0u1PJKb6/9yCISGtv7siOyjcmBW8NXX+WgVkASdveKaiFcw3fz5L/c5g6k3ULRtorGiq7CXU1RKOeGVYcQr50eEMTjLiZfw==; 25:D4nx1lUtllrBZZGyfj9kWC1AG7IGH5UBYMh2KmmHQjNktia7nuNmNtUsGZBfj6ltCxGBp7O5N5Vr/M/sRhSlzaLEavcysGsXk8WSbR8EWzvJkMYNFerhWAtKPqzjyTJW/HtLtKz9aiZVdxX1n92UFoaWwpoTkEugjExu3trSclmGn4dLML0F81FBe4G8H7Okqj7854Lr7yox/ITdhpSW8lmFUMEUJDgzFpjcuaOSOg9AtNUI8XAZ0g5oVEY8RosyEVkH8AwpeYznzrAjaYcKoA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS2PR01MB0140; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046); SRVR:OS2PR01MB0140; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0140; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0140; 4:lA71RKe7uQ/OMFry53sIvKmRGUisRqhWhG8bdjRC5ZAJIugw8T3hFvnNEoyIZw457RPJKdjmIxZLSKDo+ine0XKBNcbvXrV+mXMlFZ8tR99iYOne/WH5A8IKndI4P1SBvDolOy0jfY9BCC/3c73Ifhj2kfK/GcCN5ye+V4l3/xDR0Zl0MTD1o9/bWYAWJC90SnXtFcqAow4SHXPojsX92ZAR/1GrfWgidrFmFF1V4NQA5J8kxTv3A0B5UTYEN+ZiLanrxiC3iSuDPmvi+3SOkIjw53cdKDo/ToSTzJtNj8PxW8J4GYM11+ovRRwHahNttGlG5C53uKEvGc2di1BAevwdSr/0WjtKKza8mAt5q8KnsxMtwso4IkgJq7Rixb78 X-Forefront-PRVS: 07562C22DA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(479174004)(24454002)(199003)(189002)(50986999)(42186005)(92566002)(40100003)(54356999)(86362001)(47776003)(105586002)(65956001)(80316001)(66066001)(23676002)(65806001)(74482002)(106356001)(59896002)(189998001)(5001770100001)(101416001)(19580395003)(15975445007)(97736004)(2950100001)(122386002)(50466002)(5007970100001)(5008740100001)(77096005)(65816999)(76176999)(230700001)(87976001)(33656002)(5001960100002)(5004730100002)(83506001)(4001350100001)(87266999)(64126003)(81156007)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0140; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxTUIwMTQwOzIzOlVFaThhNFJOTXdoYmRhcTdMNVUyUndUMUNW?= =?utf-8?B?aGQ1Vk1OTTV1cnZ6ZVRjc284SS9YV1dPdnd4Ny9FcXVBQy9rcThZR25YS3RK?= =?utf-8?B?VnVVVGhybjZ6b0svOFZJYXIyU0xXRHdyU242WEVWRHM3ZWZyWGFHUjd2akVr?= =?utf-8?B?SHRBdTN5cjhLejN2V0VNMUg3V1JHMVNSa1FnNjY0aVpNNEVCcW5QSDBKc2x4?= =?utf-8?B?SkJ5M0NrYWJGV1JsS21NcUNGVnZ2SjllbDA3Vmczd3JPcDREQmJsNi9kT3Vn?= =?utf-8?B?SytZN0xQYTVzK2VCQVBabjlYM0RQR2JSbTNVaHJ5SlZ0Nk5rWi9neFJPK0Zy?= =?utf-8?B?R3NrY21SVGlNSThocEdsVkpaQVBuYzhXdU9McEVObkVmSlhuTHdQbmNRY25Q?= =?utf-8?B?b2p4alE5TXloaW9ETHIzWEd1aVpKY0pRT3BIRTFLWGQ1bzVOVXg0Mkc5dk9V?= =?utf-8?B?Wi92RmRoaWNDbERsNlhKYThGNU4vQXZtMTZHMWVETzRiTEhzNjBBa2RWVElY?= =?utf-8?B?cGRhbXVITU4vZ1lqUXhmNEs3UG03ZldUYm5JSHNQVkRsMGFNcDUvTll4Mml5?= =?utf-8?B?M2V2a1FnaEJ5Nk15T3VxMFlpZncyVmFaU0RjaHBxSFpnTXdqTGxSdGRSQTJl?= =?utf-8?B?Ri9TWFdCcEYrSmpyWG9abG1vYjFjeEErbEg3T2Y1d1F3bHJQZklvTHpwekxW?= =?utf-8?B?bmdGOFZla1dOckdqV25YT1ZYdi92TlNTSEMxcHhsekh6cVY2Y1BMN3FudU9m?= =?utf-8?B?VzUzMzYvNnVwVFdPZEhSZ3lLZExSbDIzSU1hbkY4RmkzZDBFN2VZbWNSb1J3?= =?utf-8?B?SG9abXc1YTlwd21uUGFzRTdBdUZSdElYUWJFcGlPQjBTSnJtOHEwVjg4aUlP?= =?utf-8?B?TkFKeHlYUWd3L3BmTU1Ycmo5YnFwV1NxcnNyNVdualFGbG5tYlI5aVFzMDl0?= =?utf-8?B?MWp6VlVkTEFIWFFObFhNbUdnNnhFSm5CMHVtUUhtYUdYbmFLd2RUOE96ZFRK?= =?utf-8?B?RmlzN2d4d3ErdjBNRktsYnV5clc2U2J5NC9lTjRzakhxbjR3VGZCcjFQVnJa?= =?utf-8?B?NUJoTHFIZjZ2aHpSRUZENmM2Q2hzbnVMZUJoRHhxSlZEQ0RCSTArZ0xPOHRx?= =?utf-8?B?OVlYZEpLejBKaXZFZDlxNHFwWWR3NWtTS2U5RmdHUGtXaDFkTTF2ZjNpWXBP?= =?utf-8?B?TG1JdU92Vzd2OENDbGZNWFpVbnVHb0hjeTJWbjBzbk1QNG43TVcrTzBlbnh2?= =?utf-8?B?cnlwNHZvaVM0a0VPd2xNUmFqVmZrMThMbTRSbEJFc2NhUjF2ZGdueU9mVGY1?= =?utf-8?B?UVRhTmVhL2dZUjRyVVc4T09yeCtaeG03TmVpYko4eUVpcCtLaWNYbmx5UjF0?= =?utf-8?B?UktkcVoyZ3B2VVBPcG9IRi9udUpUYVE2b2pUcjJMQjROSkZ5RGVRblM2bUZ5?= =?utf-8?B?K0o0a1lkVjNzRHZQOElrQVQxYTR5SVBXT0pkcWxOK1VPMDRaMWhDek0rUVFU?= =?utf-8?B?VHFnaERURXQxdm5wL2ZUc29hSjgzc2VRV2pyb0NjLzhrckFMblFDanAvTkVE?= =?utf-8?B?V1BZZFcxUjRRTHJvSWhMQWc5ZitLOHJCS0lTWE5iS1FRbjlkV2lNZ0FMM21M?= =?utf-8?B?ZnpHMTFPL1ZoSi9MbmRhaEFseW9XRUpNNjFQMFF4Tk5CaWxyaER2S2hYajhs?= =?utf-8?Q?6l6iCUMUqKgqGpLRRQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0140; 5:nxq9FdX3JeA9PrAYUep0IoGcXdp9ou75HKNwQPSv89ash7FfX+ApUcvq5UzL48KkrWHSLz/WuXHt7Wi2RaPd0f//plmiR4kcfqTK7bRD6f9g4KxfI9OK6RQzNvvVxldYKJQxcl7i08a/bisjswsTdQ==; 24:/th/xZQrht11wKQUOtC594YY+BsCK4i2YE7il+znheccujRMUKfzo7amzvpJFgVBE7Qmn75iAEaQ9BpmFD45eOO50R6LSOsYuKSqEiNbu0A=; 20:xAr6x4xz6Pzxp1h/VUtY96El3OkSnLgbZsT2IQMYZ77L3oeGa+onQcfuDiOAEtfp2uPAEpVenTPxF/16+1qi3Q== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2015 09:16:25.0076 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0140 Archived-At: Cc: Chris Lilley , apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 09:16:36 -0000 On 2015/11/10 17:53, Ned Freed wrote: >> As discussed at the DISPATCH meeting last week, we propose this draft >> charter for a WG with the sole purpose of defining the "font" top-level >> media type, with input from the W3C WebFonts WG. > >> http://datatracker.ietf.org/doc/charter-ietf-justfont/ > > What's there is fine, and given the high quality of the starting draft, it's > really all you need. > > While I personally prefer charters that simply describe what a group is going > to do, experience has shown that justification for the activity needs to be > part of it. As such, I think it may be a good idea to copy some of the > justification for the top-level font type from draft-lilley-font-toplevel, or > maybe a pointer to that justification text is sufficient. I agree with Ned on all points. For the record, I also plan to participate in this WG and to review the draft. Regards, Martin. From nobody Tue Nov 10 04:14:55 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821BF1A911B for ; Tue, 10 Nov 2015 04:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7Us_xWTzMGZT for ; Tue, 10 Nov 2015 04:14:52 -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 041521A90DA for ; Tue, 10 Nov 2015 04:14:52 -0800 (PST) Received: from [192.168.111.103] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id DA930C40675; Tue, 10 Nov 2015 06:14:50 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1447157690; bh=HIaxUhM6FYXy1+Z1SSfSP1iA6GXRtfNzDCNyuP8sR+c=; h=In-Reply-To:References:Subject:From:Date:To:From; b=NCQRuz2AfCxB0EdwSOKPMduw6A+Ud84toAnahr4UqO18qrDwUqZ+j2FY5Siva4bWJ +uM7Jhif5V7sALkqHtTXN4vd5TuHFVpb3v0yBl20Z0y2jytf6eOmVFFn9QtKHf9dTh dgUE0/rbXa+QvnkG00ih8wDe6Ss9wEyNB596108s= User-Agent: K-9 Mail for Android In-Reply-To: <564153CD.3010108@w3.org> References: <564153CD.3010108@w3.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Tue, 10 Nov 2015 07:14:49 -0500 To: apps-discuss@ietf.org Message-ID: <11E3E0CE-BD47-4E34-AE24-470DABA6DC98@kitterman.com> Archived-At: Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 12:14:53 -0000 On November 9, 2015 9:17:49 PM EST, Wendy Seltzer wrote: >As discussed at the DISPATCH meeting last week, we propose this draft >charter for a WG with the sole purpose of defining the "font" top-level >media type, with input from the W3C WebFonts WG. > > http://datatracker.ietf.org/doc/charter-ietf-justfont/ It seems to me like a lot of process overhead for a small effort, but if I take it as a given this needs a whole working group, what's written seems fine. Scott K From nobody Tue Nov 10 06:23:46 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176791B2B44 for ; Tue, 10 Nov 2015 06:23:44 -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 DhL9PtrYpBS1 for ; Tue, 10 Nov 2015 06:23:42 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AFAA1B2B3D for ; Tue, 10 Nov 2015 06:23:42 -0800 (PST) Received: from [192.168.123.105] (unknown [75.83.2.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6B603509C1; Tue, 10 Nov 2015 09:23:39 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_D9A60FB9-65A9-4F20-B908-61B349C7DD07"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <11E3E0CE-BD47-4E34-AE24-470DABA6DC98@kitterman.com> Date: Tue, 10 Nov 2015 06:22:15 -0800 Message-Id: <776938B4-A6AE-47FE-9834-CBEB365A6E8D@seantek.com> References: <564153CD.3010108@w3.org> <11E3E0CE-BD47-4E34-AE24-470DABA6DC98@kitterman.com> To: IETF Apps Discuss X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Scott Kitterman Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 14:23:44 -0000 --Apple-Mail=_D9A60FB9-65A9-4F20-B908-61B349C7DD07 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 10, 2015, at 4:14 AM, Scott Kitterman = wrote: > On November 9, 2015 9:17:49 PM EST, Wendy Seltzer = wrote: >> As discussed at the DISPATCH meeting last week, we propose this draft >> charter for a WG with the sole purpose of defining the "font" = top-level >> media type, with input from the W3C WebFonts WG. >>=20 >> http://datatracker.ietf.org/doc/charter-ietf-justfont/ >=20 > It seems to me like a lot of process overhead for a small effort, but = if I take it as a given this needs a whole working group, what's written = seems fine. For the purpose of defining a font top-level media type, it=92s ok, but = a bit too top-heavy. I would also request that the archive top-level media type be included = in the WG scope. I recall that the W3C web-packaging effort was = interested in that as well. This will make the work more meaty while = keeping it focused on the primary standardization effort. Based on past experience, it is better to keep the initial work tightly = focused on getting the top-level media type(s) registered. Areas of = commonality, including: * common parameters * common fragment identifiers * lots of subtypes while interesting, risk a high degree of bike-shedding, and are best = defined as follow-on topics. I would rather see =93font=94 (and = =93archive=94) RFCs published quickly and *then* the WG getting bogged = down in minutiae, than the WG getting bogged down in minutiae that = prevents these top-level types from making it through. For example, = draft-lilley-font-toplevel-00 has a lot of registrations with optional = parameters like =93Layout=94 and =93Outlines=94, which I perceive to be = rather superfluous (and unlikely to be supplied anyway). The model type got through [RFC2077] but the meat of it is really short: = just 7 pages (excluding references, appendices, and author matter). By the way: draft-lilley-font-toplevel-00 uses the term =93primary = content type=94, which appears to be outdated. [RFC6838] refers to that = thing as =93top-level media type=94. I believe we should stick to the = right term. Sean --Apple-Mail=_D9A60FB9-65A9-4F20-B908-61B349C7DD07 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUxMTEwMTQyMzQ1WjAjBgkqhkiG9w0BCQQxFgQUj33EB4EIgweWq2JQr0LWzaT8rcYwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAF+YIYzIgXU59oPRUlapVU0KZcARw+AL6BO0m2uXmbscRG03VUNg32LWzuzClC6Sf7Dk GFX757OwiEeQFN0dVTIPvzv4rSLxK4qojqAYZUo+PS3ywUYL/Rv6WRgqVM+kgN3h6/ncCYbWlJlf GsmPjvnMi6KYf22Edm13u7gOrvUe4fsxe5yDu41wq1dT5bOVU9qt/B8A6wI54NA+Rqaa9QgJShYC zJAWd5XvMSG0O5qH2vDOyzKXApahfTAM5DZ7NCn9yYAqt9tkiWL6RmnStTkoR9IfF4CjAjSrHY0x tyaFlynMTyj4abdllfiPVRTzHTrvaOpxneVMpatTgW87564AAAAAAAA= --Apple-Mail=_D9A60FB9-65A9-4F20-B908-61B349C7DD07-- From nobody Tue Nov 10 06:47:26 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FAA1B2C56 for ; Tue, 10 Nov 2015 06:47:24 -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 YrJksBktCa-a for ; Tue, 10 Nov 2015 06:47:24 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4EEE1B2C53 for ; Tue, 10 Nov 2015 06:47:23 -0800 (PST) Received: by ioc74 with SMTP id 74so2768320ioc.2 for ; Tue, 10 Nov 2015 06:47:23 -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=pIFdJKcMmP4AJD+8ivMWLBBts2f+sCQknIKenrRX9e4=; b=Vy+2o6N99UCOBShlrYn6B3UERweI7GJI451K/SjNHbOAAoubng8VvqXuzI0HsmLzR9 8h+HS6AWryTIjNfYtI2BycCX8K7Etghj9KEdbWEScyOf+7sDeBXjOBz2hlxAeGbr2wzb pAUUpAeRzRe7biX57j086XjTRRXD0795PJmRit06EO8pv7X0yuw6OqgMJtdxsHO1Pl/y pKARzeFmaXg2nVojvw5wY3Dyq67kN0yefRvry81LzyhehwNP44SbjQuka6QhdouDng+3 5oeCDRO25hLd50AXOceSeAb8Mnr7XKEjnO5PAfx3RdXBLdYZIDtS+xCaDQ2cjYLT0xlP L3Og== MIME-Version: 1.0 X-Received: by 10.107.16.144 with SMTP id 16mr4845028ioq.119.1447166843203; Tue, 10 Nov 2015 06:47:23 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.181.202 with HTTP; Tue, 10 Nov 2015 06:47:23 -0800 (PST) In-Reply-To: <776938B4-A6AE-47FE-9834-CBEB365A6E8D@seantek.com> References: <564153CD.3010108@w3.org> <11E3E0CE-BD47-4E34-AE24-470DABA6DC98@kitterman.com> <776938B4-A6AE-47FE-9834-CBEB365A6E8D@seantek.com> Date: Tue, 10 Nov 2015 09:47:23 -0500 X-Google-Sender-Auth: TzFSSyV5OBpUmloGHDvvW7rhhJ4 Message-ID: From: Barry Leiba To: Sean Leonard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Scott Kitterman , IETF Apps Discuss Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 14:47:25 -0000 > I would also request that the archive top-level media type be included > in the WG scope. I have a very strong inclination NOT to do that (though I will accept consensus, of course). We tried that; there wasn't enough interest and energy to get anywhere with it. I do not want to saddle this work with that, and I strongly prefer a tightly focused working group. Barry, ART Director From nobody Tue Nov 10 06:54:10 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C681B37C8 for ; Tue, 10 Nov 2015 06:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-T7IhEyBjXG for ; Tue, 10 Nov 2015 06:54:08 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01BCB1B37CE for ; Tue, 10 Nov 2015 06:54:06 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ZwAJ7-000INe-3w; Tue, 10 Nov 2015 09:54:01 -0500 Date: Tue, 10 Nov 2015 09:53:56 -0500 From: John C Klensin To: Barry Leiba , Sean Leonard Message-ID: <033DCB88277E4A0A4BCE332B@JcK-HP8200.jck.com> In-Reply-To: References: <564153CD.3010108@w3.org> <11E3E0CE-BD47-4E34-AE24-470DABA6DC98@kitterman.com> <776938B4-A6AE-47FE-9834-CBEB365A6E8D@seantek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Scott Kitterman , IETF Apps Discuss Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 14:54:09 -0000 FWIW, +1 john --On Tuesday, November 10, 2015 09:47 -0500 Barry Leiba wrote: >> I would also request that the archive top-level media type be >> included in the WG scope. > > I have a very strong inclination NOT to do that (though I will > accept consensus, of course). We tried that; there wasn't > enough interest and energy to get anywhere with it. I do not > want to saddle this work with that, and I strongly prefer a > tightly focused working group. From nobody Tue Nov 10 13:53:04 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323241B4029 for ; Tue, 10 Nov 2015 13:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqjApKVxg7AX for ; Tue, 10 Nov 2015 13:53:02 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3A81B4027 for ; Tue, 10 Nov 2015 13:53:02 -0800 (PST) Received: by igcph11 with SMTP id ph11so60132774igc.1 for ; Tue, 10 Nov 2015 13:53:01 -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=ZL53QKuD/mafZK5W9Uxtf6b3ybjJX2yA9qVYQTOz+ts=; b=cxoXUfGcSQLtJjwccmOLizw5Sp0BPYymoclLb4jwDJNqj206y2/WVdZITt7nKkfeNO RgK+1SJhj0I8LaxGTxLx5HdBfJMX8D7yc3DXB3JhNFFj1asVWzH9eiFz45kju05r2UON H0HLrlq+ZM8KzX1VrGiRp2Az/T7rvvxA0Z9QVjWM33oiPQ5mL3Fc1ZO4xJi5V78EddDK M/roDx4C3RDS01E2nbAmOlwFaKlSsLJSzHCZr2WL5ttRe0H8YE5naB4rwZRdmm1omuGc Nrs/vVHDLVr4Av7/BwCUFZMh7qhqm8WZWfX9sG6LVSIgt8fPwA6QQqZM+5bhmXEYPJTI fd2A== MIME-Version: 1.0 X-Received: by 10.50.117.5 with SMTP id ka5mr6587997igb.58.1447192381479; Tue, 10 Nov 2015 13:53:01 -0800 (PST) Received: by 10.36.155.139 with HTTP; Tue, 10 Nov 2015 13:53:01 -0800 (PST) In-Reply-To: References: <564153CD.3010108@w3.org> <11E3E0CE-BD47-4E34-AE24-470DABA6DC98@kitterman.com> <776938B4-A6AE-47FE-9834-CBEB365A6E8D@seantek.com> Date: Tue, 10 Nov 2015 13:53:01 -0800 Message-ID: From: Martin Thomson To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Scott Kitterman , IETF Apps Discuss Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 21:53:03 -0000 On 10 November 2015 at 06:47, Barry Leiba wrote: >> I would also request that the archive top-level media type be included >> in the WG scope. > > I have a very strong inclination NOT to do that (though I will accept > consensus, of course). We tried that; there wasn't enough interest > and energy to get anywhere with it. I do not want to saddle this work > with that, and I strongly prefer a tightly focused working group. I agree with Barry. Keep the tight focus. Then separately consider archive/*. From nobody Tue Nov 10 15:22:45 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7381B435E for ; Tue, 10 Nov 2015 15:22:43 -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 jXYmGHXpXe65 for ; Tue, 10 Nov 2015 15:22:42 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7FD1B435C for ; Tue, 10 Nov 2015 15:22:42 -0800 (PST) Received: by qgeb1 with SMTP id b1so11654836qge.1 for ; Tue, 10 Nov 2015 15:22:41 -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=3RnCMYfe7Qhf2MXse7DAXCebgaUtVQnolIgbM7UuWE0=; b=ZHy0TC/nEUyL3h5lYptqapf8iHaFgVKuggF6lMiY1u+8xDsoSXVw4LCICeGHFXMm8t nSaHWzEmr5a0xc99o2FnuCVikWo85CZFTsvU+Zn63oUvqaRK7NS0gUImz7YqoFslx9Gf IoZmFVqAjBgNXwYBZpBPIsLsfXN5bi7f9pmwgh0iB5syB0W9yAzTIZoWdWd712HVll9u uRnUiZ4G8oY1ia3IB+7S0ekfYs6LibM8zBF2exbqpZI5D0/y6FSG3oofsZKhnDPeTyfg lSVoGvCubDJMLkTRIbvRFPq9rV/10OfauiZUuZEVBqGaQO1MRqc3xJlI+JFE2hFj8lCN 9D6Q== MIME-Version: 1.0 X-Received: by 10.140.82.49 with SMTP id g46mr7916670qgd.32.1447197761353; Tue, 10 Nov 2015 15:22:41 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.55.184.129 with HTTP; Tue, 10 Nov 2015 15:22:41 -0800 (PST) In-Reply-To: References: <564153CD.3010108@w3.org> <11E3E0CE-BD47-4E34-AE24-470DABA6DC98@kitterman.com> <776938B4-A6AE-47FE-9834-CBEB365A6E8D@seantek.com> Date: Wed, 11 Nov 2015 09:22:41 +1000 X-Google-Sender-Auth: 5Jq4btihtNriB6peHR5h2OiETDM Message-ID: From: Matthew Kerwin To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c116027c400e052437fce9 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 23:22:44 -0000 --001a11c116027c400e052437fce9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11 November 2015 at 07:53, Martin Thomson wrote: > On 10 November 2015 at 06:47, Barry Leiba wrote= : > >> I would also request that the archive top-level media type be included > >> in the WG scope. > > > > I have a very strong inclination NOT to do that (though I will accept > > consensus, of course). We tried that; there wasn't enough interest > > and energy to get anywhere with it. I do not want to saddle this work > > with that, and I strongly prefer a tightly focused working group. > > I agree with Barry. Keep the tight focus. Then separately consider > archive/*. > > =E2=80=8B*reconsider. We gave it a go, then all support evaporated. This font/* proposal seems to have more drive and more widespread support, so will probably work better. Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11c116027c400e052437fce9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 11 November 2015 at 07:53, Martin Thomson <martin.thomson@gmai= l.com> wrote:
On 10 November= 2015 at 06:47, Barry Leiba <= barryleiba@computer.org> wrote:
>> I would also request that the archive top-level media type be incl= uded
>> in the WG scope.
>
> I have a very strong inclination NOT to do that (though I will accept<= br> > consensus, of course).=C2=A0 We tried that; there wasn't enough in= terest
> and energy to get anywhere with it.=C2=A0 I do not want to saddle this= work
> with that, and I strongly prefer a tightly focused working group.

I agree with Barry.=C2=A0 Keep the tight focus.=C2=A0 Then separatel= y consider archive/*.

<= br>
=E2=80=8B*reconsider. We gave it a go= , then all support evaporated. This
font/*
proposal seems to have= more drive and more widespread support, so will probably work better.

Cheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a11c116027c400e052437fce9-- From nobody Tue Nov 10 17:03:23 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E10F1ACE2F for ; Tue, 10 Nov 2015 17:03:22 -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 AVdBCxgg8-zQ for ; Tue, 10 Nov 2015 17:03:20 -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 6D9301ACE1F for ; Tue, 10 Nov 2015 17:03:20 -0800 (PST) Received: from [192.168.0.16] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2A80622E25F for ; Tue, 10 Nov 2015 20:03:12 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: Date: Wed, 11 Nov 2015 12:03:09 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <564153CD.3010108@w3.org> <11E3E0CE-BD47-4E34-AE24-470DABA6DC98@kitterman.com> <776938B4-A6AE-47FE-9834-CBEB365A6E8D@seantek.com> To: IETF Apps Discuss X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 01:03:22 -0000 +1 > On 11 Nov 2015, at 8:53 am, Martin Thomson = wrote: >=20 > On 10 November 2015 at 06:47, Barry Leiba = wrote: >>> I would also request that the archive top-level media type be = included >>> in the WG scope. >>=20 >> I have a very strong inclination NOT to do that (though I will accept >> consensus, of course). We tried that; there wasn't enough interest >> and energy to get anywhere with it. I do not want to saddle this = work >> with that, and I strongly prefer a tightly focused working group. >=20 > I agree with Barry. Keep the tight focus. Then separately consider = archive/*. >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham https://www.mnot.net/ From nobody Tue Nov 10 17:31:16 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130D31B2CFF for ; Tue, 10 Nov 2015 17:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWHVBQpUn84k for ; Tue, 10 Nov 2015 17:31:13 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A0651B2CFB for ; Tue, 10 Nov 2015 17:31:13 -0800 (PST) Received: from [10.59.2.104] (unknown [206.214.36.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E4DF8509BF for ; Tue, 10 Nov 2015 20:31:11 -0500 (EST) From: Sean Leonard Content-Type: multipart/signed; boundary="Apple-Mail=_A5911E56-53C0-453B-B2EA-6683A20C1CEF"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <2BEAD659-98EA-4DA4-9B45-5FC92A03392A@seantek.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Tue, 10 Nov 2015 17:29:58 -0800 References: <564153CD.3010108@w3.org> <11E3E0CE-BD47-4E34-AE24-470DABA6DC98@kitterman.com> <776938B4-A6AE-47FE-9834-CBEB365A6E8D@seantek.com> To: IETF Apps Discuss In-Reply-To: X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 01:31:15 -0000 --Apple-Mail=_A5911E56-53C0-453B-B2EA-6683A20C1CEF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 10, 2015, at 1:53 PM, Martin Thomson = wrote: > On 10 November 2015 at 06:47, Barry Leiba = wrote: >>> I would also request that the archive top-level media type be = included >>> in the WG scope. >>=20 >> I have a very strong inclination NOT to do that (though I will accept >> consensus, of course). We tried that; there wasn't enough interest >> and energy to get anywhere with it. I do not want to saddle this = work >> with that, and I strongly prefer a tightly focused working group. >=20 > I agree with Barry. Keep the tight focus. Then separately consider = archive/*. All right, fine. But when we say tight focus, just keep it as much as = possible on the top-level media type registration. I see =93making initial registrations in "font"=94 to be a possible = black hole. I also see defining common parameters (or ways to = accommodate them) between "font" registrations, also to be a black hole. = Black hole =3D likely to derail tight focus. Part of this is because there is no common data format congruence within = the proposed font types, so Section 4 of draft-00 says =93Unrecognized = sub-types of "font" should be treated as "application/octet-stream".=94 = Then it says =93Implementations may pass unrecognized subtypes to a = common font-handling system, if such system is available.=94 The idea of a top-level media type is that if TYPE/SUBTYPE handling is = not available, TYPE handling should be done first. Sometimes TYPE =3D> = TYPE/defaultsubtype, i.e., text/plain. All text/* types can be read by a = text/plain viewer, although you=92ll get=85raw text. The question is, is = there a common format to font/* such as font/sfnt, such that all fonts = can be treated as font/sfnt and not get total garbage? If you can open = all fonts in a truly generic font viewer where you see tables of data = (even if the data is inscrutable), then that is not garbage. (I submit that there is no commonality. In the exemplary registrations, = font/sfnt ~ font/otf ~ font/ttf but !=3D font/woff. That is because WOFF = is compressed. Maybe I don=92t understand the commonality of the data = formats. And what about PostScript Type 1 fonts such as .pfb?) The sooner we can declare that there is no commonality in data format, = the tighter we can make the scope and the sooner the WG can finish its = work. Sean= --Apple-Mail=_A5911E56-53C0-453B-B2EA-6683A20C1CEF Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUxMTExMDEzMTAyWjAjBgkqhkiG9w0BCQQxFgQUJlC5kO1XWQHIIyQggzFTHIWHJEwwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAE3bIzWb79HCkjF+wTbrnv4F0uzGGxzAuQem1tfyDAphMlrgIMmeZT3jUOxdco/OHevO eNTInk3zTMZ/+Rp2ncI2n9rcBsuUcvYa14JDxZl5rFHmxOr9Dnwf+9R450R49juXyzyxLLzgO4GI ZAr2apyTus8UIqeZ3V63G+qJxXUR7hKuRzokCGH8k50s+bvRBJXuMvy+TqLSGx3vKRZWKwQL1RQx ygQkAgE7x6V/r9M1h4jDvF37RTkv7iU0L8OfWCQy+pMxP809+WkCOgE63Eu0eeD5BGayEQ64arCz zTjuFcX69mYUktHXIfwgPv8yzzGTopZQtyOQ+lSAFPZJp1AAAAAAAAA= --Apple-Mail=_A5911E56-53C0-453B-B2EA-6683A20C1CEF-- From nobody Tue Nov 10 17:57:39 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDF01B4605 for ; Tue, 10 Nov 2015 17:57:38 -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 Qi2x-O15mC1a for ; Tue, 10 Nov 2015 17:57:36 -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 97B7D1B4603 for ; Tue, 10 Nov 2015 17:57:36 -0800 (PST) Received: from [192.168.0.16] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5C9A722E25F; Tue, 10 Nov 2015 20:57:29 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: <2BEAD659-98EA-4DA4-9B45-5FC92A03392A@seantek.com> Date: Wed, 11 Nov 2015 12:57:26 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <564153CD.3010108@w3.org> <11E3E0CE-BD47-4E34-AE24-470DABA6DC98@kitterman.com> <776938B4-A6AE-47FE-9834-CBEB365A6E8D@seantek.com> <2BEAD659-98EA-4DA4-9B45-5FC92A03392A@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 01:57:38 -0000 Hi Sean, > On 11 Nov 2015, at 12:29 pm, Sean Leonard = wrote: >=20 >=20 > On Nov 10, 2015, at 1:53 PM, Martin Thomson = wrote: >=20 >> On 10 November 2015 at 06:47, Barry Leiba = wrote: >>>> I would also request that the archive top-level media type be = included >>>> in the WG scope. >>>=20 >>> I have a very strong inclination NOT to do that (though I will = accept >>> consensus, of course). We tried that; there wasn't enough interest >>> and energy to get anywhere with it. I do not want to saddle this = work >>> with that, and I strongly prefer a tightly focused working group. >>=20 >> I agree with Barry. Keep the tight focus. Then separately consider = archive/*. >=20 > All right, fine. But when we say tight focus, just keep it as much as = possible on the top-level media type registration. >=20 > I see =93making initial registrations in "font"=94 to be a possible = black hole. I also see defining common parameters (or ways to = accommodate them) between "font" registrations, also to be a black hole. = Black hole =3D likely to derail tight focus. Can you justify these statements, or are they just a "feeling"? > Part of this is because there is no common data format congruence = within the proposed font types, so Section 4 of draft-00 says = =93Unrecognized sub-types of "font" should be treated as = "application/octet-stream".=94 Then it says =93Implementations may pass = unrecognized subtypes to a common font-handling system, if such system = is available.=94 >=20 > The idea of a top-level media type is that if TYPE/SUBTYPE handling is = not available, TYPE handling should be done first. Sometimes TYPE =3D> = TYPE/defaultsubtype, i.e., text/plain. All text/* types can be read by a = text/plain viewer, although you=92ll get=85raw text. The question is, is = there a common format to font/* such as font/sfnt, such that all fonts = can be treated as font/sfnt and not get total garbage? If you can open = all fonts in a truly generic font viewer where you see tables of data = (even if the data is inscrutable), then that is not garbage. >=20 > (I submit that there is no commonality. In the exemplary = registrations, font/sfnt ~ font/otf ~ font/ttf but !=3D font/woff. That = is because WOFF is compressed. Maybe I don=92t understand the = commonality of the data formats. And what about PostScript Type 1 fonts = such as .pfb?) >=20 > The sooner we can declare that there is no commonality in data format, = the tighter we can make the scope and the sooner the WG can finish its = work. Sure. So, why does that lead you to think that we should up-front = constrain the charter to preclude initial registrations and common = parameters? I also want to push back on folks who seem to be saying "look, archive/* = just failed; this faces the same risks." This is a completely different = community and set of use cases; just because it shares of the trivial = property of "being a top-level media type" does not mean that it's = doomed to failure.=20 Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Nov 10 22:31:45 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6C61B2C0D for ; Tue, 10 Nov 2015 22:31:45 -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, MANGLED_MARKET=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIcGomrlrx-j for ; Tue, 10 Nov 2015 22:31:43 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350451B2C04 for ; Tue, 10 Nov 2015 22:31:43 -0800 (PST) Received: from [192.168.123.105] (unknown [75.83.2.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 18B24509BE; Wed, 11 Nov 2015 01:31:40 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_3FC7F5CD-53FB-4AD7-97FA-E53B4AEB14A4"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: Date: Tue, 10 Nov 2015 22:30:47 -0800 Message-Id: References: <564153CD.3010108@w3.org> <11E3E0CE-BD47-4E34-AE24-470DABA6DC98@kitterman.com> <776938B4-A6AE-47FE-9834-CBEB365A6E8D@seantek.com> <2BEAD659-98EA-4DA4-9B45-5FC92A03392A@seantek.com> To: Mark Nottingham X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 06:31:45 -0000 --Apple-Mail=_3FC7F5CD-53FB-4AD7-97FA-E53B4AEB14A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Mark et. al., On Nov 10, 2015, at 5:57 PM, Mark Nottingham wrote: > Hi Sean, >=20 >> On 11 Nov 2015, at 12:29 pm, Sean Leonard = wrote: >>=20 >>=20 >> On Nov 10, 2015, at 1:53 PM, Martin Thomson = wrote: >>=20 >>> On 10 November 2015 at 06:47, Barry Leiba = wrote: >>>>> I would also request that the archive top-level media type be = included >>>>> in the WG scope. >>>>=20 >>>> I have a very strong inclination NOT to do that (though I will = accept >>>> consensus, of course). We tried that; there wasn't enough interest >>>> and energy to get anywhere with it. I do not want to saddle this = work >>>> with that, and I strongly prefer a tightly focused working group. >>>=20 >>> I agree with Barry. Keep the tight focus. Then separately consider = archive/*. >>=20 >> All right, fine. But when we say tight focus, just keep it as much as = possible on the top-level media type registration. >>=20 >> I see =93making initial registrations in "font"=94 to be a possible = black hole. I also see defining common parameters (or ways to = accommodate them) between "font" registrations, also to be a black hole. = Black hole =3D likely to derail tight focus. >=20 > Can you justify these statements, or are they just a "feeling=94? Because that is where some of the effort for archive, and as I gather = for prior top-level media types (looking from the e-mail history), got = derailed. Aside from my personal inability to drive conversation at that = time (not necessary to detail), a lot of ideas or things were proposed = for archive such as common parameters and in particular common fragment = identifier syntax, that required additional effort to survey the myriad = of archive types out there. I started to do that survey but it=92s a big = job and wasn=92t able to complete it in time for another draft. I sort of assume that fragment identifier syntax is not needed for = fonts. If so, explicitly declaring fragment identifiers as out-of-scope = will help keep focus. One could naturally devise some kind of fragment = syntax but that would be a great example of where we have agreement on = focus before the WG starts; therefore, the effort won=92t get = sidetracked by that. >=20 >> Part of this is because there is no common data format congruence = within the proposed font types, so Section 4 of draft-00 says = =93Unrecognized sub-types of "font" should be treated as = "application/octet-stream".=94 Then it says =93Implementations may pass = unrecognized subtypes to a common font-handling system, if such system = is available.=94 >>=20 >> The idea of a top-level media type is that if TYPE/SUBTYPE handling = is not available, TYPE handling should be done first. Sometimes TYPE =3D> = TYPE/defaultsubtype, i.e., text/plain. All text/* types can be read by a = text/plain viewer, although you=92ll get=85raw text. The question is, is = there a common format to font/* such as font/sfnt, such that all fonts = can be treated as font/sfnt and not get total garbage? If you can open = all fonts in a truly generic font viewer where you see tables of data = (even if the data is inscrutable), then that is not garbage. >>=20 >> (I submit that there is no commonality. In the exemplary = registrations, font/sfnt ~ font/otf ~ font/ttf but !=3D font/woff. That = is because WOFF is compressed. Maybe I don=92t understand the = commonality of the data formats. And what about PostScript Type 1 fonts = such as .pfb?) >>=20 >> The sooner we can declare that there is no commonality in data = format, the tighter we can make the scope and the sooner the WG can = finish its work. >=20 > Sure. So, why does that lead you to think that we should up-front = constrain the charter to preclude initial registrations and common = parameters? I think that constraining the charter will make it more focused. I am = not precluding initial registrations but I am asking for more precision. Specifically right now the scope (based on draft-00) seems too = Web-focused. Fonts apply to a lot more than the Web. For example, = (e)mail interests and printing interests should be represented. A start = would be to include PostScript Type 1 fonts (tip: there are actually a = large number of PostScript types). Other types that come to mind include = TeX font metric (TFM, .tfm), Spline Font Database (.sfd), Apple Advanced = Typography (AAT), and Graphite (by SIL). On the mail side, it would be very nice to use @font-face in HTML email: = the status quo is to render text with nice fonts in graphics that are = sliced into HTML4 table cells (which in turn promotes the pervasive use = of =93web bugs=94, i.e., server-hosted images that leak exactly when and = where a user opens an email). However, the security considerations loom = large on that one. Note that these types do not need to be registered--only acknowledged. = And by comparing all of these types, it is hopefully clearer that it is = hard to find any parameters that are in common between all of them. On the other hand, the top-level media type could be =93webfont=94 which = more explicitly states the bias. >=20 > I also want to push back on folks who seem to be saying "look, = archive/* just failed; this faces the same risks." This is a completely = different community and set of use cases; just because it shares of the = trivial property of "being a top-level media type" does not mean that = it's doomed to failure.=20 For my part I would like to see font/* succeed. But you raise an = important point because the WG ought to incorporate the needs of all = font communities, not just this particular community that promoted this = current draft. If you look at draft-singer-font-mime-00 from October = 2004, you will note a distinct difference in focus, as evidenced in = proposed parameters like =93font-name=94. Sean= --Apple-Mail=_3FC7F5CD-53FB-4AD7-97FA-E53B4AEB14A4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUxMTExMDYzMTQxWjAjBgkqhkiG9w0BCQQxFgQUu+Zi6ezGnYOEqxPhj/yQ6Ud7n8gwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAFKiuI+E8uQy3MigNh2V5tJFbRKdIjZYl6tem7auTGJkvNdG4pLNRf+sAQzSWBDXGSHH 7SHLJ/3EFsGAg8pqOFzNGZE0c1tAaYV65gBAzFNyTBIsWgTGdUpgoDs9uJQLD9HSy1PNv5nA9odM Z1+YT1M5QnILNboJDPLcamQ+AHwbez+fwadEJO86n6y49e7m/c+l3dFSlkuuG2PoUiDIypbWrzKx 8hwZ2J3aWamnQ8XxSsbkLzPwhvZvE/dhtUAFA4V92EM4tb/1ROMe7RLYBiB46ium42HNd6oeTQWY Jvuo85LDbjMXaTIogb8tHRUVPVMpZc42npvc5L+6BAjkbuEAAAAAAAA= --Apple-Mail=_3FC7F5CD-53FB-4AD7-97FA-E53B4AEB14A4-- From nobody Tue Nov 10 23:04:10 2015 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2FC1B317B for ; Tue, 10 Nov 2015 23:04:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151111070409.19195.52268.idtracker@ietfa.amsl.com> Date: Tue, 10 Nov 2015 23:04:09 -0800 From: IETF Secretariat Archived-At: Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 07:04:09 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-text-markdown", resolved as "Done". Changed milestone "Publication requested for draft-ietf-appsawg-text-markdown-use-cases", resolved as "Done". Changed milestone "Publication requested for draft-ietf-appsawg-http-problem", set due date to December 2015 from April 2015. Changed milestone "Publication requested for draft-ietf-appsawg-rfc7001bis", set due date to December 2015 from April 2015, resolved as "Done". Changed milestone "Publication requested for draft-ietf-appsawg-file-scheme", set due date to December 2015 from July 2015. Changed milestone "Publication requested for draft-ietf-appsawg-mdn-3798bis", set due date to December 2015 from July 2015. URL: https://datatracker.ietf.org/wg/appsawg/charter/ From nobody Wed Nov 11 00:53:27 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0797C1B3427 for ; Wed, 11 Nov 2015 00:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLIpMRVVbOud for ; Wed, 11 Nov 2015 00:53:23 -0800 (PST) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0113.outbound.protection.outlook.com [104.47.125.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB711A854C for ; Wed, 11 Nov 2015 00:53:20 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS2PR01MB0137.jpnprd01.prod.outlook.com (10.161.77.145) with Microsoft SMTP Server (TLS) id 15.1.318.15; Wed, 11 Nov 2015 08:53:16 +0000 To: Sean Leonard , Mark Nottingham References: <564153CD.3010108@w3.org> <11E3E0CE-BD47-4E34-AE24-470DABA6DC98@kitterman.com> <776938B4-A6AE-47FE-9834-CBEB365A6E8D@seantek.com> <2BEAD659-98EA-4DA4-9B45-5FC92A03392A@seantek.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <564301F5.4050203@it.aoyama.ac.jp> Date: Wed, 11 Nov 2015 17:53:09 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: KAWPR01CA0023.jpnprd01.prod.outlook.com (25.161.24.33) To OS2PR01MB0137.jpnprd01.prod.outlook.com (25.161.77.145) X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0137; 2:ARug1VA51UzhtM/0v62MVjsYiIHwWuCBi5djNWWhsxE27otuukrsur1u3kqWfgnZonvuMR73VRFfNpSju2nIaZeOQHL8zhspmXb/RcETB/vpjDWkCaekIK1w6sZcs7/WsIiUWpci26J8teQISQMvta6qgnChZ2SIXNyf3wi10ts=; 3:EI56gRDK/Yue9CNDk1GEqOW82QLWY+FLla1buvlnUVZddYbxY+zJ7xq0wDWq3y2OzMbdjNoDbGlYap0Ab7me+NMNNqTXk3D2S3AggMw8EbDA8LhiySe4SRTdotDjZLHaRFw2n6l1+FzDCka+URvWFw==; 25:lzvuSHP+B7IOsBUP2eRjLgkixyFHOo77xTNkSte9EY139yP7+NL1huE9o3R40Mq2Qnv4DKiuLz10EGqBLk7/a5lgCCwAgGlh0D5+6GAGOxKuJAgedgpwONNpJoy8VAHJSEgSkIQ/XYEABDDO3bJZFrnlO6jO2D8RsF4xvHd1Jat4iYt3c1tQU/iBK7frl4yZvWR36qew2qGSLTi+C9B0EDJ7O2F997Vg8Dt2mW4AClkI0vjms/I9f6bTOlpRwjEuweDg7s7AFw81ZX+alGwt5Q== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS2PR01MB0137; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046); SRVR:OS2PR01MB0137; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0137; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0137; 4:jtVVy0aw1ll8Gc8MJlfgNTq49qC+bw9fynH2M6Od+X6TrP3TlzaLl6qzmJGRpF7aGm4XR3W+ToMp0okAfQy1zqGDAUMdjepm07VJu+cLq1xEPjYQYrzNoha4C3SSe/lLuQojUbCa6ZtoR1yNBnxsYS5FewnTBiWb//tgm/JdV+ryQzogvOX3sP08KFxHhVFDKgKvTOhGJAFeM0hg3EbIManRwpNFRa32FQJN0wy+ThEieZMreLH01tzwgbtyIR6LwzyaGNKR3s8jrhhVaLTFvs7noba2oBcZDYIXuozZ6KtUCK5DXW4Ued6KiE94/7SSXUyddF58Xk28KJlhhzlOrF7vJJC/Uxu/qtvVpJ0gB360owGaGgx8rqYr2orMxLM4 X-Forefront-PRVS: 0757EEBDCA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(24454002)(479174004)(189002)(51444003)(199003)(50466002)(122386002)(54356999)(87266999)(5001960100002)(189998001)(77096005)(92566002)(81156007)(5001770100001)(74482002)(5004730100002)(59896002)(93886004)(42186005)(5007970100001)(2950100001)(40100003)(106356001)(4001350100001)(33656002)(47776003)(50986999)(87976001)(101416001)(23676002)(105586002)(83506001)(99136001)(65816999)(5008740100001)(97736004)(80316001)(64126003)(65956001)(86362001)(76176999)(65806001)(66066001)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0137; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxTUIwMTM3OzIzOnVVUTNIb2hzR3RIdURHUHdxTHZpV01PZTZS?= =?utf-8?B?QkdxTW9XcmRHUHE0UGlqVzRYOVh2cXpUck9iS0E1bDIwZVlhTGZBdmJCZXVF?= =?utf-8?B?TnV4V1N1SlV5QUY5MVJ6TkF0L0pxeFVsU0l5aU1ZSFJOMTY5cTFJVlRSWWli?= =?utf-8?B?MEVHVUc4ZXBzZFM3OFRKNVA2K3pUazZ3LzhrVG91Q2lQNXFqcXkrMjN6TG8y?= =?utf-8?B?blVhVDh5UG56anpZZWZYcDU4N1pYVFN1OEZ6a3lLeUdkNjVkeVBCOG54akQr?= =?utf-8?B?bFJldGZUSG9NUG1Uc2VZUkM5eGRWQk9RUHluRkdRa1dsSFFXTHB6emtubVZH?= =?utf-8?B?bCtxaitueVlMbzgxSTdYMjlSNUZPK0tIUTQ5NXAyNHJwc0xtT1QvKzNWVzk2?= =?utf-8?B?Q3l6SXg0WXVLcVVEUDZQUEE5TWxUOTdoUE1WdmxuZGoxcWQxUXZGVnBlVW5Q?= =?utf-8?B?QjZKYjFPcFRlTmZCU2xGblNSeGF3VFk1WWY2UW95eEtvNnNHRVl4Z0t5TitF?= =?utf-8?B?RmprNXE0VlhiQ2hNR0x6M0NibGFDV0tHeW0vaXU1R20xUUFhYlJrTVRneEcr?= =?utf-8?B?dFdONnR4WmtxaUw3L3dPT2R3TXZwcXhiaE14SVRqdGM5YXhjK3FXRDBpMkox?= =?utf-8?B?NXpYeU5aekNOL2tkeTd5NGJwMlhaZDdQeU9jS1ZQcU05QjgyeFJ6eW12aGtl?= =?utf-8?B?MWJRVmlORGdjcGJuSGExZzM0TzZ4Q2w0ZGFMNU1FTGN3MFE5bkZaMWpsT2lY?= =?utf-8?B?V1FGSnR2ZFBSaytBMTRDSGttT2QwSGtRdUw4ZEpTTmovY3YxYWliei8wQUQv?= =?utf-8?B?OTF1eENwcEpSRFRWVDV2UlBScGE1Rm54YlFSL3BxZHZuL2JuL2Z3K3g1RGJq?= =?utf-8?B?MVk0OHJjemVidHV3L3dNWStibXpoYk03alV2NS9rdk1GZ2hlZ0tacklobEh6?= =?utf-8?B?OHlNZjVqVjlMbUhTTHpZU1l2Q1ljYi8zUUFWc25nSmtrYWVOZnFaS0hpdHkw?= =?utf-8?B?TnBtOFpoaTVpNUg2a092LzdXb1QwQ01BN0p2QyttZGpSUWFGZUJ6bjFkR1I3?= =?utf-8?B?WmEwMHBaN2hPVXBsTU1jd2NSWHJDV254L2hneEV3cVU0Um44UitZZUVsVjBZ?= =?utf-8?B?dkFPeVorZU92VXNtVGNqWFhabXhMenUyU0haUk1iNDlPTXdyUGdqRHVhdFdY?= =?utf-8?B?dDlidjRiQnlVdU5VVmpHcnBENWpac1J5eElCVldXQXkvVGVrcmozcm5Qa2ZV?= =?utf-8?B?QzE4a3dXU2Erc2U1SjlNSGRNb1djbWQ3cFI4YzZFOFZiYTdWeXVwellOR2N3?= =?utf-8?B?RDlkdTlmZm15MHpSYnVNMHFyRkJMUWdKWlR4MnR6M1dBaWJIQkY2SHhPV0tG?= =?utf-8?B?dmdZVllHUGYweWFVa2lwcGlpZk4zUGYzSmkyNUJsUHg2Uy9nOWVWblAyM3BR?= =?utf-8?B?a2pvbmd2eVlJQUhDQ2VHWWJYamlxVG5OTlBxYjYwdDFYeGNBNnU5ZWNGdWk5?= =?utf-8?B?VHpkRDZkNkFhTzhBMFVSVTdnWmNCZ241T1liZkpIRWtEa09NcnFnOHNBVVlL?= =?utf-8?B?WFM4a3NHTFh0YW5HN2M5OUp3OVlYVGE0eGRmeHhmb3VqRTlrOXd4bTBVclBW?= =?utf-8?B?RnFJSjJjT0RmbVpVRnUzVFpEQnozVUNqU1djMkYyVkk3QWxib21hdElFa3NS?= =?utf-8?Q?ulJxCWRVkauL2iRToI=3D?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0137; 5:/QzEhljFmIw08YN/ORIpoPtUoTQg92XGT8SSNz2soAAJd0Zpx8dQLWBfnkW+HSZMpJKvG0whJ180l3cSENRFC7yXg9ry5tqDOuLyIGua4RcvWgVASZiG/tv2X/a4oP+vwGPotvqQxUQ/dm6h2fJlcw==; 24:89a9nxeeiHensSBE9/NdjC8uE/S4xDipx1bg4RmWRrQZBzszvKrIVpZhrx0rMnosdRErD77j66zAlZ3kTdYkdX4mAT0v0V4833U1SLKsdcY=; 20:jXZ+ZUlpJJ67YbrIgMaE/dTmz9LR0zo8Z/kefeLrlEmz3aJmAr3w0+ki6V7GfH8fQYA16+ICTAxBIxamfxf8dA== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Nov 2015 08:53:16.9786 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0137 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 08:53:26 -0000 On 2015/11/11 15:30, Sean Leonard wrote: > I sort of assume that fragment identifier syntax is not needed for fonts. If so, explicitly declaring fragment identifiers as out-of-scope will help keep focus. One could naturally devise some kind of fragment syntax but that would be a great example of where we have agreement on focus before the WG starts; therefore, the effort won’t get sidetracked by that. Agreed. I don't think it's needed in the charter, but it doesn't hurt to add it. > I think that constraining the charter will make it more focused. I am not precluding initial registrations but I am asking for more precision. > > Specifically right now the scope (based on draft-00) seems too Web-focused. Fonts apply to a lot more than the Web. For example, (e)mail interests and printing interests should be represented. A start would be to include PostScript Type 1 fonts (tip: there are actually a large number of PostScript types). Other types that come to mind include TeX font metric (TFM, .tfm), Spline Font Database (.sfd), Apple Advanced Typography (AAT), and Graphite (by SIL). I think one way to word it is that we want a few initial registrations because it wouldn't make sense to create a new top level empty. The initial registrations can also serve as examples for further registrations and as a proof of concept for the top level type. But there's no need to be complete; registering a subtype isn't too difficult. Of course, if people provide additional registration templates, maybe these can also be added to the initial registration, but there is absolutely no need to try to be complete. > On the mail side, it would be very nice to use @font-face in HTML email: the status quo is to render text with nice fonts in graphics that are sliced into HTML4 table cells (which in turn promotes the pervasive use of “web bugs”, i.e., server-hosted images that leak exactly when and where a user opens an email). However, the security considerations loom large on that one. Interesting point, but not at all relevant for the current effort. > Note that these types do not need to be registered--only acknowledged. And by comparing all of these types, it is hopefully clearer that it is hard to find any parameters that are in common between all of them. Common parameters don't need to be universal across subtypes. An example is "charset", although fairly common for text/, it's not used on all subtypes. > On the other hand, the top-level media type could be “webfont” which more explicitly states the bias. The current 'bias' is, as far as I can guess, mostly due to the fact that the lack of a common top-level type is most severely felt by people involved in Web fonts, and that therefore they have started this effort. It would be very strange to create a top-level type "webfont", because we also don't have top level types "webimage" or "webtext" and so on. > But you raise an important point because the WG ought to incorporate the needs of all font communities, not just this particular community that promoted this current draft. If you look at draft-singer-font-mime-00 from October 2004, you will note a distinct difference in focus, as evidenced in proposed parameters like “font-name”. I'm pretty sure these concerns can be addressed once the WG is formed. I'm also sure that the current community doesn't want to leave other font formats out, it just concentrated on what it needs and what it knows best. As for draft-singer-font-mime-00, I agree that there's some good reusable stuff in there. But on the other hand, there's also some hopeless overkill, for example the text that says that something like font/Courier is out of scope in the same way as image/MonaLisa is out of scope. Regards, Martin. From nobody Wed Nov 11 02:30:21 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF581A88BE for ; Wed, 11 Nov 2015 02:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 v4o4CCkE-_ay for ; Wed, 11 Nov 2015 02:30:17 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915841A88BD for ; Wed, 11 Nov 2015 02:30:17 -0800 (PST) Received: from [213.205.194.75] (helo=M6700) by raoul.w3.org with esmtpsa (TLS1.1:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1ZwSfP-000BME-G7 for apps-discuss@ietf.org; Wed, 11 Nov 2015 10:30:15 +0000 Date: Wed, 11 Nov 2015 10:30:12 +0000 From: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <1447052943.20151111103012@w3.org> To: apps-discuss@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 10:30:19 -0000 Hello Apps-discuss, (I just joined; apologies for not having the original thread starter message to reply to). I have ready the proposed charter and it seems fine to me. I'm glad to see that my ID is to be used as the basis, and confirm my willingness to be document editor for the proposed group IDs and eventual RFC. I agree with Ned Freed that a brief sentence or two of justification, lifted from the ID and pointing to the same data about current usage, would be helpful. I see that the topic of fragment identifiers has come up. Some formats will indeed need fragment identifiers to be defined (TrueType collections is one example, SVG Fonts was another) and the correct place to do so is clearly the Media Type registration. (I also see calls for fragment identifiers to be ruled out of scope; I see no reason to do so and it would be actively harmful so let's not do that). I concur with the opinions Barry, John, Mark and others have expressed that a tightly focussed group is preferable to extending the scope for additional top-level types, which is an unbounded problem. I see pushback on initial registrations. I don't understand this, at all. Forcing the initial set of registrations out to another venue means extra work for no benefit. The original MIME document had initial registrations for image/gif and image/jpeg if I recall correctly, despite there being no commonality in terms of internal structure between the two. Both however could be (and were, in the early days) handed off to a multiformat image viewing program. This looks like exactly the same case. So I think the initial registrations should stay. The ones for WOFF1 and WOFF2 come from the W3C WebFonts WG, which this charter proposes to tightly coordinate with; the sfnt, TrueType and OpenType ones come from ISO SC29 WG11 whoo maintain the Open Font Format (aka OpenType) specification. So these formats are all widely deployed already, they are not speculative or tentative. Let's avoid splitting those all out into separate documents, please. I do agree with Sean however on the terminology "primary content type". I'm used to the term "top-level type" but I read the model/* registration shortly before submitting this iD and suddenly worried I was using the wrong term, hence the occurrences of "primary content type". Happy to revert to using the right term. -- Best regards, Chris Lilley Technical Director, W3C Interaction Domain From nobody Wed Nov 11 07:34:30 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E191B2A43 for ; Wed, 11 Nov 2015 07:34:29 -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_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 KDp9iHTJ9RQk for ; Wed, 11 Nov 2015 07:34:28 -0800 (PST) Received: from p01c11o143.mxlogic.net (p01c11o143.mxlogic.net [208.65.144.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BDBC1B2A3C for ; Wed, 11 Nov 2015 07:34:27 -0800 (PST) Received: from unknown [192.5.106.47] (EHLO wob-maildb-03.agfamonotype.org) by p01c11o143.mxlogic.net(mxl_mta-8.5.0-3) with ESMTP id 30063465.2b61e020c940.620428.00-498.1720399.p01c11o143.mxlogic.net (envelope-from ); Wed, 11 Nov 2015 08:34:27 -0700 (MST) X-MXL-Hash: 56436003460be3a9-f43fdab2afc5b1bd70cad90692f02d8dba6acbb9 Received: from unknown [192.5.106.47] (EHLO wob-maildb-03.agfamonotype.org) by p01c11o143.mxlogic.net(mxl_mta-8.5.0-3) over TLS secured channel with ESMTP id ddf53465.0.619867.00-306.1718722.p01c11o143.mxlogic.net (envelope-from ); Wed, 11 Nov 2015 08:33:50 -0700 (MST) X-MXL-Hash: 56435fde5af5a46d-9c572370bbec272e7714f34708abe6766e796779 Received: from wob-maildb-03.agfamonotype.org (192.168.65.95) by wob-maildb-03.agfamonotype.org (192.168.65.95) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 11 Nov 2015 10:32:45 -0500 Received: from wob-maildb-03.agfamonotype.org ([fe80::f90b:70d6:b5e2:1c86]) by wob-maildb-03.agfamonotype.org ([fe80::f90b:70d6:b5e2:1c86%17]) with mapi id 15.00.0913.011; Wed, 11 Nov 2015 10:32:45 -0500 From: "Levantovsky, Vladimir" To: Sean Leonard , IETF Apps Discuss Thread-Topic: [apps-discuss] Proposed charter for justfont Thread-Index: AQHRG14P9IIAwU/oyEm/ruf5IAEAGJ6Vf9+AgAAjm4CAAAcGgIAAduuAgAA8ngCAAI048IAAChQQ Date: Wed, 11 Nov 2015 15:32:44 +0000 Message-ID: References: <564153CD.3010108@w3.org> <11E3E0CE-BD47-4E34-AE24-470DABA6DC98@kitterman.com> <776938B4-A6AE-47FE-9834-CBEB365A6E8D@seantek.com> <2BEAD659-98EA-4DA4-9B45-5FC92A03392A@seantek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.25.1.29] x-exclaimer-md-config: c271eea4-4802-4476-ab53-9ae654d778b2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=ffqrvhkF c=1 sm=1 tr=0 a=XOlr6t7Gqt60WzYSt0UKeQ==] X-AnalysisOut: [:117 a=XOlr6t7Gqt60WzYSt0UKeQ==:17 a=2c3nKaCKAAAA:8 a=rfFW] X-AnalysisOut: [i7IFAAAA:8 a=YlVTAMxIAAAA:8 a=fQfWnCFtOYMA:10 a=IkcTkHD0fZ] X-AnalysisOut: [MA:10 a=xqWC_Br6kY4A:10 a=qtqOOiqGOCEA:10 a=B6KMzFptAAAA:2] X-AnalysisOut: [0 a=CE3YtXpAWNsEY1PRXOsA:9 a=5vKIRPZaiZ7mCmpE:21 a=KV-WY5_] X-AnalysisOut: [UNXEHFATI:21 a=QEXdDO2ut3YA:10] X-Spam: [F=0.5200000000; CM=0.500; MH=0.520(2015111106); S=0.313(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [192.5.106.47] Archived-At: Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 15:34:29 -0000 SGkgYWxsLA0KDQooU29ycnkgZm9yIGR1cGxpY2F0aW9uIGlmIHlvdSBzZWUgdGhpcyBlbWFpbCB0 d2ljZSAtIHRoZSBvcmlnaW5hbCBwb3N0IGhhcyBib3VuY2VkIHNpbmNlIEkgdXNlZCB0byBiZSBz dWJzY3JpYmVkIHRvIHRoZSBsaXN0IHdpdGggYSBkaWZmZXJlbnQgZW1haWwgYWRkcmVzcy4pDQoN CkFzIGEgYnJpZWYgaW50cm9kdWN0aW9uLCBJIGFtIFZsYWRpbWlyIExldmFudG92c2t5IGZyb20g TW9ub3R5cGUgYW5kIEkgYWxzbyBzZXJ2ZSBhcyBhIGNoYWlyIG9mIHRoZSBXM0MgV2ViRm9udHMg V0cgYW5kIGFzIElTTyBwcm9qZWN0IGVkaXRvciBmb3IgSVNPL0lFQyAxNDQ5Ni0yMiBPcGVuIEZv bnQgRm9ybWF0IChPRkYpIHNwZWMuDQoNCk9uIFR1ZXNkYXksIE5vdmVtYmVyIDEwLCAyMDE1IDg6 MzAgUE0gU2VhbiBMZW9uYXJkIHdyb3RlOg0KDQo+IEFsbCByaWdodCwgZmluZS4gQnV0IHdoZW4g d2Ugc2F5IHRpZ2h0IGZvY3VzLCBqdXN0IGtlZXAgaXQgYXMgbXVjaCBhcyANCj4gcG9zc2libGUg b24gdGhlIHRvcC1sZXZlbCBtZWRpYSB0eXBlIHJlZ2lzdHJhdGlvbi4NCj4NCj4gSSBzZWUg4oCc bWFraW5nIGluaXRpYWwgcmVnaXN0cmF0aW9ucyBpbiAiZm9udCLigJ0gdG8gYmUgYSBwb3NzaWJs ZSBibGFjayANCj4gaG9sZS4gSSBhbHNvIHNlZSBkZWZpbmluZyBjb21tb24gcGFyYW1ldGVycyAo b3Igd2F5cyB0byBhY2NvbW1vZGF0ZSANCj4gdGhlbSkgYmV0d2VlbiAiZm9udCIgcmVnaXN0cmF0 aW9ucywgYWxzbyB0byBiZSBhIGJsYWNrIGhvbGUuIEJsYWNrIGhvbGUgPSBsaWtlbHkgdG8gZGVy YWlsIHRpZ2h0IGZvY3VzLg0KPg0KDQpUaGUgY3VycmVudCBwcm9wb3NhbCBhdHRlbXB0cyB0byBy ZXBsaWNhdGUgdGhlIHNhbWUgc3RydWN0dXJlIG9mIHN1YnR5cGVzIHRoYXQgd2VyZSBkZWZpbmVk IGZvciBmb250LXJlbGF0ZWQgc3VidHlwZXMgaW4gdGhlICJhcHBsaWNhdGlvbiIgdHJlZSwgc28g d2hhdCB1c2VkIHRvIGJlIGRlZmluZWQgYXMgYXBwbGljYXRpb24vZm9udC13b2ZmIHdvdWxkIG5v dyBiZSBzaW1wbHkgZm9udC93b2ZmLg0KDQo+IFBhcnQgb2YgdGhpcyBpcyBiZWNhdXNlIHRoZXJl IGlzIG5vIGNvbW1vbiBkYXRhIGZvcm1hdCBjb25ncnVlbmNlIA0KPiB3aXRoaW4gdGhlIHByb3Bv c2VkIGZvbnQgdHlwZXMsIHNvIFNlY3Rpb24gNCBvZiBkcmFmdC0wMCBzYXlzIA0KPiDigJxVbnJl Y29nbml6ZWQgc3ViLXR5cGVzIG9mICJmb250IiBzaG91bGQgYmUgdHJlYXRlZCBhcyANCj4gImFw cGxpY2F0aW9uL29jdGV0LXN0cmVhbSIu4oCdIFRoZW4gaXQgc2F5cyDigJxJbXBsZW1lbnRhdGlv bnMgbWF5IHBhc3MgdW5yZWNvZ25pemVkIHN1YnR5cGVzIHRvIGEgY29tbW9uIGZvbnQtaGFuZGxp bmcgc3lzdGVtLCBpZiBzdWNoIHN5c3RlbSBpcyBhdmFpbGFibGUu4oCdDQoNCkkgc3Ryb25nbHkg ZGlzYWdyZWUgd2l0aCB0aGUgc2VudGltZW50LiBUaGUgT3BlblR5cGUgLyBPRkYgc3RhbmRhcmQg ZGVmaW5lcyBhIGNvbW1vbiBkYXRhIGZvcm1hdCB3aGVyZSBUcnVlVHlwZSwgQWRvYmUgQ0ZGLCBh bmQgbm93IFNWRyBvdXRsaW5lcyBjYW4gcGVhY2VmdWxseSBjb2V4aXN0LCBhbmQgdGhlIGxpc3Qg ZG9lc27igJl0IHN0b3AgdGhlcmUuIEF0IGEgaGlnaGVyIGxldmVsLCBhbGwgbW9kZXJuIGZvbnQg ZGF0YSBmb3JtYXRzIChPcGVuVHlwZS9PRkYsIEFBVCwgU0lMKSBzaGFyZSB0aGUgc2FtZSBTRk5U IGRhdGEgc3RydWN0dXJlIHNvIGNvbnNpZGVyaW5nIHRoYXQgdGhlcmUgYXJlIGEgbnVtYmVyIG9m IG9mZmljaWFsbHkgc3RhbmRhcmRpemVkIGdseXBoIG91dGxpbmUgZm9ybWF0cyAoc2VlIGFib3Zl KSBhbmQgdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4gdmFyaW91cyBTRk5ULWJhc2VkIGZvbnQgZm9y bWF0cyBhcmUgc3BlY2lmaWMgdG8gdmFyaWF0aW9ucyBpbiBzdXBwb3J0ZWQgdGV4dCBsYXlvdXQg bWVjaGFuaXNtcyAtIHRoZSBzdWJ0eXBlcyBhbmQgdGhlIG9wdGlvbmFsIHBhcmFtZXRlcnMgdGhh dCBhcmUgcHJvcG9zZWQgYXMgcGFydCBvZiB0aGUgZm9udC8qIHRyZWUgKGFuZCB0aG9zZSB0aGF0 IGhhdmUgYmVlbiByZWdpc3RlcmVkIHRvIGRhdGUgYXMgcGFydCBvZiB0aGUgYXBwbGljYXRpb24g dHJlZSkgYXJlIGFsbCBqdXN0aWZpZWQgYnkgcHJhZ21hdGljIGNvbnNpZGVyYXRpb25zIG9mIHdo YXQgaXMgdXNlZCB0aGVzZSBkYXlzLg0KDQo+IChJIHN1Ym1pdCB0aGF0IHRoZXJlIGlzIG5vIGNv bW1vbmFsaXR5LiBJbiB0aGUgZXhlbXBsYXJ5IA0KPiByZWdpc3RyYXRpb25zLCBmb250L3NmbnQg fiBmb250L290ZiB+IGZvbnQvdHRmIGJ1dCAhPSBmb250L3dvZmYuIFRoYXQgDQo+IGlzIGJlY2F1 c2UgV09GRiBpcyBjb21wcmVzc2VkLiBNYXliZSBJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGUgDQo+ IGNvbW1vbmFsaXR5IG9mIHRoZSBkYXRhIGZvcm1hdHMuIEFuZCB3aGF0IGFib3V0IFBvc3RTY3Jp cHQgVHlwZSAxIA0KPiBmb250cyBzdWNoIGFzIC5wZmI/KQ0KDQpNZW1iZXJzIG9mIFdlYkZvbnRz IFdHIGhhdmUgY29uZHVjdGVkIGV4dGVuc2l2ZSBzdHVkeSBvZiBtZWRpYSB0eXBlcyB0aGF0IGFy ZSBpbiB1c2UgdGhlc2UgZGF5czoNCmh0dHBzOi8vZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L2Qv MVRzanU2RU9QNExxSjFSY0ZKUnBxeHJ5Z2diV1pZYnE1anZzSWhWWU5veVUvZWRpdA0KQXMgbXVj aCBhcyBpdCBtYWtlcyBzZW5zZSB0byBtYWtlIHRoZSBuZXcgc2V0IG9mIG1lZGlhIHR5cGVzIGZv ciBmb250cyBpbnR1aXRpdmUgYW5kIGVhc3kgdG8gdXNlLCB3ZSBhcmUgbm90IGF0IGFsbCBpbnRl cmVzdGVkIGluIHJlc3VycmVjdGluZyBhbGwgYW5jaWVudCBmb250IGZvcm1hdHMgdGhhdCBoYWQg c2VlbiB0aGUgbGlnaHQgb2YgZGF5IGF0IHNvbWUgcG9pbnQgb2YgdGhlIGxhc3QgY2VudHVyeSAt IHRoZSBwcm9wb3NhbCBpcyByb290ZWQgaW4gb2JzZXJ2YXRpb25zIG9mIHdoYXQgdGhlIG1ham9y aXR5IG9mIGZvbGtzIHVzZSB0aGVzZSBkYXlzIChpLmUuLCBtb3JlIG9mdGVuIHRoYW4gbm90IHRo ZXkgc2ltcGx5IHVzZSBhIG1lZGlhIHR5cGUgdGhleSBfdGhpbmtfIHdvdWxkIG1ha2Ugc2Vuc2Ug dG8gdXNlLCBhbmQgZG9u4oCZdCBldmVuIGJvdGhlciBjaGVja2luZyBpZiBpdCdzIGFjdHVhbGx5 IGRlZmluZWQpIGFuZCBzaW1wbGUgcHJhZ21hdGljIGNvbnNpZGVyYXRpb25zIGlzIHdoYXQncyBk cml2aW5nIG91ciBkZWNpc2lvbnMgYW5kIHRoaXMgcHJvcG9zYWwuDQoNCj4gVGhlIHNvb25lciB3 ZSBjYW4gZGVjbGFyZSB0aGF0IHRoZXJlIGlzIG5vIGNvbW1vbmFsaXR5IGluIGRhdGEgZm9ybWF0 LCANCj4gdGhlIHRpZ2h0ZXIgd2UgY2FuIG1ha2UgdGhlIHNjb3BlIGFuZCB0aGUgc29vbmVyIHRo ZSBXRyBjYW4gZmluaXNoIGl0cyB3b3JrLg0KDQpJTU8sIHdpc2hpbmcgc29tZXRoaW5nIGNvbWUg dHJ1ZSAob3IgZGVjbGFyaW5nIHNvbWV0aGluZyB0byBub3QgYmUgdGhlIGNhc2UgZXZlbiBpZiBp dCBpcykgZG9lc27igJl0IHdvcmsgLSB0aGUgcmVhbGl0eSBhbHdheXMgcHJldmFpbHMuDQoNClRo YW5rIHlvdSwNClZsYWQNCg0K From nobody Wed Nov 11 08:10:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51861B2B38 for ; Wed, 11 Nov 2015 08:10:23 -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 ZOWQ5vXIs75Y for ; Wed, 11 Nov 2015 08:10:22 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23CA71B2B3B for ; Wed, 11 Nov 2015 08:10:22 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B6609509BF; Wed, 11 Nov 2015 11:10:20 -0500 (EST) To: "Levantovsky, Vladimir" , IETF Apps Discuss References: <564153CD.3010108@w3.org> <11E3E0CE-BD47-4E34-AE24-470DABA6DC98@kitterman.com> <776938B4-A6AE-47FE-9834-CBEB365A6E8D@seantek.com> <2BEAD659-98EA-4DA4-9B45-5FC92A03392A@seantek.com> From: Sean Leonard Message-ID: <56436822.7070704@seantek.com> Date: Wed, 11 Nov 2015 08:09:06 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090908080808030803060506" Archived-At: Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 16:10:24 -0000 This is a cryptographically signed message in MIME format. --------------ms090908080808030803060506 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 11/11/2015 7:32 AM, Levantovsky, Vladimir wrote: > Hi all, > > (Sorry for duplication if you see this email twice - the original post = has bounced since I used to be subscribed to the list with a different em= ail address.) > > As a brief introduction, I am Vladimir Levantovsky from Monotype and I = also serve as a chair of the W3C WebFonts WG and as ISO project editor fo= r ISO/IEC 14496-22 Open Font Format (OFF) spec. Greetings; pleased to meet you. > > On Tuesday, November 10, 2015 8:30 PM Sean Leonard wrote: > >> All right, fine. But when we say tight focus, just keep it as much as >> possible on the top-level media type registration. >> >> I see =E2=80=9Cmaking initial registrations in "font"=E2=80=9D to be a= possible black >> hole. I also see defining common parameters (or ways to accommodate >> them) between "font" registrations, also to be a black hole. Black hol= e =3D likely to derail tight focus. >> > The current proposal attempts to replicate the same structure of subtyp= es that were defined for font-related subtypes in the "application" tree,= so what used to be defined as application/font-woff would now be simply = font/woff. Fine. > >> Part of this is because there is no common data format congruence >> within the proposed font types, so Section 4 of draft-00 says >> =E2=80=9CUnrecognized sub-types of "font" should be treated as >> "application/octet-stream".=E2=80=9D Then it says =E2=80=9CImplementat= ions may pass unrecognized subtypes to a common font-handling system, if = such system is available.=E2=80=9D > I strongly disagree with the sentiment. The OpenType / OFF standard def= ines a common data format where TrueType, Adobe CFF, and now SVG outlines= can peacefully coexist, and the list doesn=E2=80=99t stop there. At a hi= gher level, all modern font data formats (OpenType/OFF, AAT, SIL) share t= he same SFNT data structure so considering that there are a number of off= icially standardized glyph outline formats (see above) and the difference= s between various SFNT-based font formats are specific to variations in s= upported text layout mechanisms - the subtypes and the optional parameter= s that are proposed as part of the font/* tree (and those that have been = registered to date as part of the application tree) are all justified by = pragmatic considerations of what is used these days. I suppose that this is analogous to the text & charset situation, in=20 which charset is common across the vast majority of text types and has=20 predefined semantics, but not all text subtypes need to use it (for=20 historical reasons). With that said, it sounds like the default font=20 type handling is going to be font/sfnt. Since the primary experts have=20 already concluded this, I would rather see it in the charter as follows: The working group will use draft-lilley-font-toplevel as a starting=20 point. Default font handling will be defined by font/sfnt. -Sean --------------ms090908080808030803060506 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MTExNjA5MDZaMC8GCSqGSIb3DQEJBDEiBCDbAlrbpT9HwejiG+3bk51PepqTQS3VPnAvWEwW g8RKPTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQC2iXiJXUiEY/PXU2T7 Ma9HA6ke3PN8v5uMRtmqS4CaaoGJcocO9+YXTWhF0W7ECDO/HUCQdtHX9dZgUm2nNEVI3ON9 o0oxzyPwsfKTcJG+yu2H2ELZ4KOgSvkSRZRA/86Ekly6UhpTXDP7DLs9bLZOImmtikX3xc1c XNs5FqL5LlLRNw2Tp416VmYk25dCE+LrTO3wi+JB8hlocidLwq53RedO41edGNlhEYo5I5jZ tM9EzWBGeAfDUsRdaphmHmhd4/1nFSqCwBhOSwBTAYlvmrauxVKVTubz9FV7HukVEv/f2flw rZ8XmLZsoKTzm+XlPuaNq0pCOSF4v8FiqbJeAAAAAAAA --------------ms090908080808030803060506-- From nobody Wed Nov 11 10:08:02 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0932B1B373B for ; Wed, 11 Nov 2015 10:08:01 -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 I_cXJ3osXkcQ for ; Wed, 11 Nov 2015 10:07:59 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209BF1B3627 for ; Wed, 11 Nov 2015 10:07:59 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D5EDB509BB for ; Wed, 11 Nov 2015 13:07:57 -0500 (EST) To: apps-discuss@ietf.org References: <1447052943.20151111103012@w3.org> From: Sean Leonard Message-ID: <564383B3.6040101@seantek.com> Date: Wed, 11 Nov 2015 10:06:43 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1447052943.20151111103012@w3.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080008070203020109040905" Archived-At: Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 18:08:01 -0000 This is a cryptographically signed message in MIME format. --------------ms080008070203020109040905 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 11/11/2015 2:30 AM, Chris Lilley wrote: > Hello Apps-discuss, > > (I just joined; apologies for not having the original thread starter > message to reply to). Greetings. Here you go: http://mailarchive.ietf.org/arch/msg/apps-discuss/Y7jED50ZCAprh3WGqn5TH5v= aIfM > I see that the topic of fragment identifiers has come up. Some formats > will indeed need fragment identifiers to be defined (TrueType > collections is one example, SVG Fonts was another) and the correct > place to do so is clearly the Media Type registration. > > (I also see calls for fragment identifiers to be ruled out of scope; I > see no reason to do so and it would be actively harmful so let's not > do that). Fragment identifiers are complicated, because: * the character encoding is not necessarily straightforward, especially=20 when dealing with legacy types * when generalizing about any group of types, you should survey as many=20 of the types as possible (including those that you personally don't=20 consider "popular") to make sure that your syntax does not exclude those = types * fragments can represent anything so you have to make choices about=20 what is addressable and what is not addressable. For example, text/html=20 uses fragments for anchors; this precludes using fragmen= t=20 syntax to identify, for example, the nth element in the tag soup, or=20 some XPath expression (absent active JavaScript code on the page that=20 reinterprets the anchor). One also does not really use fragments with=20 text/html to express "ranges" of the document. At a high level, collections of fonts are not single fonts; my=20 impression prior to researching was that font/x represents a single=20 font. A generic font collection would best be described in archive/* (if = the collection is a group of files, such as a ZIP archive), or possibly=20 in message/* or multipart/* depending on the structure. It could even be = application/cms or application/cbor if one were so inclined. However I just read=20 and it appears=20 that TTCs are actually SFNT data with a header, TTCHeader, that=20 indicates the presence of multiple individual font table collections. So = font/ttc may well be appropriate because it is a kind of SFNT. I am=20 curious what happens if a font rendering engine that is *not* TTC-aware=20 is supposed to do with the font file. Will the rendering engine just=20 treat it as a single font, such as the first font in the table? As for fragments: if you want the fragment of a font/ttc to be useful to = identify a single font, that has very different semantics from a=20 single-font SFNT, where people might want fragment identifiers to=20 address individual tables (or possibly individual glyphs or data items=20 in individual tables). There is nothing wrong with defining fragment=20 identifiers specifically for font/ttc, as long as we understand that=20 it's not necessarily generalizable to the generic case. If we can agree that SFNT is the de-facto structure for types in font/*, = that could keep the work more focused. If TTC & font collections are a significant use case, then the WG=20 charter should be updated to include (or exclude, put it in=20 multipart/ttc or application/font-collection; type=3D"ttc" or=20 what-have-you) that. The choice seems to be directly related to how TTC=20 handling might gracefully degrade to a generic font/sfnt, and based on=20 my preliminary research, it should probably be in. (I have no domain knowledge about SVG Fonts so don't want to say=20 anything about that.) Sean --------------ms080008070203020109040905 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfYwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU/MIIEJ6ADAgECAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMjAyMDAwMDAwWhcNMTYwMjAyMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkB FhRkZXYraWV0ZkBzZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM+J9tKgDs1LQtaDc+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgiv boRKoo2guKi2R5xrf/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftv TEun2mOrnJ3G53zvawQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecN VbfusUU1wZOlfdy8lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd 7oCj5MRKOg2ZLia33JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAfIwggHu MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQaZuXe8vDwU+ja pyFW3zSvIW6TxjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2Vh bnRlay5jb20wDQYJKoZIhvcNAQELBQADggEBAHiH/zXr779dLLJNLp6yW/RQvJSYuNbEqauQ BWLZgvCF8FJjcS+y+bhN7RpTSVaEymbxnpJWFg0Qs6us6rXtttU6MF2JhTuxtu6yWW0EYy80 KGOt6zJRTxa46kAhAOqw4KPQ5RTvf/NT+2Qu8b2edlh+3t6f8iTQOAL/BNHnmr4QvpfnMLa8 NMAqd4FLOcSU9JKBlb5YtsEdfM3nBt4m95pfhpww79gB+zoXMoVaI+lfQHhkGth6mlaTkFUV DT2pqq98XgESpObFEngb8ZRftBVoZfgJ4ajXcZnhKaqYEr23EtY207KgKb4LAXA84wtPcFfJ rQaDArapR7xd2GNs+eYxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCWCGSAFlAwQC AQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEx MTExODA2NDNaMC8GCSqGSIb3DQEJBDEiBCCScwKa2YKo2sj8DZfztzfciGpxAPdAKHpoaIdr JX2S2TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQGkJKzyf5xBtzPJYq257J5zCBwwYLKoZIhvcNAQkQ AgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQD EzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIQGkJKzyf5xBtzPJYq257J5zANBgkqhkiG9w0BAQEFAASCAQBBFfqvZ0LTiRB5N2eM +/LhmxKXf6N5zEAnKeOc2BMEMFnrT3emUraJ+ocf8rX4X0/0iNbHyfmVoI7H/tCNL3+GiY/U uM+3elWUIMkbwgHPOChyiDcuHhr8In7LlYoZqaqQtetJ7yVrY2zblmuYNQ5pgPKzogqHRk+U 6Cu4XaWLS1SfIIulNIn1x965fhYW72YLCLbqobWoKjtfEeU9XoPj2LVcf6QX2TtI4pgKfWag GtdpaT2/U03vkbBltfgn60ZAeHfx+TI9Psrw1Lnvy+PU2vLOeaIoZcelapKQHwagRT8GCgXa /2OFMhbdGHn18IHPTGqUyaNvfYJ23jxegvXeAAAAAAAA --------------ms080008070203020109040905-- From nobody Wed Nov 11 17:06:59 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4191B3CB8 for ; Wed, 11 Nov 2015 17:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQ-XdlARGN4c for ; Wed, 11 Nov 2015 17:06:56 -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 8AB741B3CBA for ; Wed, 11 Nov 2015 17:06:56 -0800 (PST) Received: (qmail 96397 invoked from network); 12 Nov 2015 01:06:55 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 12 Nov 2015 01:06:55 -0000 Date: 12 Nov 2015 01:06:33 -0000 Message-ID: <20151112010633.2000.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <776938B4-A6AE-47FE-9834-CBEB365A6E8D@seantek.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 01:06:57 -0000 >I would also request that the archive top-level media type be included in the WG scope. I recall that the W3C web-packaging effort was >interested in that as well. This will make the work more meaty while keeping it focused on the primary standardization effort. Please, no. There is a specific significant community ready to implement font/whatever. As far as I know, there is no such community for archive/*. It failed once due to lack of interest and I don't see anything different now. R's, John From nobody Thu Nov 12 10:23:43 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EA61B2CAD for ; Thu, 12 Nov 2015 10:23:39 -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 p3vnNNr9_i-q for ; Thu, 12 Nov 2015 10:23:38 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A701B2CAB for ; Thu, 12 Nov 2015 10:23:38 -0800 (PST) Received: by iofh3 with SMTP id h3so73760529iof.3 for ; Thu, 12 Nov 2015 10:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mcarijVRXx3OP6wkpE2LSukgLdRzhBQLF3eM2O93ixI=; b=Ehfwpbv4LSHBfMu/owt98zlTYScY0yE/tJ3Ikyv14sjcCxWIUQLzHMylKddUHpjn8o 5rXeZqnRoQHmW9iqfyC8rmsIeOphdV2CJDI5x/I/29QYHta2nyFvwCcE00jl7gxAjlNr uYs0CTyq6IZD0K0NPp5dmUr07cVlEFVkIyFl87ceKGMOzU6tBC3lnd+iVG+LAazKMMGv NoeAyuIxGqPEhTpcBI/fLaFDBe0K7WLtAVd39bAQ0ZJmFLL+R88mKL7jioe0gcdEiqBo 8Elj4gXyZih2F8/vp4VvCEipQcLmOSZdiHrm5dIiUwX/QJr0/XaIJPjUivQ6DZ8WlEB9 FaZQ== MIME-Version: 1.0 X-Received: by 10.107.28.144 with SMTP id c138mr5321358ioc.15.1447352618087; Thu, 12 Nov 2015 10:23:38 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.181.202 with HTTP; Thu, 12 Nov 2015 10:23:37 -0800 (PST) In-Reply-To: <56436822.7070704@seantek.com> References: <564153CD.3010108@w3.org> <11E3E0CE-BD47-4E34-AE24-470DABA6DC98@kitterman.com> <776938B4-A6AE-47FE-9834-CBEB365A6E8D@seantek.com> <2BEAD659-98EA-4DA4-9B45-5FC92A03392A@seantek.com> <56436822.7070704@seantek.com> Date: Thu, 12 Nov 2015 13:23:37 -0500 X-Google-Sender-Auth: 3IZn937hJ_5ityzPDQyncNGs5o4 Message-ID: From: Barry Leiba To: Sean Leonard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 18:23:39 -0000 > it sounds like the default font type handling is > going to be font/sfnt. Since the primary experts have already concluded > this, I would rather see it in the charter as follows: > > The working group will use draft-lilley-font-toplevel as a starting point. > Default font handling will be defined by font/sfnt. That's something the document should say, and the working group should confirm consensus on. It would be a bad idea to constrain a working group by putting such a low-level detail into the charter, absent a very strong reason for it. I don't see a strong reason. Barry From nobody Thu Nov 12 16:10:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD241B3DAF for ; Thu, 12 Nov 2015 16:10:24 -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 Vw_r9f226_xH for ; Thu, 12 Nov 2015 16:10:21 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCB1B1B3DAC for ; Thu, 12 Nov 2015 16:10:20 -0800 (PST) Received: by qkao63 with SMTP id o63so32293747qka.2 for ; Thu, 12 Nov 2015 16:10:20 -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=ooKT5cig2yWakLXA5CKmunzD8Ns8Lbd/7Qr5BHEaQ2k=; b=Wq21+wdp0kyLaxm7pnNL6X9DdZ197wl2s9x16wriDQ1O+YRwCjREQfK6/HOggtug2w yaTiWoE0Owlr0gMtDHCjt9fExw7K0WxYcSITMRxbZOwnYgD3qXBMuKFWJYNjhHshNIM9 bvjW6CENfvrECn9BiKy2+1hA4YppYpUK4SRFbuznbAEtaz7/ODFsVbDLr9vMu7Gmz9pp SW9e80BF7hys4aQyNE/itHIQpXS322M/abDKM4R+DXsOtRBFmemPRWjJguSbJC6R2NCH ezQEJw5fJ1lHqxngd7h5DntORpWUqEFiGtqPB0YB5PArXSpLzMZps9/ccXiWQL7VnvR2 iuBw== MIME-Version: 1.0 X-Received: by 10.140.18.146 with SMTP id 18mr19210897qgf.1.1447373420044; Thu, 12 Nov 2015 16:10:20 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.55.184.129 with HTTP; Thu, 12 Nov 2015 16:10:19 -0800 (PST) In-Reply-To: <01PSNM8H9MCO01729W@mauve.mrochek.com> References: <01PSN42ACKJS01729W@mauve.mrochek.com> <01PSNM8H9MCO01729W@mauve.mrochek.com> Date: Fri, 13 Nov 2015 10:10:19 +1000 X-Google-Sender-Auth: qwe10UVhSlxvD90YGd2GA2O-6xE Message-ID: From: Matthew Kerwin To: Ned Freed Content-Type: multipart/alternative; boundary=001a113559928f2afb052460e2cd Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 00:10:24 -0000 --001a113559928f2afb052460e2cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ahh somehow I managed to not see this email for a whole week. It's marked as "read" in gmail and everything. Sorry! On 3 November 2015 at 16:44, Ned Freed wrote: > > On 3 November 2015 at 07:42, Ned Freed wrote: > > > > I scanned the document, and maybe I'm missing something obvious, but = it > > > looks > > > to me like the material about the "authority" field is a bit mixed up= . > > > > > > The document starts by importing the "authority" production from RFC > 3986, > > > but AFAICT never actually uses the production. That production is: > > > > > > authority =3D [ userinfo "@" ] host [ ":" port ] > > > > > > The reason it's not used is the [ ":" port ] part is unneeded and > > > unwanted. (I > > > think I agree with that assessment, but even so this difference from > the > > > generic syntax should be stated somwhere.) > > > > > > The production that's used instead is: > > > > > > file-auth =3D [ userinfo "@" ] host > > > > > > Which is a fine way to get rid of the unwanted optional port clause. > But > > > then > > > the document speaks of things in terms of use or non-use of the > "authority" > > > field, when that field does not in fact appear in the file: URI ABNF. > > > > > > > > =E2=80=8BYou're right, the text in Section 2 wasn't updated when the AB= NF stopped > > directly using the "authority" rule. I'll fix that up, and make sure th= e > > right things are imported. > > > Throughout the document I used both "path" and "authority" to refer to > > functional components of the URI, rather than syntactic, even though bo= th > > of those words are also used as ABNF rules in RFC 3986. If we remove th= e > > import, does that resolve the issue? > > No, not really. If anything it makes it worse, because now you're talking > about > something that's effectively undefined. > > > (Would we then need a definition of > > "authority", or is the ref to RFC 3986 enough?) > > You need to link whatever term you use to the component of URL it refers > to. > > =E2=80=8BThat's true, but it was always the case for "path"=E2=80=8B and no= body seemed to mind that. It would have been convenient if the core spec defined some sort of URI object model, so we could subclass it appropriately; however since we've only the ABNF rules to go on, would something like this suffice? The core syntax in RFC 3986 includes "path" and "authority" components, for each of which only a subset is used in the definition of the file URI scheme. The subset of "path" is "path-absolute", and the subset of "authority" is "file-auth". I think that also carries the semantics of what the authority /*means*/ over to "file-auth," in its limited applicability. > > > I can think of a bunch of different ways of addressing this problem, > e.g., > > > changing file-auth back to authority and noting the difference betwee= n > it > > > here > > > and in RFC 3986, but since I'm not familiar with the document history > and > > > how > > > it has arrived at this point it would be a bit presumptious of me to > > > suggest a > > > specific course of action. > > > > > > I also found the directions in section 3.1, "Translating Local File > Path to > > > file URI", regarding the authority field to be a bit confusing. Step = 3 > > > says: > > > > > > 3. If including an empty authority field, append the "//" sigil to > > > the URI. > > > > > > No explanation given as to why I might - or might not - want to > include an > > > empty authority (file-auth) field. Some elaboration here would be nic= e. > > > > > > > > =E2=80=8BHmm, yes. How about something in the relevant paragraph in sec= tion 2, to > > the effect of: "To maximise compatibility with previous specifications, > > implementations MAY include an empty file-auth." ? > > That sounds OK to me. > > Ned > =E2=80=8BOk, I've changed it to: As a special case, the =E2=80=9Cfile-auth=E2=80=9D rule can match the st= ring =E2=80=9Clocalhost=E2=80=9D or the empty string; either value is interpr= eted as =E2=80=9Cthe machine from which the URI is being interpreted,=E2=80=9D exactly as if = no authority was present. To maximise compatibility with previous specifications, implementations MAY choose to include an empty =E2=80=9Cfile-auth=E2=80=9D.=E2=80=8B Seeing that with Chrome's spelling suggestions makes me wonder if I should Americanize all my "-ise" words, or just leave it for the editors. Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a113559928f2afb052460e2cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ahh somehow I managed to not see this email for a= whole week. It's marked as "read" in gmail and everything. S= orry!

On 3 N= ovember 2015 at 16:44, Ned Freed <ned.freed@mrochek.com>= wrote:
> On 3 November 2015 at 07:= 42, Ned Freed <ned.freed@mroche= k.com> wrote:

> > I scanned the document, and maybe I'm missing something obvio= us, but it
> > looks
> > to me like the material about the "authority" field is = a bit mixed up.
> >
> > The document starts by importing the "authority" produc= tion from RFC 3986,
> > but AFAICT never actually uses the production. That production is= :
> >
> >=C2=A0 =C2=A0authority=C2=A0 =C2=A0 =C2=A0=3D [ userinfo "@&q= uot; ] host [ ":" port ]
> >
> > The reason it's not used is the [ ":" port ] part i= s unneeded and
> > unwanted. (I
> > think I agree with that assessment, but even so this difference f= rom the
> > generic syntax should be stated somwhere.)
> >
> > The production that's used instead is:
> >
> >=C2=A0 =C2=A0file-auth=C2=A0 =C2=A0 =C2=A0 =3D [ userinfo "@&= quot; ] host
> >
> > Which is a fine way to get rid of the unwanted optional port clau= se. But
> > then
> > the document speaks of things in terms of use or non-use of the &= quot;authority"
> > field, when that field does not in fact appear in the file: URI A= BNF.
> >
> >
> =E2=80=8BYou're right, the text in Section 2 wasn't updated wh= en the ABNF stopped
> directly using the "authority" rule. I'll fix that up, a= nd make sure the
> right things are imported.

> Throughout the document I used both "path" and "authori= ty" to refer to
> functional components of the URI, rather than syntactic, even though b= oth
> of those words are also used as ABNF rules in RFC 3986. If we remove t= he
> import, does that resolve the issue?

No, not really. If anything it makes it worse, because now you'r= e talking about
something that's effectively undefined.

> (Would we then need a definition of
> "authority", or is the ref to RFC 3986 enough?)

You need to link whatever term you use to the component of URL it re= fers to.


=E2= =80=8BThat's true, but it was always the case for "path"=E2= =80=8B and nobody seemed to mind that. It would have been convenient if the= core spec defined some sort of URI object model, so we could subclass it a= ppropriately; however since we've only the ABNF rules to go on, would s= omething like this suffice?

=C2=A0 =C2=A0The core syntax in RFC 3986 = includes "path" and "authority"
=C2=A0 =C2= =A0components, for each of which only a subset is used in the definition
=C2=A0 =C2=A0of the file URI scheme. The subset of "path"= is "path-absolute", and
=C2=A0 =C2=A0the subset of &qu= ot;authority" is "file-auth".

I think that also carries the semantics of what the authority /= means/ over to "file-auth," in its limited applicability.<= /div>
=C2=A0
> > I can think of a bunch of different ways of addressing this probl= em, e.g.,
> > changing file-auth back to authority and noting the difference be= tween it
> > here
> > and in RFC 3986, but since I'm not familiar with the document= history and
> > how
> > it has arrived at this point it would be a bit presumptious of me= to
> > suggest a
> > specific course of action.
> >
> > I also found the directions in section 3.1, "Translating Loc= al File Path to
> > file URI", regarding the authority field to be a bit confusi= ng. Step 3
> > says:
> >
> >=C2=A0 3.=C2=A0 If including an empty authority field, append the = "//" sigil to
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the URI.
> >
> > No explanation given as to why I might - or might not - want to i= nclude an
> > empty authority (file-auth) field. Some elaboration here would be= nice.
> >
> >
> =E2=80=8BHmm, yes. How about something in the relevant paragraph in se= ction 2, to
> the effect of: "To maximise compatibility with previous specifica= tions,
> implementations MAY include an empty file-auth." ?

That sounds OK to me.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ned

=E2=80=8BOk, I've changed it to:

=C2=A0 =C2=A0As a special cas= e, the =E2=80=9Cfile-auth=E2=80=9D rule can match the string
=C2= =A0 =C2=A0=E2=80=9Clocalhost=E2=80=9D or the empty string; either value is = interpreted as =E2=80=9Cthe
=C2=A0 =C2=A0machine from which the U= RI is being interpreted,=E2=80=9D exactly as if no
=C2=A0 =C2= =A0authority was present. To maximise compatibility with previous
=C2=A0 =C2=A0specifications, implementations MAY choose to include an empt= y
=C2=A0 =C2=A0=E2=80=9Cfile-auth=E2=80=9D.=E2=80=8B
=

Seeing th= at with Chrome's spelling suggestions makes me wonder if I should Ameri= canize all my "-ise" words, or just leave it for the editors.

Cheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a113559928f2afb052460e2cd-- From vladimir.levantovsky@monotype.com Tue Nov 10 07:02:56 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2611B381D for ; Tue, 10 Nov 2015 07:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 3lHae60zGIJh for ; Tue, 10 Nov 2015 07:02:53 -0800 (PST) Received: from p02c11o143.mxlogic.net (p02c11o143.mxlogic.net [208.65.144.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795E41B381A for ; Tue, 10 Nov 2015 07:02:53 -0800 (PST) Received: from unknown [192.5.106.47] (EHLO p02c11o143.mxlogic.net) by p02c11o143.mxlogic.net(mxl_mta-8.5.0-3) with ESMTP id d1702465.2b9071e02940.126684.00-528.363531.p02c11o143.mxlogic.net (envelope-from ); Tue, 10 Nov 2015 08:02:53 -0700 (MST) X-MXL-Hash: 5642071d1cf8ebe0-6157f31c1aafbb045bbff49a17e659e9a215d073 Received: from unknown [192.5.106.47] by p02c11o143.mxlogic.net(mxl_mta-8.5.0-3) over TLS secured channel with SMTP id a1702465.0.126571.00-267.363408.p02c11o143.mxlogic.net (envelope-from ); Tue, 10 Nov 2015 08:02:52 -0700 (MST) X-MXL-Hash: 5642071c2e690a7f-1860e9698cb1f50b6a6185decf473ab7178e5c07 Received: from wob-maildb-03.agfamonotype.org (192.168.65.95) by wob-maildb-04.agfamonotype.org (192.168.65.96) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 10 Nov 2015 10:01:47 -0500 Received: from wob-maildb-03.agfamonotype.org ([fe80::f90b:70d6:b5e2:1c86]) by wob-maildb-03.agfamonotype.org ([fe80::f90b:70d6:b5e2:1c86%17]) with mapi id 15.00.0913.011; Tue, 10 Nov 2015 10:01:48 -0500 From: "Levantovsky, Vladimir" To: Barry Leiba , Sean Leonard Thread-Topic: [apps-discuss] Proposed charter for justfont Thread-Index: AQHRG14P9IIAwU/oyEm/ruf5IAEAGJ6Vf9+AgAAjm4CAAAcGgP//r3Kg Date: Tue, 10 Nov 2015 15:01:47 +0000 Message-ID: References: <564153CD.3010108@w3.org> <11E3E0CE-BD47-4E34-AE24-470DABA6DC98@kitterman.com> <776938B4-A6AE-47FE-9834-CBEB365A6E8D@seantek.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.25.1.21] x-exclaimer-md-config: c271eea4-4802-4476-ab53-9ae654d778b2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=FModsrcs c=1 sm=1 tr=0 a=XOlr6t7Gqt60WzYSt0UKeQ==] X-AnalysisOut: [:117 a=XOlr6t7Gqt60WzYSt0UKeQ==:17 a=2c3nKaCKAAAA:8 a=rfFW] X-AnalysisOut: [i7IFAAAA:8 a=YlVTAMxIAAAA:8 a=JH8vP3xTTU4A:10 a=IkcTkHD0fZ] X-AnalysisOut: [MA:10 a=xqWC_Br6kY4A:10 a=qtqOOiqGOCEA:10 a=48vgC7mUAAAA:8] X-AnalysisOut: [ a=gKztFLWB2YEGE7U-j5UA:9 a=vbtB-Gq4UeihRMJ4:21 a=xVsLPbSl] X-AnalysisOut: [iML5YzgH:21 a=QEXdDO2ut3YA:10] X-Spam: [F=0.5200000000; CM=0.500; MH=0.520(2015111009); S=0.276(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [192.5.106.47] Archived-At: X-Mailman-Approved-At: Thu, 12 Nov 2015 22:10:47 -0800 Cc: Scott Kitterman , IETF Apps Discuss Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 15:26:36 -0000 KzEhDQpGb3IgdGhlIHJlY29yZCwgSSBzdXBwb3J0IHRoZSBwcm9wb3NlZCBjaGFydGVyIGFuZCB3 aWxsIHBhcnRpY2lwYXRlIGluIHRoZSB3b3JrIG9mIHRoaXMgV0cgdG8gYWRkcmVzcyBhbnkgcXVl c3Rpb25zIHRoYXQgbWF5IGFyaXNlIChlLmcuIG9wdGlvbmFsIHBhcmFtZXRlcnMgYW5kIHRoZWly IHB1cnBvc2UpLg0KDQpUaGFuayB5b3UsDQpWbGFkaW1pcg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBhcHBzLWRpc2N1c3MgW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJhcnJ5IExlaWJhDQpTZW50OiBUdWVzZGF5LCBOb3Zl bWJlciAxMCwgMjAxNSA5OjQ3IEFNDQpUbzogU2VhbiBMZW9uYXJkDQpDYzogU2NvdHQgS2l0dGVy bWFuOyBJRVRGIEFwcHMgRGlzY3Vzcw0KU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIFByb3Bv c2VkIGNoYXJ0ZXIgZm9yIGp1c3Rmb250DQoNCj4gSSB3b3VsZCBhbHNvIHJlcXVlc3QgdGhhdCB0 aGUgYXJjaGl2ZSB0b3AtbGV2ZWwgbWVkaWEgdHlwZSBiZSBpbmNsdWRlZCANCj4gaW4gdGhlIFdH IHNjb3BlLg0KDQpJIGhhdmUgYSB2ZXJ5IHN0cm9uZyBpbmNsaW5hdGlvbiBOT1QgdG8gZG8gdGhh dCAodGhvdWdoIEkgd2lsbCBhY2NlcHQgY29uc2Vuc3VzLCBvZiBjb3Vyc2UpLiAgV2UgdHJpZWQg dGhhdDsgdGhlcmUgd2Fzbid0IGVub3VnaCBpbnRlcmVzdCBhbmQgZW5lcmd5IHRvIGdldCBhbnl3 aGVyZSB3aXRoIGl0LiAgSSBkbyBub3Qgd2FudCB0byBzYWRkbGUgdGhpcyB3b3JrIHdpdGggdGhh dCwgYW5kIEkgc3Ryb25nbHkgcHJlZmVyIGEgdGlnaHRseSBmb2N1c2VkIHdvcmtpbmcgZ3JvdXAu DQoNCkJhcnJ5LCBBUlQgRGlyZWN0b3INCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCmFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCmFwcHMtZGlzY3Vz c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRp c2N1c3MNCg== From nobody Thu Nov 12 22:11:04 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D1F1B29F4 for ; Wed, 11 Nov 2015 07:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 YXNpcXL6fkjB for ; Wed, 11 Nov 2015 07:23:55 -0800 (PST) Received: from p02c11o148.mxlogic.net (p02c11o148.mxlogic.net [208.65.144.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 130061B29F1 for ; Wed, 11 Nov 2015 07:23:55 -0800 (PST) Received: from unknown [192.5.106.47] (EHLO p02c11o148.mxlogic.net) by p02c11o148.mxlogic.net(mxl_mta-8.5.0-3) with ESMTP id b8d53465.2b6f51c63940.149109.00-500.420200.p02c11o148.mxlogic.net (envelope-from ); Wed, 11 Nov 2015 08:23:55 -0700 (MST) X-MXL-Hash: 56435d8b3bcbb269-465eec787ddd33cf21972ee35f30a94df8788651 Received: from unknown [192.5.106.47] by p02c11o148.mxlogic.net(mxl_mta-8.5.0-3) over TLS secured channel with SMTP id 88d53465.0.149030.00-380.420113.p02c11o148.mxlogic.net (envelope-from ); Wed, 11 Nov 2015 08:23:54 -0700 (MST) X-MXL-Hash: 56435d8a072b84bd-8bf38b9d0869b1b6ab19ef7fff40da5929036e23 Received: from wob-maildb-03.agfamonotype.org (192.168.65.95) by wob-maildb-04.agfamonotype.org (192.168.65.96) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 11 Nov 2015 10:23:43 -0500 Received: from wob-maildb-03.agfamonotype.org ([fe80::f90b:70d6:b5e2:1c86]) by wob-maildb-03.agfamonotype.org ([fe80::f90b:70d6:b5e2:1c86%17]) with mapi id 15.00.0913.011; Wed, 11 Nov 2015 10:23:43 -0500 From: "Levantovsky, Vladimir" To: Sean Leonard , IETF Apps Discuss Thread-Topic: [apps-discuss] Proposed charter for justfont Thread-Index: AQHRG14P9IIAwU/oyEm/ruf5IAEAGJ6Vf9+AgAAjm4CAAAcGgIAAduuAgAA8ngCAAI048A== Date: Wed, 11 Nov 2015 15:23:43 +0000 Message-ID: <1d8cbc528313478b88fa2c17b9bad893@wob-maildb-03.agfamonotype.org> References: <564153CD.3010108@w3.org> <11E3E0CE-BD47-4E34-AE24-470DABA6DC98@kitterman.com> <776938B4-A6AE-47FE-9834-CBEB365A6E8D@seantek.com> <2BEAD659-98EA-4DA4-9B45-5FC92A03392A@seantek.com> In-Reply-To: <2BEAD659-98EA-4DA4-9B45-5FC92A03392A@seantek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.25.1.29] x-exclaimer-md-config: c271eea4-4802-4476-ab53-9ae654d778b2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=cNvmxwqN c=1 sm=1 tr=0 a=XOlr6t7Gqt60WzYSt0UKeQ==] X-AnalysisOut: [:117 a=XOlr6t7Gqt60WzYSt0UKeQ==:17 a=2c3nKaCKAAAA:8 a=rfFW] X-AnalysisOut: [i7IFAAAA:8 a=YlVTAMxIAAAA:8 a=fQfWnCFtOYMA:10 a=IkcTkHD0fZ] X-AnalysisOut: [MA:10 a=xqWC_Br6kY4A:10 a=qtqOOiqGOCEA:10 a=B6KMzFptAAAA:2] X-AnalysisOut: [0 a=CE3YtXpAWNsEY1PRXOsA:9 a=QEXdDO2ut3YA:10] X-Spam: [F=0.5200000000; CM=0.500; MH=0.520(2015111106); S=0.363(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [192.5.106.47] Archived-At: X-Mailman-Approved-At: Thu, 12 Nov 2015 22:11:02 -0800 Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 15:23:57 -0000 SGkgYWxsLA0KDQpBcyBhIGJyaWVmIGludHJvZHVjdGlvbiwgSSBhbSBWbGFkaW1pciBMZXZhbnRv dnNreSBmcm9tIE1vbm90eXBlIGFuZCBJIGFsc28gc2VydmUgYXMgYSBjaGFpciBvZiB0aGUgVzND IFdlYkZvbnRzIFdHIGFuZCBhcyBJU08gcHJvamVjdCBlZGl0b3IgZm9yIElTTy9JRUMgMTQ0OTYt MjIgT3BlbiBGb250IEZvcm1hdCAoT0ZGKSBzcGVjLg0KDQpPbiBUdWVzZGF5LCBOb3ZlbWJlciAx MCwgMjAxNSA4OjMwIFBNIFNlYW4gTGVvbmFyZCB3cm90ZToNCg0KPiBBbGwgcmlnaHQsIGZpbmUu IEJ1dCB3aGVuIHdlIHNheSB0aWdodCBmb2N1cywganVzdCBrZWVwIGl0IGFzIG11Y2ggYXMgcG9z c2libGUgb24gdGhlIA0KPiB0b3AtbGV2ZWwgbWVkaWEgdHlwZSByZWdpc3RyYXRpb24uDQo+DQo+ IEkgc2VlIOKAnG1ha2luZyBpbml0aWFsIHJlZ2lzdHJhdGlvbnMgaW4gImZvbnQi4oCdIHRvIGJl IGEgcG9zc2libGUgYmxhY2sgaG9sZS4gSSBhbHNvIHNlZSBkZWZpbmluZyANCj4gY29tbW9uIHBh cmFtZXRlcnMgKG9yIHdheXMgdG8gYWNjb21tb2RhdGUgdGhlbSkgYmV0d2VlbiAiZm9udCIgcmVn aXN0cmF0aW9ucywgYWxzbyANCj4gdG8gYmUgYSBibGFjayBob2xlLiBCbGFjayBob2xlID0gbGlr ZWx5IHRvIGRlcmFpbCB0aWdodCBmb2N1cy4NCj4NCg0KVGhlIGN1cnJlbnQgcHJvcG9zYWwgYXR0 ZW1wdHMgdG8gcmVwbGljYXRlIHRoZSBzYW1lIHN0cnVjdHVyZSBvZiBzdWJ0eXBlcyB0aGF0IHdl cmUgZGVmaW5lZCBmb3IgZm9udC1yZWxhdGVkIHN1YnR5cGVzIGluIHRoZSAiYXBwbGljYXRpb24i IHRyZWUsIHNvIHdoYXQgdXNlZCB0byBiZSBkZWZpbmVkIGFzIGFwcGxpY2F0aW9uL2ZvbnQtd29m ZiB3b3VsZCBub3cgYmUgc2ltcGx5IGZvbnQvd29mZi4NCg0KPiBQYXJ0IG9mIHRoaXMgaXMgYmVj YXVzZSB0aGVyZSBpcyBubyBjb21tb24gZGF0YSBmb3JtYXQgY29uZ3J1ZW5jZSB3aXRoaW4gdGhl IHByb3Bvc2VkIA0KPiBmb250IHR5cGVzLCBzbyBTZWN0aW9uIDQgb2YgZHJhZnQtMDAgc2F5cyDi gJxVbnJlY29nbml6ZWQgc3ViLXR5cGVzIG9mICJmb250IiBzaG91bGQgYmUgdHJlYXRlZCANCj4g YXMgImFwcGxpY2F0aW9uL29jdGV0LXN0cmVhbSIu4oCdIFRoZW4gaXQgc2F5cyDigJxJbXBsZW1l bnRhdGlvbnMgbWF5IHBhc3MgdW5yZWNvZ25pemVkIHN1YnR5cGVzIA0KPiB0byBhIGNvbW1vbiBm b250LWhhbmRsaW5nIHN5c3RlbSwgaWYgc3VjaCBzeXN0ZW0gaXMgYXZhaWxhYmxlLuKAnQ0KDQpJ IHN0cm9uZ2x5IGRpc2FncmVlIHdpdGggdGhlIHNlbnRpbWVudC4gVGhlIE9wZW5UeXBlIC8gT0ZG IHN0YW5kYXJkIGRlZmluZXMgYSBjb21tb24gZGF0YSBmb3JtYXQgd2hlcmUgVHJ1ZVR5cGUsIEFk b2JlIENGRiwgYW5kIG5vdyBTVkcgb3V0bGluZXMgY2FuIHBlYWNlZnVsbHkgY29leGlzdCwgYW5k IHRoZSBsaXN0IGRvZXNu4oCZdCBzdG9wIHRoZXJlLiBBdCBhIGhpZ2hlciBsZXZlbCwgYWxsIG1v ZGVybiBmb250IGRhdGEgZm9ybWF0cyAoT3BlblR5cGUvT0ZGLCBBQVQsIFNJTCkgc2hhcmUgdGhl IHNhbWUgU0ZOVCBkYXRhIHN0cnVjdHVyZSBzbyBjb25zaWRlcmluZyB0aGF0IHRoZXJlIGFyZSBh IG51bWJlciBvZiBvZmZpY2lhbGx5IHN0YW5kYXJkaXplZCBnbHlwaCBvdXRsaW5lIGZvcm1hdHMg KHNlZSBhYm92ZSkgYW5kIHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIHZhcmlvdXMgU0ZOVC1iYXNl ZCBmb250IGZvcm1hdHMgYXJlIHNwZWNpZmljIHRvIHZhcmlhdGlvbnMgaW4gc3VwcG9ydGVkIHRl eHQgbGF5b3V0IG1lY2hhbmlzbXMgLSB0aGUgc3VidHlwZXMgYW5kIHRoZSBvcHRpb25hbCBwYXJh bWV0ZXJzIHRoYXQgYXJlIHByb3Bvc2VkIGFzIHBhcnQgb2YgdGhlIGZvbnQvKiB0cmVlIChhbmQg dGhvc2UgdGhhdCBoYXZlIGJlZW4gcmVnaXN0ZXJlZCB0byBkYXRlIGFzIHBhcnQgb2YgdGhlIGFw cGxpY2F0aW9uIHRyZWUpIGFyZSBhbGwganVzdGlmaWVkIGJ5IHByYWdtYXRpYyBjb25zaWRlcmF0 aW9ucyBvZiB3aGF0IGlzIHVzZWQgdGhlc2UgZGF5cy4NCg0KPiAoSSBzdWJtaXQgdGhhdCB0aGVy ZSBpcyBubyBjb21tb25hbGl0eS4gSW4gdGhlIGV4ZW1wbGFyeSByZWdpc3RyYXRpb25zLCBmb250 L3NmbnQgfiBmb250L290ZiB+IA0KPiBmb250L3R0ZiBidXQgIT0gZm9udC93b2ZmLiBUaGF0IGlz IGJlY2F1c2UgV09GRiBpcyBjb21wcmVzc2VkLiBNYXliZSBJIGRvbuKAmXQgdW5kZXJzdGFuZCAN Cj4gdGhlIGNvbW1vbmFsaXR5IG9mIHRoZSBkYXRhIGZvcm1hdHMuIEFuZCB3aGF0IGFib3V0IFBv c3RTY3JpcHQgVHlwZSAxIGZvbnRzIHN1Y2ggYXMgLnBmYj8pDQoNCk1lbWJlcnMgb2YgV2ViRm9u dHMgV0cgaGF2ZSBjb25kdWN0ZWQgZXh0ZW5zaXZlIHN0dWR5IG9mIG1lZGlhIHR5cGVzIHRoYXQg YXJlIGluIHVzZSB0aGVzZSBkYXlzOg0KaHR0cHM6Ly9kb2NzLmdvb2dsZS5jb20vZG9jdW1lbnQv ZC8xVHNqdTZFT1A0THFKMVJjRkpScHF4cnlnZ2JXWllicTVqdnNJaFZZTm95VS9lZGl0DQpBcyBt dWNoIGFzIGl0IG1ha2VzIHNlbnNlIHRvIG1ha2UgdGhlIG5ldyBzZXQgb2YgbWVkaWEgdHlwZXMg Zm9yIGZvbnRzIGludHVpdGl2ZSBhbmQgZWFzeSB0byB1c2UsIHdlIGFyZSBub3QgYXQgYWxsIGlu dGVyZXN0ZWQgaW4gcmVzdXJyZWN0aW5nIGFsbCBhbmNpZW50IGZvbnQgZm9ybWF0cyB0aGF0IGhh ZCBzZWVuIHRoZSBsaWdodCBvZiBkYXkgYXQgc29tZSBwb2ludCBvZiB0aGUgbGFzdCBjZW50dXJ5 IC0gdGhlIHByb3Bvc2FsIGlzIHJvb3RlZCBpbiBvYnNlcnZhdGlvbnMgb2Ygd2hhdCB0aGUgbWFq b3JpdHkgb2YgZm9sa3MgdXNlIHRoZXNlIGRheXMgKGkuZS4sIG1vcmUgb2Z0ZW4gdGhhbiBub3Qg dGhleSBzaW1wbHkgdXNlIGEgbWVkaWEgdHlwZSB0aGV5IF90aGlua18gd291bGQgbWFrZSBzZW5z ZSB0byB1c2UsIGFuZCBkb27igJl0IGV2ZW4gYm90aGVyIGNoZWNraW5nIGlmIGl0J3MgYWN0dWFs bHkgZGVmaW5lZCkgYW5kIHNpbXBsZSBwcmFnbWF0aWMgY29uc2lkZXJhdGlvbnMgaXMgd2hhdCdz IGRyaXZpbmcgb3VyIGRlY2lzaW9ucyBhbmQgdGhpcyBwcm9wb3NhbC4NCg0KPiBUaGUgc29vbmVy IHdlIGNhbiBkZWNsYXJlIHRoYXQgdGhlcmUgaXMgbm8gY29tbW9uYWxpdHkgaW4gZGF0YSBmb3Jt YXQsIHRoZSB0aWdodGVyIHdlIGNhbiANCj4gbWFrZSB0aGUgc2NvcGUgYW5kIHRoZSBzb29uZXIg dGhlIFdHIGNhbiBmaW5pc2ggaXRzIHdvcmsuDQoNCklNTywgd2lzaGluZyBzb21ldGhpbmcgY29t ZSB0cnVlIChvciBkZWNsYXJpbmcgc29tZXRoaW5nIHRvIG5vdCBiZSB0aGUgY2FzZSBldmVuIGlm IGl0IGlzKSBkb2VzbuKAmXQgd29yayAtIHRoZSByZWFsaXR5IGFsd2F5cyBwcmV2YWlscy4NCg0K VGhhbmsgeW91LA0KVmxhZA0KDQo= From nobody Thu Nov 12 23:53:04 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C6A1B41D4 for ; Thu, 12 Nov 2015 23:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25L8BNntXT3Z for ; Thu, 12 Nov 2015 23:53:00 -0800 (PST) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0139.outbound.protection.outlook.com [104.47.125.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E840E1B41D6 for ; Thu, 12 Nov 2015 23:52:59 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS1PR01MB0134.jpnprd01.prod.outlook.com (10.161.228.15) with Microsoft SMTP Server (TLS) id 15.1.325.17; Fri, 13 Nov 2015 07:52:55 +0000 To: "Levantovsky, Vladimir" , Sean Leonard , IETF Apps Discuss References: <564153CD.3010108@w3.org> <11E3E0CE-BD47-4E34-AE24-470DABA6DC98@kitterman.com> <776938B4-A6AE-47FE-9834-CBEB365A6E8D@seantek.com> <2BEAD659-98EA-4DA4-9B45-5FC92A03392A@seantek.com> <1d8cbc528313478b88fa2c17b9bad893@wob-maildb-03.agfamonotype.org> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <564596D1.2040708@it.aoyama.ac.jp> Date: Fri, 13 Nov 2015 16:52:49 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1d8cbc528313478b88fa2c17b9bad893@wob-maildb-03.agfamonotype.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR01CA0006.jpnprd01.prod.outlook.com (25.161.131.144) To OS1PR01MB0134.jpnprd01.prod.outlook.com (25.161.228.15) X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0134; 2:0ZwCUuCDpL4VxcInEB6xhAvBzy7QuzRi2/i9Ovaw72IX7SmnudSaY+/ktTUWqEwhhLTeTZ9VIRgC24PhEgRYMEFQ7D5NtWGlVMZwfRz3NyZdn1ki46o158iuN5/2lxB/2f9gzpNw9+/Z5Pkcu9ioY4BAlwHfpOM8DQrEfR60kak=; 3:/xGLvD5k2o9xs4zENzCU/4/ui1LO4fXW/63SXO07waQqIN4ZbZ+fuF2sWMUyGT2WXOQEc5VYtVbUboB+uB/2HhjaJBcUXsVphNBIpbXfiHirlMl5of4igUIxEf54LmSEhque0KGMLUH508Ee/7H5cQ==; 25:q4b5U0rZly0a8TwDPHedDGQik3+KF4elU8ExX1agPl/K8tkPVaOOg5sz0feNYKTV7v/Aruo/6+AAP6K611etJKk60vxZg7DPQKEtpp5UGqPnAnYgGvl4AY0eaywylQv0D7nmRkcn2vZeJBEE9SNVXg+DF8fVA2csKvQleYOD8p6bGA6hRWaTiEagfVuCxnLzBEtDo4kcRExBU2mTQnyNAIfNSSo9vtIFOLirG5bE74SYZkB9T3kuBkSbDXn9Z7zMA9QFQyIL8iBh3Mbr8LaUtA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS1PR01MB0134; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(211936372134217); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046); SRVR:OS1PR01MB0134; BCL:0; PCL:0; RULEID:; SRVR:OS1PR01MB0134; X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0134; 4:rsQfREVAUXj2NA+tqjLxxp7ItuRVR7ikRtrUJgGKxAUOhsysWrkXfHg+g5TohB2MJTnKb/Cr5BY8uG/5+ZMnfaZzqW6jYTSwRHJHWBTeYavri+dwnUM7NPnOHPtH7hzKOWLvJE+tWvOWaJVN4HuPBFuS7BOI/ENaVX7aPTvd944H+mbP8I7/39hrRa3ChP0WQM6mqvprjD8NcYY3hqimI5pFtcVoiz44HSj3BcLMhZUBqPScst+5EKL90qXbyNBcjc7oCFN4902vulUXvGy3LiUskT0/WXkptOpePHJmQzA5MEfcTrhJj0h/TKB93p+yWqxgxpp2HUnsTPKSTW+CPhQROEwRx9wE+t9t1OASGVHIlsaRL74aFzFe14yzjJlM X-Forefront-PRVS: 0759F7A50A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(189002)(24454002)(479174004)(199003)(377454003)(77096005)(87976001)(5004730100002)(5007970100001)(47776003)(66066001)(83506001)(65956001)(65806001)(64126003)(122386002)(33656002)(42186005)(86362001)(561944003)(23676002)(93886004)(40100003)(50466002)(74482002)(59896002)(99136001)(65816999)(76176999)(50986999)(87266999)(105586002)(54356999)(2950100001)(106356001)(5008740100001)(101416001)(81156007)(5001770100001)(92566002)(5001960100002)(19580395003)(97736004)(107886002)(80316001)(5002510100001)(15975445007)(4001350100001)(189998001)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS1PR01MB0134; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzFQUjAxTUIwMTM0OzIzOnBPdWRSa0wzelkvTWNRVExrd1dxTUR4NHVE?= =?utf-8?B?S0xVTWw0YS9YN1VEV2JPTG95VVRGaUNCN0U3Rk14UWNPdVlTVERDZm9lM0VX?= =?utf-8?B?Z3dlaHdOL0wwVS9jYkdqeU91ZUhDeTVQUWl6cWUyWGxpWGhvTlZueWV5Rkhp?= =?utf-8?B?TzZDNTRGKytBWG5WUDR3Z2hSMEY5aEQzUHJxaWE2NjdTNUJSUDQrY3BtYkgz?= =?utf-8?B?aGZEQStGaFRRK1RsajRmY1VxcUNVVFJ0VlhxMk04Zlc3TkxkQ1BPenUzU1Jo?= =?utf-8?B?VEVBM3lSUklGZWFIc1REM3BTVmwvcTlHY0JoWXJpSDJocmxtWm5RVUs1b29h?= =?utf-8?B?c0lPbzV0ZTRSNnFwaU5rMXh5MlQxZFNYQ0hWUzJ4b0tocVRWMTNVZElPR00x?= =?utf-8?B?Tkl5dlcyMkNDcCs1ZU94ZDZ6MlRYL3IyTTFFWmJONlN6NURreThnbFVGdWxJ?= =?utf-8?B?SUV3SE9ZSk9mYTZnc2h5eUdRUEkvZ205Z3ZzTFM4UHRtMlF6Z00vQTBpWWh0?= =?utf-8?B?MUpuYmxxOEcvNjB0Y1JhR0Nsb01YYlFQclpXa1hzTXJnaVBlZ0l3MGtJMHRE?= =?utf-8?B?dEdqdW9SVlB1K2RSbU1VcnZ6MmUwKy8weVBVc0VYN25EQVZoRC95SHRmUFJV?= =?utf-8?B?OEkyZGR5T3MyaXlzMnhqc2JxU2lQbStzTTVoRE5ZWmtqV2JZVDBESE04dTVG?= =?utf-8?B?VDZ6ZEtNbkhIaTFDYnpaZjc5REtJS2FwTHZIT2xVblk1V1JRZHI4RHRJQWJj?= =?utf-8?B?dXQyVW5ZbmtMNTdBT3IxNkJRVXE3TWRoSmduQjRwS1VEMVFlTDF6TzdmR2tV?= =?utf-8?B?VGMwQU1nU2lROUFuZDFDamJ6dFJ5bG9jZUh5RWNFYmhKVVNzblhlVWVnSzM0?= =?utf-8?B?TkRBQ2J0MkJ0TmV2M3pOazMvcnBObEJzKzUzUHR0SzhneHFlL1RLdHhxU1NE?= =?utf-8?B?Z1pqbTJhcUFjcWEwamVwZDRhTG9yR2Y5ZHZkdDRBZFVmQnlrUkp5SkpWUUpj?= =?utf-8?B?TFlhY2dBdVlidmpvZCtPUnhkUVlHd3M3a09xamN1dmFGTU5oZTlMSTN5TGlY?= =?utf-8?B?WkZ5L3YyTkdxQ05GZ0tnTy9MaVlxRDVLcDliNHltdWQ1RlhWWkp5N1lWU1p4?= =?utf-8?B?SFRKVVI2REczQll4VUduSHpRZUJBa0FVeFlsYlZqL0dlZUtiellzL2x2OTFJ?= =?utf-8?B?VHBTQnNRSkcvRXR0bmtycnR5RlYzYld4cjFwajluUWlwWW5ZUFlmNW4wVFJ6?= =?utf-8?B?VUFYcGJzQ3l4c3BkNTJMczMxbUxDdzdjYTEzcDY4cmNaV0NhMndBQmhqN0hM?= =?utf-8?B?c3pxOHg1YmRGVmhDUmZjMytsY3hOSXp2QTIvL3ViZDdCUXNzQTE5QUVSZ2Vq?= =?utf-8?B?QnluYnptUWhmT0dHeUR0U3BOYS9uczNSejczbHdkWmxYQm1EVkRmRWZva0xj?= =?utf-8?B?QkxPUWZtMnpwOWM0b0RwUjdOVlNiT2NvN0JTZHAwRW5kMUc5cnZqU3o1cE1E?= =?utf-8?B?RnB3V0pLU0x0ZHF0TlBiT2tOdXdjdDJpVFZBRm41eUxkeUhHMVNQc1ZvNklC?= =?utf-8?B?VnhlTXVvMHNGYnU0YkhLOXkxSjNOc0k1ZkpoZG9GSkl2b1JOTXJFY29wK0FH?= =?utf-8?B?bnYzQzZJRVo0VGh6c1FickNrSUp3dEJsQUI1c1d0ZFNZeVdEZ0tydDNpaGlv?= =?utf-8?B?TXVnelBtM2JPZnc1K2hYV0RHaHYwRnV0QzZKemtoQ3lBRDNDY3FRaFZRUzJL?= =?utf-8?B?V1VBdTI2S0FKNlhrUWdTY2FLcU02K1Y3bG1JYUV2NEk1emMxbDRmaHJRV1V1?= =?utf-8?B?bVltaDU0aVR6WHRqTzdtQThBUkZNejIyYStGTFluQmJSTlJNSVRVcUZVanRx?= =?utf-8?Q?nZtexBGYvI0=3D?= X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0134; 5:4Fzfzy8KAh2uTkf4Koi2zC5u+NztLLn4g+eJtNWa2qBXHxy3Ub0ueOBcGkyhjlVDru52MAZHen6YbJMkIlduhK/oeVcYVJR0cJ5tCasv8PrHxaWcT1eSf+pXKctJN3XoC94QfLJ7QKqEIs/uJwN9Ig==; 24:B/EYFguk+LQEIij1Q6glW/UIVLZiVeQYIlBxpbqxHaPdF/56wiPgMbPVH1hZk4c773jsjm5OQLoaIOyZOdMiTMGYvsFyqTg6kA0EgOA2iQM=; 20:b0CBIgT6jy9fQ/ttMtwB1pDkuMl/fkEFfU+UAwo983RyJGX6qGBqzNbyFrf0YTni/ZJZAKOmS8sTgnzOZPeQWg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Nov 2015 07:52:55.7280 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS1PR01MB0134 Archived-At: Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 07:53:03 -0000 Hello Vlad, On 2015/11/12 00:23, Levantovsky, Vladimir wrote: > On Tuesday, November 10, 2015 8:30 PM Sean Leonard wrote: >> (I submit that there is no commonality. In the exemplary registrations, font/sfnt ~ font/otf ~ >> font/ttf but != font/woff. That is because WOFF is compressed. Maybe I don’t understand >> the commonality of the data formats. And what about PostScript Type 1 fonts such as .pfb?) > > Members of WebFonts WG have conducted extensive study of media types that are in use these days: > https://docs.google.com/document/d/1Tsju6EOP4LqJ1RcFJRpqxryggbWZYbq5jvsIhVYNoyU/edit > As much as it makes sense to make the new set of media types for fonts intuitive and easy to use, we are not at all interested in resurrecting all ancient font formats that had seen the light of day at some point of the last century - the proposal is rooted in observations of what the majority of folks use these days (i.e., more often than not they simply use a media type they _think_ would make sense to use, and don’t even bother checking if it's actually defined) and simple pragmatic considerations is what's driving our decisions and this proposal. I agree that the proposal should focus on what's most used these days, and what the proposers are most interested in. >> The sooner we can declare that there is no commonality in data format, the tighter we can >> make the scope and the sooner the WG can finish its work. > > IMO, wishing something come true (or declaring something to not be the case even if it is) doesn’t work - the reality always prevails. I think saying that there's no commonality between formats is wrong. But implying that all formats have the same commonalities (except obviously that they are fonts) is also wrong. As an example, I'd never request the WG to register something like font/bdf, but I'd expect that we set up the top level type and the registration so that somebody could register font/bdf if they needed to. [If all of what I said above seems obvious, please just ignore :-] Regards, Martin. From nobody Fri Nov 13 09:44:52 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99211B305C for ; Fri, 13 Nov 2015 09:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 iCGfSI6TUOYQ for ; Fri, 13 Nov 2015 09:44:48 -0800 (PST) Received: from p02c11o145.mxlogic.net (p02c11o145.mxlogic.net [208.65.144.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFEA31B3058 for ; Fri, 13 Nov 2015 09:44:48 -0800 (PST) Received: from unknown [192.5.106.48] (EHLO wob-maildb-04.agfamonotype.org) by p02c11o145.mxlogic.net(mxl_mta-8.5.0-3) with ESMTP id 09126465.2b57e981b940.250628.00-550.700753.p02c11o145.mxlogic.net (envelope-from ); Fri, 13 Nov 2015 10:44:48 -0700 (MST) X-MXL-Hash: 564621904b8495f3-266c7444783c7ca0a08f0a9eb477f4d0856c55c1 Received: from unknown [192.5.106.48] (EHLO wob-maildb-04.agfamonotype.org) by p02c11o145.mxlogic.net(mxl_mta-8.5.0-3) over TLS secured channel with ESMTP id b8126465.0.250567.00-297.700579.p02c11o145.mxlogic.net (envelope-from ); Fri, 13 Nov 2015 10:44:45 -0700 (MST) X-MXL-Hash: 5646218d4f759218-8f6f2b10eede6269bb6c277d153630ecc12bb40a Received: from wob-maildb-03.agfamonotype.org (192.168.65.95) by wob-maildb-04.agfamonotype.org (192.168.65.96) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 13 Nov 2015 12:44:41 -0500 Received: from wob-maildb-03.agfamonotype.org ([fe80::f90b:70d6:b5e2:1c86]) by wob-maildb-03.agfamonotype.org ([fe80::f90b:70d6:b5e2:1c86%17]) with mapi id 15.00.0913.011; Fri, 13 Nov 2015 12:44:41 -0500 From: "Levantovsky, Vladimir" To: =?utf-8?B?TWFydGluIEouIETDvHJzdA==?= , "Sean Leonard" , IETF Apps Discuss Thread-Topic: [apps-discuss] Proposed charter for justfont Thread-Index: AQHRG14P9IIAwU/oyEm/ruf5IAEAGJ6Vf9+AgAAjm4CAAAcGgIAAduuAgAA8ngCAAI048IADAmmAgABMBgA= Date: Fri, 13 Nov 2015 17:44:41 +0000 Message-ID: <6a9de4b3942c4f52a562233e9c004cea@wob-maildb-03.agfamonotype.org> References: <564153CD.3010108@w3.org> <11E3E0CE-BD47-4E34-AE24-470DABA6DC98@kitterman.com> <776938B4-A6AE-47FE-9834-CBEB365A6E8D@seantek.com> <2BEAD659-98EA-4DA4-9B45-5FC92A03392A@seantek.com> <1d8cbc528313478b88fa2c17b9bad893@wob-maildb-03.agfamonotype.org> <564596D1.2040708@it.aoyama.ac.jp> In-Reply-To: <564596D1.2040708@it.aoyama.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.93.87.55] x-exclaimer-md-config: c271eea4-4802-4476-ab53-9ae654d778b2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=Xa6PudN5 c=1 sm=1 tr=0 a=wyIouNo9IjkfSHuI6pvFag==] X-AnalysisOut: [:117 a=wyIouNo9IjkfSHuI6pvFag==:17 a=2c3nKaCKAAAA:8 a=rfFW] X-AnalysisOut: [i7IFAAAA:8 a=YlVTAMxIAAAA:8 a=aAeE378k-PMA:10 a=IkcTkHD0fZ] X-AnalysisOut: [MA:10 a=xqWC_Br6kY4A:10 a=qtqOOiqGOCEA:10 a=uo-iMVIFn7Clz6] X-AnalysisOut: [QOwdgA:9 a=QEXdDO2ut3YA:10] X-Spam: [F=0.5200000000; CM=0.500; MH=0.520(2015111318); S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [192.5.106.48] Archived-At: Subject: Re: [apps-discuss] Proposed charter for justfont X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 17:44:51 -0000 SGkgTWFydGluLA0KDQpPbiBGcmlkYXksIE5vdmVtYmVyIDEzLCAyMDE1IDI6NTMgQU0gTWFydGlu IEouIETDvHJzdCB3cm90ZToNClRvOiBMZXZhbnRvdnNreSwgVmxhZGltaXI7IFNlYW4gTGVvbmFy ZDsgSUVURiBBcHBzIERpc2N1c3MNClN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBQcm9wb3Nl ZCBjaGFydGVyIGZvciBqdXN0Zm9udA0KDQo+IE9uIDIwMTUvMTEvMTIgMDA6MjMsIExldmFudG92 c2t5LCBWbGFkaW1pciB3cm90ZToNCg0KPj4gT24gVHVlc2RheSwgTm92ZW1iZXIgMTAsIDIwMTUg ODozMCBQTSBTZWFuIExlb25hcmQgd3JvdGU6DQoNCj4+PiBUaGUgc29vbmVyIHdlIGNhbiBkZWNs YXJlIHRoYXQgdGhlcmUgaXMgbm8gY29tbW9uYWxpdHkgaW4gZGF0YSANCj4+PiBmb3JtYXQsIHRo ZSB0aWdodGVyIHdlIGNhbiBtYWtlIHRoZSBzY29wZSBhbmQgdGhlIHNvb25lciB0aGUgV0cgY2Fu IGZpbmlzaCBpdHMgd29yay4NCj4+DQo+PiBJTU8sIHdpc2hpbmcgc29tZXRoaW5nIGNvbWUgdHJ1 ZSAob3IgZGVjbGFyaW5nIHNvbWV0aGluZyB0byBub3QgYmUgdGhlIGNhc2UgZXZlbiBpZiBpdCBp cykgZG9lc27igJl0IHdvcmsgLSB0aGUgcmVhbGl0eSBhbHdheXMgcHJldmFpbHMuDQo+DQo+SSB0 aGluayBzYXlpbmcgdGhhdCB0aGVyZSdzIG5vIGNvbW1vbmFsaXR5IGJldHdlZW4gZm9ybWF0cyBp cyB3cm9uZy4gQnV0IGltcGx5aW5nIHRoYXQgYWxsIA0KPiBmb3JtYXRzIGhhdmUgdGhlIHNhbWUg Y29tbW9uYWxpdGllcyAoZXhjZXB0IG9idmlvdXNseSB0aGF0IHRoZXkgYXJlIGZvbnRzKSBpcyBh bHNvIHdyb25nLg0KDQpBZ3JlZS4gSXQganVzdCBoYXBwZW5zIHRoYXQgbW9zdCBvZiB0aGUgd2lk ZWx5IHVzZWQgZm9udCBmb3JtYXRzIHRvZGF5ICh3aGljaCBpcyB1bHRpbWF0ZWx5IHJlZmxlY3Rl ZCBpbiB0aGUgY3VycmVudCBwcm9wb3NhbCkgaGF2ZSBhIGhpZ2ggZGVncmVlIG9mIGNvbW1vbmFs aXR5IGJ1dCB5ZXMsIGhpc3RvcmljYWxseSwgdGhlcmUgaGF2ZSBiZWVuIHNpZ25pZmljYW50IGRp ZmZlcmVuY2VzIGJldHdlZW4gZm9udCBmb3JtYXRzLiBJdCdzIHBlcmZlY3RseSBub3JtYWwgdG8g aGF2ZSBubyBjb21tb25hbGl0eSBiZXR3ZWVuIGUuZy4gc2NhbGFibGUgdmVjdG9yIGZvbnRzIGFu ZCBiaXRtYXAgZm9udHMuDQoNCj4gQXMgYW4gZXhhbXBsZSwgSSdkIG5ldmVyIHJlcXVlc3QgdGhl IFdHIHRvIHJlZ2lzdGVyIHNvbWV0aGluZyBsaWtlIGZvbnQvYmRmLCBidXQgSSdkIGV4cGVjdA0K PiB0aGF0IHdlIHNldCB1cCB0aGUgdG9wIGxldmVsIHR5cGUgYW5kIHRoZSByZWdpc3RyYXRpb24g c28gdGhhdCBzb21lYm9keSBjb3VsZCByZWdpc3RlciBmb250L2JkZg0KPiBpZiB0aGV5IG5lZWRl ZCB0by4NCg0KWWVzLCBhYnNvbHV0ZWx5LiBPbmNlIHRoZSB0b3AtbGV2ZWwgdHlwZSBpcyBlc3Rh Ymxpc2hlZCwgYW55b25lIGNhbiByZWdpc3RlciB0aGUgc3VidHlwZXMgdGhleSBuZWVkLCBhbmQg YnkgIm5lZWQiIEkgbWVhbiBhbnl0aGluZyB0aGF0IG1heSBiZSB1c2VmdWwgd291bGQgYmUgYSBn b29kIHRoaW5nIHRvIHJlZ2lzdGVyIChvbGQgb3IgbmV3KSBpZiBpdCdzIGFjdHVhbGx5IHVzZWQu DQoNCkNoZWVycywNClZsYWQNCg0K From nobody Sat Nov 14 12:29:10 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5F91AD0BE for ; Sat, 14 Nov 2015 12:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jYjXbcJiDew for ; Sat, 14 Nov 2015 12:29:08 -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 02CDD1ACF54 for ; Sat, 14 Nov 2015 12:29:07 -0800 (PST) Received: (qmail 11035 invoked from network); 14 Nov 2015 20:29:06 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 14 Nov 2015 20:29:06 -0000 Date: 14 Nov 2015 20:28:44 -0000 Message-ID: <20151114202844.9601.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org In-Reply-To: <56476A62.5070201@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: dcrocker@bbiw.net, apps-discuss@ietf.org Subject: Re: [apps-discuss] [DNSOP] Registry of non-service _prefix names and draft-crocker-dns-attrleaf-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Nov 2015 20:29:10 -0000 >Done. > >This will be the third or fourth try for the document. Perhaps there is >now enough community interest to make it happen? The more I look at this, the more of a mess I find. It's not like it would have been all up to you. RFC 6335 came out five years after the first version of your draft and would have been a fine opportunity to de-mess. Assuming the places in the draft where you refer to the left-most name you mean the right-most name for what gets registered, it needs to make clear what names enable what sub-names. For example, if a name is _tcp or _udp, all of the names in the RFC 6335 service name registry are eligible. This includes _soap-beep and _xmlrpc-beep which are in that registry, and _certificates and _crls which should be but aren't. But RFC 2782 is pretty casual about what protocols other than _tcp and _udp correspond to SRV names. IANA has a protocol registry at http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml but a lot of the entries are not obvious candidates for SRV. On the other hand, RFC 5509 makes _sip a SRV protocol name even though it's also a service. DKIM currently allows _adsp as a subtag, probably not worth making a registry, since there don't seem to be any other likely DKIM subtags. Similarly there's _report._dmarc which seems to be a one-off. R's, John From nobody Sat Nov 14 15:26:11 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B88F1A8F44; Sat, 14 Nov 2015 15:26:09 -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 eCC5rhABXZDD; Sat, 14 Nov 2015 15:26:07 -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 BFF801A8AAF; Sat, 14 Nov 2015 15:26:07 -0800 (PST) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id tAENQ65I016446 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 14 Nov 2015 15:26:06 -0800 References: <20151114202844.9601.qmail@ary.lan> To: John Levine From: Dave Crocker X-Enigmail-Draft-Status: N1110 Organization: Brandenburg InternetWorking Message-ID: <5647C30C.10302@dcrocker.net> Date: Sat, 14 Nov 2015 15:26:04 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151114202844.9601.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 14 Nov 2015 15:26:06 -0800 (PST) Archived-At: Cc: dnsop@ietf.org, dcrocker@bbiw.net, apps-discuss@ietf.org Subject: Re: [apps-discuss] [DNSOP] Registry of non-service _prefix names and draft-crocker-dns-attrleaf-07 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: Sat, 14 Nov 2015 23:26:09 -0000 On 11/14/2015 12:28 PM, John Levine wrote: > RFC 6335 came out five years after the > first version of your draft and would have been a fine opportunity to > de-mess. Given what it was trying to do, I don't think they could reasonably have tackled this topic. However I suppose it's nice that they sought to enfoce a "no underscores" rule for their table, since it facilitates the re-use of the names under SRV. The more serious problem, IMO, is that the SRV spec has such a fuzzy spec for the alternative names that might be used besides _udp and _tcp. I tried to accommodate this actively in the earliest versions of the draft -- even to the point of having the registry be hierarchical -- but seem to have fallen back to something as fuzzy as the SRV spec itself. I finally decided flat organization suffices but didn't care the requirement for explicit registration forward. Yuck. At this point, after looking at the relevant SRV spec text again, I believe the only respectable solution is to change that part of the SRV spec and dictate that the service names must be registered in this IANA table. I do not see a "inherited from the IANA service names table" model as being viable, since it almost encourages name collisions. > Assuming the places in the draft where you refer to the left-most name > you mean the right-most name for what gets registered, it needs to > make clear what names enable what sub-names. oh my. ummm. yes. i only wish i could attribute this to alcohol or dyslexia. > For example, if a name is _tcp or _udp, all of the names in the RFC > 6335 service name registry are eligible. This includes _soap-beep and > _xmlrpc-beep which are in that registry, and _certificates and _crls > which should be but aren't. But RFC 2782 is pretty casual about what > protocols other than _tcp and _udp correspond to SRV names. IANA has > a protocol registry at > http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml > but a lot of the entries are not obvious candidates for SRV. On the > other hand, RFC 5509 makes _sip a SRV protocol name even though it's > also a service. > > DKIM currently allows _adsp as a subtag, probably not worth making a > registry, since there don't seem to be any other likely DKIM subtags. > Similarly there's _report._dmarc which seems to be a one-off. For got that. Thought it was indepedent. ADSP is now removed from the draft. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Nov 15 19:07:17 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528681B2A6D for ; Sun, 15 Nov 2015 19:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 sp74uJJD_oWK for ; Sun, 15 Nov 2015 19:07:13 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B371B2A74 for ; Sun, 15 Nov 2015 19:07:13 -0800 (PST) Received: by iofh3 with SMTP id h3so147610218iof.3 for ; Sun, 15 Nov 2015 19:07:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=qF2cgOyW3yo1c0hgyA+/jmlHCQjLv4ZfDTGVAkA3RIU=; b=C0rCnbowFziP1rHAt9pHiDree9WUoChlKcO+P76i5VU/KKeY1S7TG1mExUb3tN5/+B 4p771PXozzFQ54mt4Cx2vQC/nIuf9+g7hcUHWCtVpUSiA4483RxOS18p9zceSiWMHfrI G8ol61zKcxSXQ4w028ewFQXoCSHi7jrR/3PNi79ysabO8i/wM9+IcCDsMDUtkMoeL643 n4j+284HtYYUTO8ybwJGbpNM0Q+2TjfcUtuk+99ITvOgb/UI9U2pOpleisf7IflMP8OR WwP/Tcwckt+q6VoZTC7xWPXXYZwL0YVnM2otqyEnvivVvqc+yXuC9KGPcdDsZR6H/Xz+ 46SQ== MIME-Version: 1.0 X-Received: by 10.107.170.213 with SMTP id g82mr29162093ioj.178.1447643232881; Sun, 15 Nov 2015 19:07:12 -0800 (PST) Received: by 10.79.78.145 with HTTP; Sun, 15 Nov 2015 19:07:12 -0800 (PST) Received: by 10.79.78.145 with HTTP; Sun, 15 Nov 2015 19:07:12 -0800 (PST) In-Reply-To: References: Date: Sun, 15 Nov 2015 19:07:12 -0800 Message-ID: From: Rahul Sharma To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=001a114267dea850ad05249fb452 Archived-At: Subject: Re: [apps-discuss] apps-discuss Digest, Vol 94, Issue 12 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 03:07:16 -0000 --001a114267dea850ad05249fb452 Content-Type: text/plain; charset=UTF-8 Cntct me On Nov 16, 2015 1:30 AM, wrote: > Send apps-discuss mailing list submissions to > apps-discuss@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/apps-discuss > or, via email, send a message with subject or body 'help' to > apps-discuss-request@ietf.org > > You can reach the person managing the list at > apps-discuss-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of apps-discuss digest..." > > > Today's Topics: > > 1. Re: [DNSOP] Registry of non-service _prefix names and > draft-crocker-dns-attrleaf-07 (John Levine) > 2. Re: [DNSOP] Registry of non-service _prefix names and > draft-crocker-dns-attrleaf-07 (Dave Crocker) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: 14 Nov 2015 20:28:44 -0000 > From: "John Levine" > To: dnsop@ietf.org > Cc: dcrocker@bbiw.net, apps-discuss@ietf.org > Subject: Re: [apps-discuss] [DNSOP] Registry of non-service _prefix > names and draft-crocker-dns-attrleaf-07 > Message-ID: <20151114202844.9601.qmail@ary.lan> > Content-Type: text/plain; charset=utf-8 > > >Done. > > > >This will be the third or fourth try for the document. Perhaps there is > >now enough community interest to make it happen? > > The more I look at this, the more of a mess I find. It's not like it > would have been all up to you. RFC 6335 came out five years after the > first version of your draft and would have been a fine opportunity to > de-mess. > > Assuming the places in the draft where you refer to the left-most name > you mean the right-most name for what gets registered, it needs to > make clear what names enable what sub-names. > > For example, if a name is _tcp or _udp, all of the names in the RFC > 6335 service name registry are eligible. This includes _soap-beep and > _xmlrpc-beep which are in that registry, and _certificates and _crls > which should be but aren't. But RFC 2782 is pretty casual about what > protocols other than _tcp and _udp correspond to SRV names. IANA has > a protocol registry at > http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml > but a lot of the entries are not obvious candidates for SRV. On the > other hand, RFC 5509 makes _sip a SRV protocol name even though it's > also a service. > > DKIM currently allows _adsp as a subtag, probably not worth making a > registry, since there don't seem to be any other likely DKIM subtags. > Similarly there's _report._dmarc which seems to be a one-off. > > R's, > John > > > > > ------------------------------ > > Message: 2 > Date: Sat, 14 Nov 2015 15:26:04 -0800 > From: Dave Crocker > To: John Levine > Cc: dnsop@ietf.org, dcrocker@bbiw.net, apps-discuss@ietf.org > Subject: Re: [apps-discuss] [DNSOP] Registry of non-service _prefix > names and draft-crocker-dns-attrleaf-07 > Message-ID: <5647C30C.10302@dcrocker.net> > Content-Type: text/plain; charset=utf-8 > > On 11/14/2015 12:28 PM, John Levine wrote: > > RFC 6335 came out five years after the > > first version of your draft and would have been a fine opportunity to > > de-mess. > > Given what it was trying to do, I don't think they could reasonably have > tackled this topic. However I suppose it's nice that they sought to > enfoce a "no underscores" rule for their table, since it facilitates the > re-use of the names under SRV. > > The more serious problem, IMO, is that the SRV spec has such a fuzzy > spec for the alternative names that might be used besides _udp and _tcp. > > I tried to accommodate this actively in the earliest versions of the > draft -- even to the point of having the registry be hierarchical -- but > seem to have fallen back to something as fuzzy as the SRV spec itself. > I finally decided flat organization suffices but didn't care the > requirement for explicit registration forward. Yuck. > > At this point, after looking at the relevant SRV spec text again, I > believe the only respectable solution is to change that part of the SRV > spec and dictate that the service names must be registered in this IANA > table. I do not see a "inherited from the IANA service names table" > model as being viable, since it almost encourages name collisions. > > > > > Assuming the places in the draft where you refer to the left-most name > > you mean the right-most name for what gets registered, it needs to > > make clear what names enable what sub-names. > > oh my. ummm. yes. i only wish i could attribute this to alcohol or > dyslexia. > > > > For example, if a name is _tcp or _udp, all of the names in the RFC > > 6335 service name registry are eligible. This includes _soap-beep and > > _xmlrpc-beep which are in that registry, and _certificates and _crls > > which should be but aren't. But RFC 2782 is pretty casual about what > > protocols other than _tcp and _udp correspond to SRV names. IANA has > > a protocol registry at > > http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml > > but a lot of the entries are not obvious candidates for SRV. On the > > other hand, RFC 5509 makes _sip a SRV protocol name even though it's > > also a service. > > > > DKIM currently allows _adsp as a subtag, probably not worth making a > > registry, since there don't seem to be any other likely DKIM subtags. > > Similarly there's _report._dmarc which seems to be a one-off. > > For got that. Thought it was indepedent. ADSP is now removed from the > draft. > > d/ > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > ------------------------------ > > End of apps-discuss Digest, Vol 94, Issue 12 > ******************************************** > --001a114267dea850ad05249fb452 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Cntct me

On Nov 16, 2015 1:30 AM, <apps-discuss-request@ietf.org> wrote:=
Send apps-discuss m= ailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 apps-d= iscuss@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/m= ailman/listinfo/apps-discuss
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 apps-discuss-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = apps-discuss-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of apps-discuss digest..."


Today's Topics:

=C2=A0 =C2=A01. Re:=C2=A0 [DNSOP] Registry of non-service _prefix names and=
=C2=A0 =C2=A0 =C2=A0 draft-crocker-dns-attrleaf-07 (John Levine)
=C2=A0 =C2=A02. Re:=C2=A0 [DNSOP] Registry of non-service _prefix names and=
=C2=A0 =C2=A0 =C2=A0 draft-crocker-dns-attrleaf-07 (Dave Crocker)


----------------------------------------------------------------------

Message: 1
Date: 14 Nov 2015 20:28:44 -0000
From: "John Levine" <johnl@= taugh.com>
To: dnsop@ietf.org
Cc: dcrocker@bbiw.net, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [DNSOP] Registry of non-service _prefix
=C2=A0 =C2=A0 =C2=A0 =C2=A0 names and draft-crocker-dns-attrleaf-07
Message-ID: <20151114202844.9601.qmail@ary.lan>
Content-Type: text/plain; charset=3Dutf-8

>Done.
>
>This will be the third or fourth try for the document.=C2=A0 Perhaps th= ere is
>now enough community interest to make it happen?

The more I look at this, the more of a mess I find.=C2=A0 It's not like= it
would have been all up to you.=C2=A0 RFC 6335 came out five years after the=
first version of your draft and would have been a fine opportunity to
de-mess.

Assuming the places in the draft where you refer to the left-most name
you mean the right-most name for what gets registered, it needs to
make clear what names enable what sub-names.

For example, if a name is _tcp or _udp, all of the names in the RFC
6335 service name registry are eligible.=C2=A0 This includes _soap-beep and=
_xmlrpc-beep which are in that registry, and _certificates and _crls
which should be but aren't.=C2=A0 But RFC 2782 is pretty casual about w= hat
protocols other than _tcp and _udp correspond to SRV names.=C2=A0 IANA has<= br> a protocol registry at
http://www.iana.org/assignmen= ts/protocol-numbers/protocol-numbers.xhtml
but a lot of the entries are not obvious candidates for SRV.=C2=A0 On the other hand, RFC 5509 makes _sip a SRV protocol name even though it's also a service.

DKIM currently allows _adsp as a subtag, probably not worth making a
registry, since there don't seem to be any other likely DKIM subtags. Similarly there's _report._dmarc which seems to be a one-off.

R's,
John




------------------------------

Message: 2
Date: Sat, 14 Nov 2015 15:26:04 -0800
From: Dave Crocker <dhc@dcrocker.net= >
To: John Levine <johnl@taugh.com&= gt;
Cc: dnsop@ietf.org, dcrocker@bbiw.net, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [DNSOP] Registry of non-service _prefix
=C2=A0 =C2=A0 =C2=A0 =C2=A0 names and draft-crocker-dns-attrleaf-07
Message-ID: <5647C30C.103= 02@dcrocker.net>
Content-Type: text/plain; charset=3Dutf-8

On 11/14/2015 12:28 PM, John Levine wrote:
> RFC 6335 came out five years after the
> first version of your draft and would have been a fine opportunity to<= br> > de-mess.

Given what it was trying to do, I don't think they could reasonably hav= e
tackled this topic.=C2=A0 However I suppose it's nice that they sought = to
enfoce a "no underscores" rule for their table, since it facilita= tes the
re-use of the names under SRV.

The more serious problem, IMO, is that the SRV spec has such a fuzzy
spec for the alternative names that might be used besides _udp and _tcp.
I tried to accommodate this actively in the earliest versions of the
draft -- even to the point of having the registry be hierarchical -- but seem to have fallen back to something as fuzzy as the SRV spec itself.
I finally decided flat organization suffices but didn't care the
requirement for explicit registration forward. Yuck.

At this point, after looking at the relevant SRV spec text again, I
believe the only respectable solution is to change that part of the SRV
spec and dictate that the service names must be registered in this IANA
table.=C2=A0 I do not see a "inherited from the IANA service names tab= le"
model as being viable, since it almost encourages name collisions.



> Assuming the places in the draft where you refer to the left-most name=
> you mean the right-most name for what gets registered, it needs to
> make clear what names enable what sub-names.

oh my.=C2=A0 ummm.=C2=A0 yes.=C2=A0 i only wish i could attribute this to a= lcohol or
dyslexia.


> For example, if a name is _tcp or _udp, all of the names in the RFC > 6335 service name registry are eligible.=C2=A0 This includes _soap-bee= p and
> _xmlrpc-beep which are in that registry, and _certificates and _crls > which should be but aren't.=C2=A0 But RFC 2782 is pretty casual ab= out what
> protocols other than _tcp and _udp correspond to SRV names.=C2=A0 IANA= has
> a protocol registry at
> http://www.iana.org/assi= gnments/protocol-numbers/protocol-numbers.xhtml
> but a lot of the entries are not obvious candidates for SRV.=C2=A0 On = the
> other hand, RFC 5509 makes _sip a SRV protocol name even though it'= ;s
> also a service.
>
> DKIM currently allows _adsp as a subtag, probably not worth making a > registry, since there don't seem to be any other likely DKIM subta= gs.
> Similarly there's _report._dmarc which seems to be a one-off.

For got that.=C2=A0 Thought it was indepedent. ADSP is now removed from the=
draft.

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net



------------------------------

Subject: Digest Footer

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


------------------------------

End of apps-discuss Digest, Vol 94, Issue 12
********************************************
--001a114267dea850ad05249fb452-- From nobody Mon Nov 16 13:31:29 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF931B31D7; Mon, 16 Nov 2015 13:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, 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 EkPPo-B6TUt4; Mon, 16 Nov 2015 13:31:25 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 DA1F61B31AB; Mon, 16 Nov 2015 13:31:24 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id CDCEC7D7907E9; Mon, 16 Nov 2015 21:31:17 +0000 (GMT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id tAGLVISN021894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2015 21:31:21 GMT Received: from [135.185.238.169] (shoonya.ih.lucent.com [135.185.238.169]) by umail.lucent.com (8.13.8/TPES) with ESMTP id tAGLVIgj003389; Mon, 16 Nov 2015 15:31:18 -0600 (CST) To: draft-ietf-straw-b2bua-dtls-srtp.all@tools.ietf.org From: "Vijay K. Gurbani" Message-ID: <564A4B26.4020108@bell-labs.com> Date: Mon, 16 Nov 2015 15:31:18 -0600 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: iesg@ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-straw-b2bua-dtls-srtp-08.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, 16 Nov 2015 21:31:27 -0000 I have been selected as the Applications Area Directorate early reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-straw-b2bua-dtls-srtp-08.txt Title: DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) Reviewer: Vijay K. Gurbani Review Date: 2015-11-16 IETF Last Call Date: 2015-11-17 IESG Telechat Date: 2015-12-03 Summary: This draft has minor issues, and is ready for publication as a Proposed Standard once these issues are resolved. I will also (strongly) suggest that the editors go over the draft for grammatical touches to eliminate the sort of issues present in the Nits section. This will make the draft more readable and provide it the gravity it needs for a standards track document. Major: 0 Minor: 3 Nits: Many Minor: - S3.1.1, second to last paragraph (beginning with "[RFC4474] provides ... the signature."): Isn't this only true if the originating UAC used rfc4474 and inserted the appropriate headers. Or is the assumption that rfc4474 is always used, and therefore, a media relay B2BUA must be careful and not modify the fingerprints? - S3.1.2, first paragraph: "The identity integrity protection procedures described in Security Considerations section..." Described in the Security Consideration section of which document? The document under review or some other one (rfc7092)? - S3.1.2.2: I am not sure what your takeaway is at the end of this section. You seem to be making the case that a B2BUA cannot modify the RTP headers and RTCP packets. But then you go on and say that this can be mitigated by using different keys, and that with "such an approach" (aside: define "such an approach"), the B2BUA is not aware of the keys used to decrypt the media payload. Well, the B2BUA is never aware of such keys, since they are negotiated end-to-end (over the B2BUA), so I am at a loss to see what is the point of this section. Nits: - Abstract: s/media plane, rather than/media plane rather than - Abstract: s/This document describes the behavior such B2BUAs can adhere to/This document describes the behaviour of such B2BUAs/ - S1.1: s/The fingerprint, identifies/The fingerprint identifies - S3.1.2: s/There are two types of media-aware relay/There are two types of media-aware relays/ - S3.1.2.1: (For readability) s/This kind of media aware relay/A RTP/RTCP aware media relay/ - S4: s/B2BUA replaces the Bob's/B2BUA replaces Bob's/ (If you want to retain "the", perhaps you may consider renaming Bob to Donald! Sorry, bad joke, I know.) Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Tue Nov 17 20:31:38 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653631B2D4E; Tue, 17 Nov 2015 01:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.086 X-Spam-Level: X-Spam-Status: No, score=-15.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZ-p3KfLcQle; Tue, 17 Nov 2015 01:17:21 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A89F1B2D48; Tue, 17 Nov 2015 01:17:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4810; q=dns/txt; s=iport; t=1447751841; x=1448961441; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=c3X/EepysXxwVTkAGoeU2qOEaj1qtjIGxeDO2cSIIGA=; b=fSzD/nOltjD9cAB0mZMkPnIm5LHVItkSyZvBWNkHXJzxUq5DpUHqybMU BRYFIk6vvckc65MWt2hEqT4MmggJKp3j2Aztoi/bFeTr38fgPLpZMzPuA O5ZLeqgMP0Hehk/WEPuocx4oXgqwCt3fYggHO1W0S8GVa/RASM5p+cbhe Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAgCs70pW/5BdJa1UCYM7U2kGBrw9g?= =?us-ascii?q?hoBDYFlI4VtAoFKOBQBAQEBAQEBgQqENAEBAQQ6PwwEAgEIEQMBAh8QMh0IAgQ?= =?us-ascii?q?BDQWILggFA7s+AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZVhH2EKgcKAYR9BZZJA?= =?us-ascii?q?YUfiAqBW0mDd45kAoNSg3EBHwEBQoQEcgELAQGDOzoBgQYBAQE?= X-IronPort-AV: E=Sophos;i="5.20,307,1444694400"; d="scan'208";a="47447057" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Nov 2015 09:17:20 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tAH9HKEM016738 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Nov 2015 09:17:20 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 Nov 2015 04:17:19 -0500 Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1104.000; Tue, 17 Nov 2015 04:17:19 -0500 From: "Ram Mohan R (rmohanr)" To: "Vijay K. Gurbani" , "draft-ietf-straw-b2bua-dtls-srtp.all@tools.ietf.org" , "straw@ietf.org" Thread-Topic: APPSDIR review of draft-ietf-straw-b2bua-dtls-srtp-08.txt Thread-Index: AQHRILYtRnP8BsSoEEqoxVoa7OqN7J6goUUA Date: Tue, 17 Nov 2015 09:17:19 +0000 Message-ID: References: <564A4B26.4020108@bell-labs.com> In-Reply-To: <564A4B26.4020108@bell-labs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [173.39.64.87] Content-Type: text/plain; charset="us-ascii" Content-ID: <5733618F4FCF5548AED7FB15B723950A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 17 Nov 2015 20:31:36 -0800 Cc: "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-straw-b2bua-dtls-srtp-08.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, 17 Nov 2015 09:17:23 -0000 Hi Vijay, Thanks for your review and feedback. Please see inline -----Original Message----- From: "Vijay K. Gurbani" Date: Tuesday, 17 November 2015 at 3:01 AM To: "draft-ietf-straw-b2bua-dtls-srtp.all@tools.ietf.org" Cc: "apps-discuss@ietf.org" , "iesg@ietf.org" Subject: APPSDIR review of draft-ietf-straw-b2bua-dtls-srtp-08.txt Resent-From: Resent-To: Resent-Date: Tuesday, 17 November 2015 at 3:01 AM >I have been selected as the Applications Area Directorate early >reviewer for this draft (for background on appsdir, please see >http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate) >. > >Please resolve these comments along with any other Last Call comments >you may receive. Please wait for direction from your document shepherd >or AD before posting a new version of the draft. > >Document: draft-ietf-straw-b2bua-dtls-srtp-08.txt >Title: DTLS-SRTP Handling in Session Initiation Protocol (SIP) > Back-to-Back User Agents (B2BUAs) >Reviewer: Vijay K. Gurbani >Review Date: 2015-11-16 >IETF Last Call Date: 2015-11-17 >IESG Telechat Date: 2015-12-03 > >Summary: This draft has minor issues, and is ready for publication as >a Proposed Standard once these issues are resolved. > >I will also (strongly) suggest that the editors go over the draft for >grammatical touches to eliminate the sort of issues present in the Nits >section. This will make the draft more readable and provide it the >gravity it needs for a standards track document. > >Major: 0 >Minor: 3 >Nits: Many > >Minor: > >- S3.1.1, second to last paragraph (beginning with "[RFC4474] provides > ... the signature."): Isn't this only true if the originating UAC > used rfc4474 and inserted the appropriate headers. Or is the > assumption that rfc4474 is always used, and therefore, a media relay > B2BUA must be careful and not modify the fingerprints? Right. This is true only when RFC4474 is used. We have re-worded the text to say the same. Here is the proposed new text: NEW: "When is used forDTLS-SRTP sessions, the fingerprint attributes are integrity protected. Thus, under circumstances when is used, B2BUAs cannot terminate the DTLS-SRTP session without invalidating the signature and causing the session to fail. > >- S3.1.2, first paragraph: "The identity integrity protection > procedures described in Security Considerations section..." > > Described in the Security Consideration section of which document? > The document under review or some other one (rfc7092)? Described in section 5 (Security Consideration) of this document. I will re-word to say the same. > >- S3.1.2.2: I am not sure what your takeaway is at the end of this > section. You seem to be making the case that a B2BUA cannot > modify the RTP headers and RTCP packets. But then you go on and > say that this can be mitigated by using different keys, and that > with "such an approach" (aside: define "such an approach"), the > B2BUA is not aware of the keys used to decrypt the media payload. > Well, the B2BUA is never aware of such keys, since they are > negotiated end-to-end (over the B2BUA), so I am at a loss to see > what is the point of this section. The idea of the section is to highlight that with current mechanisms it is not possible for B2BUA modify headers with out being a DTLS endpoint. In future (with PERC) it is possible that a B2BUA can modify the headers/RTCP packets but still have no access to the RTP payload. > >Nits: > >- Abstract: s/media plane, rather than/media plane rather than > >- Abstract: s/This document describes the behavior such B2BUAs can > adhere to/This document describes the behaviour of such B2BUAs/ > >- S1.1: s/The fingerprint, identifies/The fingerprint identifies > >- S3.1.2: > s/There are two types of media-aware relay/There are two types of > media-aware relays/ > >- S3.1.2.1: (For readability) > s/This kind of media aware relay/A RTP/RTCP aware media relay/ > >- S4: s/B2BUA replaces the Bob's/B2BUA replaces Bob's/ Thanks. Will fix all the above Nits Regards, Ram > > (If you want to retain "the", perhaps you may consider renaming > Bob to Donald! Sorry, bad joke, I know.) > >Thanks, > >- vijay >--=20 >Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) >Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com >Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Fri Nov 20 12:56:57 2015 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0390F1B3DB2; Fri, 20 Nov 2015 12:56:56 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.10.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20151120205655.17511.99851.idtracker@ietfa.amsl.com> Date: Fri, 20 Nov 2015 12:56:55 -0800 Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-http-problem@ietf.org, barryleiba@gmail.com, apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (Problem Details for HTTP APIs) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 20:56:56 -0000 The IESG has received a request from the ART Area General Applications Working Group WG (appsawg) to consider the following document: - 'Problem Details for HTTP APIs' as Proposed Standard 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 2015-12-04. 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 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. Note to Readers This draft should be discussed on the apps-discuss mailing list [1]. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-problem/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-problem/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sun Nov 22 09:07:52 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236F01ACD08 for ; Sun, 22 Nov 2015 09:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.184 X-Spam-Level: X-Spam-Status: No, score=-1.184 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.585, 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 37sYWC0A1Ssq for ; Sun, 22 Nov 2015 09:07:49 -0800 (PST) Received: from statler.isode.com (statler.isode.com [217.34.220.151]) by ietfa.amsl.com (Postfix) with ESMTP id 88A041ACD05 for ; Sun, 22 Nov 2015 09:07:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1448212068; d=isode.com; s=selector; i=@isode.com; bh=tMUqlduqpaQ2hUFUBQvHVc5YerKxoIriiTEKVh9Bn50=; 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=AB8FQaiOfStORTzt0yR3kH4mpKBH4Yl1mRgDQZoU/yZWXkdurBx8ovTrBEQ2cOONQdW5lb 2cV1ajN9o3/ltmND59rxG0ZdOuWhJbarsWlJsUodQWDqQkFL8gqh0LLaxJGmaGXDK5G2+Z q9Srm86NygrCHagUaqH/rJtwwH5yR88=; Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 22 Nov 2015 17:07:47 +0000 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (13B143) In-Reply-To: Date: Sun, 22 Nov 2015 17:09:16 +0000 Message-Id: <9A50BBF2-E3F8-4C32-A3AE-674063C78A7A@isode.com> References: To: IETF Apps Discuss MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-3F52FF1F-5473-47E8-8504-D04CE9106E19 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2015 17:07:51 -0000 --Apple-Mail-3F52FF1F-5473-47E8-8504-D04CE9106E19 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Hi, Sorry for the late review. > On 2 Nov 2015, at 03:50, Murray S. Kucherawy wrote: >=20 > Colleagues, >=20 > This note starts a Working Group Last Call for draft-ietf-appsawg-file-sch= eme. This document has been with us for a while and feedback has fallen to a= trickle. We've gotten all the feedback from W3C that we expect, so we'd li= ke to move it toward publication. >=20 > Please provide review comments or expressions of support for the current v= ersion either on this list or privately to draft-ietf-appsawg-file-scheme.al= l@tools.ietf.org on or before November 20, 2015. Be as detailed as possible= . The co-chairs need to determine if the document has working group consens= us, which means we need to know people have read the latest version and agre= e with its content and with the idea that it is ready to proceed. A simple =93= +1=94 doesn=92t tell us anything. I read and reviewed the document and I am pleased with its quality. I haven'= t tested various statements about what different implementations do. I suppo= rt the document being published. Alexey, as an APPSAWG participant. >=20 > Also, if any participant has knowledge of IPR that needs to be declared on= this work, please do so, as required by BCPs 78 and 79. >=20 > Dave Crocker is fulfilling the duties of document shepherd. --Apple-Mail-3F52FF1F-5473-47E8-8504-D04CE9106E19 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,
Sorry for the late review.

<= div>On 2 Nov 2015, at 03:50, Murray S. Kucherawy <superuser@gmail.com> wrote:

Colleagues,

This note starts a Wor= king Group Last Call for draft-ietf-appsawg-file-scheme.  This document= has been with us for a while and feedback has fallen to a trickle.  We= 've gotten all the feedback from W3C that we expect, so we'd like to move it= toward publication.

Please provide review comments or expressions of= support for the current version either on this list or privately to draft-ietf-app= sawg-file-scheme.all@tools.ietf.org on or before November 20, 2015. = ; Be as detailed as possible.  The co-chairs need to determine if the d= ocument has working group consensus, which means we need to know people have= read the latest version and agree with its content and with the idea that i= t is ready to proceed.  A simple =E2=80=9C+1=E2=80=9D doesn=E2=80=99t t= ell us anything.

I read and revie= wed the document and I am pleased with its quality. I haven't tested various= statements about what different implementations do. I support the document b= eing published.

Alexey,
as an APPSAWG participa= nt.

Also, if any part= icipant has knowledge of IPR that needs to be declared on this work, please d= o so, as required by BCPs 78 and 79.

Dave Crocker is fulfilling the d= uties of document shepherd.
= --Apple-Mail-3F52FF1F-5473-47E8-8504-D04CE9106E19-- From nobody Mon Nov 23 12:24:59 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EB21B33CA; Mon, 23 Nov 2015 12:24:55 -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 XU9HygLDkWcu; Mon, 23 Nov 2015 12:24:52 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7138E1B33C9; Mon, 23 Nov 2015 12:24:49 -0800 (PST) Received: by qgeb1 with SMTP id b1so122620840qge.1; Mon, 23 Nov 2015 12:24:48 -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=v6uVmXFattIfDXp8lXYJx/8ypdnXupSx12I+2OXyq8E=; b=vo+tVj450G8R3ryOP3n4DOB1UZLlfClXoffOdAI8fj9gJFMUX0YijvA+G5jPXFxbX9 TdtC55DwJ+1CUU34gOP2MHT/Mg7F0w/UmIBL5z45t+D0MJ0UUJsC2Wbcw+9GA/oCokym f6kADr3Na2Fwu9VQHnUsopzpLRTqdg4Y9aH979XkM0eVoLB+ZXOTDnFj3uPpzeeRwcCB E3J3DH4ChYEcI3KRfmmraM5Tf6/jJ56yrWitDu+ax6fBJsk5U8SYF0pVJ5+G9uUB7AjH pNFOC8F9+0N2wOoP1oU1sPf4ZhDxSp2u/gXhfN3lRierAvUGWyoxYql9C27XZ/g/mwuG gcQw== MIME-Version: 1.0 X-Received: by 10.140.250.70 with SMTP id v67mr31584312qhc.43.1448310288429; Mon, 23 Nov 2015 12:24:48 -0800 (PST) Received: by 10.55.115.132 with HTTP; Mon, 23 Nov 2015 12:24:48 -0800 (PST) Date: Mon, 23 Nov 2015 12:24:48 -0800 Message-ID: From: Ted Hardie To: apps-discuss@ietf.org, draft-ietf-dnsop-edns-chain-query.all@ietf.org Content-Type: multipart/alternative; boundary=001a113a97e2443ccb05253b0457 Archived-At: Cc: IESG Subject: [apps-discuss] APPS-Dir review of draft-ietf-dnsop-edns-chain-query-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 20:24:55 -0000 --001a113a97e2443ccb05253b0457 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see =E2=80=8B http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-dnsop-edns-chain-query-05 Title: Chain Query requests in DNS Reviewer: Ted Hardie Review Date: November 23, 2015 Summary: This is generally suitable as the basis of an experiment, but the document could describe some of the trade-offs more clearly. Comments: Major Issues: The effort to avoid amplification attacks is appropriate, but justification of the UDP option, even with the EDNS option for a DNS cookie, is not well supported in the draft. One major driver for the work is that the total response size needed for validation may be large. Using DNS cookies will add between 15 and 40 bytes (presuming both client and server cookies are used), thus further swelling the response. Some description of when the requester/responder's UDP payload size is likely to be sufficient here would be a valuable addition. If the data is not available now, perhaps it could be gathered during the course of experimentation? If that data shows the intersection of "fits within UDP" and "answers at least a partial chain" is small, then reverting this to TCP-only looks sensible. Minor Issues: In 5.4, the document currently describes the process of returning a partial chain: If a CHAIN answer would be bigger than the Recursive Resolver is willing to serve, it SHOULD send a partial chain starting with the data closest to the top of the chain. The client MAY re-send the query with an updated Closest Trust Point until it has received the full chain. The CHAIN response will contain the lowest Closest Trust Point that was included in the CHAIN answer. This describes the intersection of one particular resource constraint and the operation of this option. It seems possible, however that a resolver might see other resource constraints which might allow it to answer a partial chain from something other than the data closest to the top of the chain. Imagine, for example, that it has cached data for some parts of the chain but needs to refresh the cache on some other part. If the cache fill operation is taking significant time, it might prefer to send what data it has, and fill the cache in anticipation of the follow-up query. Is there a reason for limiting partial answers to the top-most hierarchical responses? If so, could the document include it? In section 6.5, the document says: Many paths between DNS clients and Recursive Resolvers suffer from poor hygiene, limiting the free flow of DNS messages that include particular EDNS0 options, or messages that exceed a particular size. A fallback strategy similar to that described in [RFC6891 ] section 6.2.2 SHOULD be employed to avoid persistent interference due to non- clean paths. This seems to conflict with the advice in 5.3: However, it is RECOMMENDED that Forwarders remember which upstream Recursive Resolvers did not return the option (and additional data) with their response. The Forwarder SHOULD fallback to regular DNS for subsequent queries to those Recursive Resolvers. It MAY switch to another Recursive Resolver that does support the CHAIN option or try again later to see if the server has become less loaded and is now willing to answer with Query Chains. To resolve this, the client would have to be able to detect when the ENDS0 option is suppressed by the path, versus not offered by a Recursive Resolver. Some further text on how this is discerned would be useful; absent a method, I believe the text in 5.3 is sufficient and 6.5 not useful beyond the points made in RFC 6891. Nits: The abstract uses the term "security aware validating Resolver". This use of "security aware" appears to be the term of art used in RFC 4033, but that may not be obvious; perhaps "DNSSEC validating resolver" would be more clear for an abstract? In section 6.3, the document says: In the event that there is greater demand for Chain Queries than can be accommodated, DNS servers may stop advertising the CHAIN option in successive DNS messages. This allows, for example, clients with other candidate servers to query to establish new sessions with different servers in expectation that those servers might still allow Chain Queries. Given that this would also apply to UDP CHAIN queries, it is not clear why this is in the TCP Session Management section. In section 6.4, the document says "partian CHAIN up" where it should say "partial CHAIN up". In section 6.6, this text was quite hard to parse: Changes in network topology between clients and anycast servers may cause disruption to TCP sessions making use of CHAIN more often than with TCP sessions that omit it, since the TCP sessions are expected to be longer-lived. Perhaps: Since DNS queries using CHAIN may result in longer TCP sessions, network topology changes may disrupt them more frequently. --001a113a97e2443ccb05253b0457 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I have been selected as the Applications Area Directorate reviewer for this= draft (for background on appsdir, please see =E2=80=8Bhttp://trac.tools.ietf.org/area/app/trac/wiki/App= licationsAreaDirectorate ).

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

Document: draft-ietf-dnsop-edns-chain-query-05
Title: Chain Query requests in DNS

Reviewer: = Ted Hardie
Review Date: November 23, 2015

Summary:

This is generally suitable as the ba= sis of an experiment, but the document could describe some of the trade-off= s more clearly.

Comments:

Major Issues:=C2=A0

The effort to avoid ampli= fication attacks is appropriate, but justification of the UDP option, even = with the EDNS option for a DNS cookie, is not well supported in the draft.= =C2=A0 One major driver for the work is that the total response size needed= for validation may be large.=C2=A0 Using DNS cookies will add between 15 a= nd 40 bytes (presuming both client and server cookies are used), thus furth= er swelling the response.=C2=A0 Some description of when the requester/resp= onder's UDP payload size is likely to be sufficient here would be a val= uable addition.=C2=A0 If the data is not available now, perhaps it could be= gathered during the course of experimentation? If that data shows the inte= rsection of "fits within UDP" and "answers at least a partia= l chain" is small, then reverting this to TCP-only looks sensible.
=

Minor Issues:

In 5.4, the document currently describes the process of= returning a partial chain:

   I=
f a CHAIN answer would be bigger than the Recursive Resolver is
   willing to serve, it SHOULD send a partial chain starting with the
   data closest to the top of the chain.  The client MAY re-send the
   query with an updated Closest Trust Point until it has received the
   full chain.  The CHAIN response will contain the lowest Closest Trust
   Point that was included in the CHAIN answer.

This describes the intersection of one particular r= esource constraint and the operation of this option.=C2=A0 It seems possibl= e, however that a resolver might see other resource constraints which might= allow it to answer a partial chain from something other than the data clos= est to the top of the chain.=C2=A0 Imagine, for example, that it has cached= data for some parts of the chain but needs to refresh the cache on some ot= her part.=C2=A0 If the cache fill operation is taking significant time, it = might prefer to send what data it has, and fill the cache in anticipation o= f the follow-up query.=C2=A0 Is there a reason for limiting partial answers= to the top-most hierarchical responses?=C2=A0 If so, could the document in= clude it?

In section 6.5, the document says: = 

   Many paths between DNS c=
lients and Recursive Resolvers suffer from
   poor hygiene, limiting the free flow of DNS messages that include
   particular EDNS0 options, or messages that exceed a particular size.
   A fallback strategy similar to that described in [RFC6891] section
   6.2.2 SHOULD be employed to avoid persistent interfe=
rence due to non-
   clean paths.

This seems to conflict with= the advice in 5.3:

   However, =
it is RECOMMENDED that Forwarders remember which
   upstream Recursive Resolvers did not return the option (and
   additional data) with their response.  The Forwarder SHOULD fallback
   to regular DNS for subsequent queries to those Recursive Resolvers.
   It MAY switch to another Recursive Resolver that does support the
   CHAIN option or try again later to see if the server has become less
   loaded and is now willing to answer with Query Chains.

To resolve this, the client would have to be able to detect = when the ENDS0 option is suppressed by the path, versus not offered by a Re= cursive Resolver. =C2=A0 Some further text on how this is discerned would b= e useful; absent a method, I believe the text in 5.3 is sufficient and 6.5 = not useful beyond the points made in RFC 6891.

Nits:

The abstract uses the term = "security aware validating Resolver".=C2=A0 This=20 use of "security aware" appears to be the term of art used in RFC= 4033,=20 but that may not be obvious; perhaps "DNSSEC validating resolver"= would=20 be more clear for an abstract?

In section 6.3, t= he document says:
   In the event th=
at there is greater demand for Chain Queries than can
   be accommodated, DNS servers may stop advertising the CHAIN option in
   successive DNS messages.  This allows, for example, clients with
   other candidate servers to query to establish new sessions with
   different servers in expectation that those servers might still allow
   Chain Queries.
Given that this would also a= pply to UDP CHAIN queries, it is not clear why this is in the TCP Session M= anagement section.

In section 6.4, the document s= ays "partian CHAIN up" where it should say "partial CHAIN up= ".

In section 6.6, this text was quite hard to parse:= 


    Changes in network topology between clients and anycast=
 servers may
   cause disruption to TCP sessions making use of CHAIN more often than
   with TCP sessions that omit it, since the TCP sessions are expected
   to be longer-lived.

Perhaps:
Since DNS queries using CHAIN may result in longer TC=
P sessions,  
network topology changes may disrupt them more freq=
uently.
--001a113a97e2443ccb05253b0457-- From nobody Tue Nov 24 02:27:27 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1E91B2F3F for ; Tue, 24 Nov 2015 02:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, 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 h6EOtY4vc751 for ; Tue, 24 Nov 2015 02:27:19 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0739.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::739]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C8C91B2F33 for ; Tue, 24 Nov 2015 02:27:18 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 24 Nov 2015 10:26:59 +0000 Message-ID: <01e701d126a2$726600e0$4001a8c0@gateway.2wire.net> From: t.petch To: "Murray S. Kucherawy" , IETF Apps Discuss References: Date: Tue, 24 Nov 2015 10:24:04 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: AM3PR02CA0046.eurprd02.prod.outlook.com (10.242.240.46) To DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB064; 2:/zTSFahVrWWhSq8nkrwagCbYq9ohLC+BZvJeMKtNaEZSSiw42bufYuM/ct8qYK7c7c175glk/OdZncUID5g8CoLKTw729mng6gSv3wTb1maASYjHzgO6T9CgUWGvjfi7Im52hO6yA2hA0OIq6/8D1A==; 3:A0dWAJ6J28xbECQctbETu6o9WaP7mukQlYyMY+C217/wDMU5VfuCW2/pkJF6PO+FfiIlZmF01plrT0B9b+nd1iQQceb3XAnQwggqZQ88jpEogCKpFW+kSvQkbQ3c78fe; 25:yuNKTacb2N7HyYzflzEPJjt4oYs58/ru/XnBLMTH/zJuf7XlONVDBcTbJDbNoUPn3AITu5jV9FtfnlCnz1lDhYfB7n3hGexam/Fqices46cBKVNCsib9qpKY/p3Rs5ncWrS+6Z/0TLZWoambNwt6G1wCZDeCmw2Dt64OZ1BlcmAOFQ6K9P0XWSNK/h3XyijCDbK1Lmug9CPPz1wL21m3FWGqbdiyXa6HbfUPP67yfe5zZJCLK5EYvpELvNBvl4SL7QuCctXhmCxl6Ex9XnyP6Q==; 4:aQ/g/PRJ/jIEMAvUfCsWHMrYvy8KHoU7ztYDL0WaO+sFQSOz2xSxUN2PLozFZbshdhyt+E3JG9d4vc2O8h2B9cqhYyd+ePsrvoYsLo+Rh5gZ1+/M5ekS2ffSub1pOJS5epCR9aHX+bnYrCXEGl1VYEj3WxXpCRdNbUfa0cF6h6+92WPuQZpvSjUpc+eWrQFdvuG0PhrRq+C2WtkCbqF3gt66Ab+42Yiy4LgwT2yGaAVCMcKxHzf7KqJd6QIEtr8fXgqkpJyPpAwPywhpO26xiXfK97/Yw7X9frR8I4OS51XSCQGYm9PuCxHkUQEAJqvUrVsnm8qGExaxn2daD2gckZylkorv/PGVvLK1tP/tF8gSmdjoPFBVx+lZ/dRWVJ+a X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB064; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:DBXPR07MB064; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB064; X-Forefront-PRVS: 0770F75EA9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(13464003)(199003)(51444003)(87976001)(230783001)(47776003)(92566002)(84392001)(62236002)(44736004)(40100003)(1556002)(1456003)(61296003)(6116002)(106356001)(66066001)(86362001)(5008740100001)(15975445007)(5004730100002)(14496001)(23676002)(77096005)(116806002)(44716002)(42186005)(3846002)(586003)(33646002)(97736004)(81686999)(50226001)(101416001)(76176999)(189998001)(81156007)(5001770100001)(105586002)(5001960100002)(19580395003)(19580405001)(122386002)(5001920100001)(50986999)(107886002)(50466002)(81816999)(5007970100001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB064; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQlhQUjA3TUIwNjQ7MjM6T0lNU21EZU1FS3NhQ0g4L1l2Q0g1N2lDcHFn?= =?utf-8?B?MDRvc0xKTHBnQ1ZtcjdsNnlUTk1PRjQ4eGVXUU95NkxQeTBMS2dMTHdoN2hT?= =?utf-8?B?b3dZVGRUcW1FMkJmaXU5d3lPc2g1QmdxNklrUEpGMWlOek5CWW5UUkROekVR?= =?utf-8?B?Ylk3Z24yS011Q0t6UURIRnc3WWlMU2RZdkJ5NDJWeS8vRGF3ejFGbDNjd0NL?= =?utf-8?B?Z2NoSEhXVWwwbzB0cU4xYUoyUE1YT3lDSldMQnRlM04wYjVDbkdZbDBvNk84?= =?utf-8?B?cVp5MkluK09zVUZ4eFhkeGYwZGdkQnZJY0FtU205M0xMeCtGVXNIaDhQZk4x?= =?utf-8?B?cTc0cThTV2tnbFl1c3lCNG5WY3BidlFQVC91eGdUeTBIK2lRdWt4S3JDMHI5?= =?utf-8?B?SlFWSDFnSkdHZ0JxeHZKbzlUVVYvNlNId2VSNkZ2elZha3FwUUtJQWR3WkNu?= =?utf-8?B?SE9GRDM4bElxK3ZncW4xZ08zN0M3dUhBZlVkVmV3bzA4N3RjdmZwN0Z1U1Fq?= =?utf-8?B?QTBoNGhPV0VDclJJZWZXcEpMRWMvR3hWZzFZQlo0TjRNa0lLUkVkTTVkUVdO?= =?utf-8?B?eHBSeDhJV1h6VVFaakZhMnpJQmorcnlTN2xVOEdxcHVjNEUyQUJBckJuTXZS?= =?utf-8?B?VGNsbDkyMVZQVENoM041QUc1eEVjTDMyaCtyVlcvRG5ST0xkOVYzVHRQTUN4?= =?utf-8?B?RFlBRzY4aE16aTYybTlTZTdVYXBxaVdzVU1JVFM5OTI4Q09HYndtZ3BoVS9j?= =?utf-8?B?V1YvTFZaNlkxMlhVMndJMjdkT0F4TmZ3eVN2bUZxZ0VUbFBEcVhnc0h6cHFY?= =?utf-8?B?ZmVZemsyTldSM1FJRFRUbUNKQ3ZOak5OWmNKeFRwUTFuRTB0ZTFpdC9JUWhv?= =?utf-8?B?Q3Q2TU1jbktKamlZVXBHZit4eElHUTl6OXBNaHlML0VyS3NNMDRhbjFyemg3?= =?utf-8?B?K1Z4bWhTaFRHQWMwejBjdjJZcGhvT2dpMGY5eXBKNFhNSFFqRWJpSUxNbC83?= =?utf-8?B?ejN5bGZQVXU0OGoxN1dTRTlRRVFyMmxrRGpGYTdVcElBbFBxSkErdDNjQWlk?= =?utf-8?B?QzcvemE2bjcvN1JGZjQydzlOOWNBYnlkVWdLVXY2OWFtd2owQjZRU1R1MmZG?= =?utf-8?B?Q2I1TXZhNXRiak92Rmt0Uk5yeUJsQjYwM3VqYVBPVWpuR2M1UUxQZ1ZROGZR?= =?utf-8?B?SUtjajR4NGZKU3hJRHJQNkhxN0gvQ25VWkgrSk5PWUtidnhZcndTbzBpNUhW?= =?utf-8?B?eVBjQndTcGUxRHhQSzFUTlZpcWlYNS9WUnRPcFJySEhGcGRPQ3NGd2t6dEFn?= =?utf-8?B?azZrZnErclN5eXNHeXorQkhSa240Qk9TTmM3MlRWRXV6VSt1cmd4Y3JCZ0hs?= =?utf-8?B?RENHWmxYc2JqSCs2OHdYR3g3UHMzMThmYldMYmJ1ZFpLaVkrdjhadkQ3MUhR?= =?utf-8?B?QWlxbzFrQkxYUExiN09ibm9oWFM5amNyakx6bm1RZnNxajhIL1NsZFUzN1JT?= =?utf-8?B?d3Z6YWVTSzRBR0ZvdlJPWHBxZXMvRFlCZyt3VCswL2tvV0ljZDdIVm5WaVd1?= =?utf-8?B?QUNrbXBXc204V3FPUXFDeThqak5aVGxtVkhPSWIybzUyR1J5eUhuOC9UZVlW?= =?utf-8?B?Q09TbWJRcWZoRWhuYlNBa1JSNEwzU2dUajU2VWQ5VitYUlRUZ2plbHhDRXRi?= =?utf-8?B?cytwS1JQTlhzeVJKeEFnZ09HWG1IYmJXQWQyVUxuNk1OMnFqWXJDS2ptbXZu?= =?utf-8?B?UHdpYVBwVC9IaWViclJOV2wveFZscEJTazZieXpKay9zSjlBU2s4cWtPWVhp?= =?utf-8?B?ZG9Qb3FKUmx4V2s2MkIrQXVpVE1BVlZjSmJNN1duUk0yeE50V3BOMTNucitD?= =?utf-8?Q?jYkmSEcxss=3D?= X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB064; 5:oHV5YaQUVFy5tUEtqPcbuGLVgdS7KhJeQFpzrIdG++7EWpwXi29pWZ0QdilZvt25G0Lq3xKyAh1c2DqAX7tBh+JWNLbD2IdpWqts/MWtlGw+NsHIVFBHf+QI0A7G/AHqllTuhzFH185TaRAr5cMrDg==; 24:AVzYzxMAIQ4TJblXHMIRYBOUFdFDmiVb3TFqW++5kggwfyOv0UIrIg70n3PwpBkiFVpscIpTidN4auexzIjTAbHid1a321RDfWPM5JzpEig= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2015 10:26:59.8015 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB064 Archived-At: Subject: Re: [apps-discuss] Working Group Last Call fordraft-ietf-appsawg-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, 24 Nov 2015 10:27:26 -0000 ---- Original Message ----- From: "Murray S. Kucherawy" To: "IETF Apps Discuss" Sent: Monday, November 02, 2015 3:50 AM Colleagues, This note starts a Working Group Last Call for draft-ietf-appsawg-file-scheme. This document has been with us for a while and feedback has fallen to a trickle. We've gotten all the feedback from W3C that we expect, so we'd like to move it toward publication. Please provide review comments or expressions of support for the current version either on this list or privately to draft-ietf-appsawg-file-scheme.all@tools.ietf.org on or before November 20, 2015. Be as detailed as possible. The co-chairs need to determine if the document has working group consensus, which means we need to know people have read the latest version and agree with its content and with the idea that it is ready to proceed. A simple “+1” doesn’t tell us anything. Ah well, in that case I shall have to make some editorial suggestions:-) s1.1 **/former/the former/ References [Win32-Namespaces] lacks a URL Appendix C The phrase which starts " Regular DOS or Windows file URIs, ..." threw me at first, until I realised that it was an 'i.e.' for the three lines above. There was a case recently where the RFC Editor removed the indentation and turned comprehensible pseudo-code into easy-to-misunderstand pseudo-code so something similar might happen here I think that the text should be reordered so that the indentation is not needed to make this easy to understand. For example, OLD This is intended to support URIs of the form: o "file:///c|/path/to/file" o "file:/c|/path/to/file" o "file:c|/path/to/file" Regular DOS or Windows file URIs, with vertical line characters in the drive letter construct. NEW This is intended to support regular DOS or Windows file URIs, with vertical line characters in the drive letter construct e.g. o "file:///c|/path/to/file" o "file:/c|/path/to/file" o "file:c|/path/to/file" This applies in several places in Appendix C. Appendix F This imports rules from the non-Normative Appendix C and is thus, I presume, non-Normative. Tom Petch Also, if any participant has knowledge of IPR that needs to be declared on this work, please do so, as required by BCPs 78 and 79. Dave Crocker is fulfilling the duties of document shepherd. -MSK, APPSAWG co-chair ------------------------------------------------------------------------ -------- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Tue Nov 24 04:22:36 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB081A1BC2 for ; Tue, 24 Nov 2015 04:22:35 -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 JKtLxZ5KLF6h for ; Tue, 24 Nov 2015 04:22:32 -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 C60D11A1BBD for ; Tue, 24 Nov 2015 04:22:32 -0800 (PST) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1a1CcB-0001n0-dw; Tue, 24 Nov 2015 12:22:31 +0000 Received: from gklyne38.plus.com ([81.174.129.24] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1a1CcB-0003GQ-Do; Tue, 24 Nov 2015 12:22:31 +0000 Message-ID: <56545687.3010400@ninebynine.org> Date: Tue, 24 Nov 2015 12:22:31 +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" , IETF Apps Discuss References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Archived-At: Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-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, 24 Nov 2015 12:22:35 -0000 All, Apologies for my late response - I missed the original last call, and early follow-up. I would be happy for this to go forward as-is, but I do have a couple of minor comments to offer (if only to prove I actually read it again!). ... [Minor] In section 3, I'm finding the reference to "implementation" a bit vague (does this mean URI generators, parsers, or what?), though I suppose it's easy enough to figure from the context. Suggest: OLD: 3. Operations on file URIs Implementations SHOULD, at a minimum, provide a read-like operation to return the contents of a file located by a file URI. Additional operations MAY be provided, such as writing to, creating, and deleting files. See the POSIX file and directory operations [POSIX] for examples of standardized operations that can be performed on files. NEW: 3. Operations on file URIs Implementations that provide dereferencing operations on file: URIs SHOULD, at a minimum, provide a read-like operation to return the contents of a file located by a file URI. Additional operations MAY be provided, such as writing to, creating, and deleting files. See the POSIX file and directory operations [POSIX] for examples of standardized operations that can be performed on files. (I hope it's clear that "dereference" is used here in the sense of section 1.2.2 of RFC3986 - https://tools.ietf.org/html/rfc3986#section-1.2.2) ... [Minor] In section 3, the text "can only be dereferenced" seems a bit strong - in that it appears to prohibit dereferencing lon-local file URIs. Suggest: OLD: A file URI can only be dereferenced or translated to a local file path if it is local. A file URI is considered "local" if it has a blank or no authority, or the authority is the special string "localhost". NEW: A file URI can be dependably dereferenced or translated to a local file path only if it is local. A file URI is considered "local" if it has a blank or no authority, or the authority is the special string "localhost". ... (Section 6, aside: it's really strange for me to read "HP OpenVMS Systems Documentation" -- but of course, it's quite correct.) ... Good work! #g -- On 02/11/2015 03:50, Murray S. Kucherawy wrote: > Colleagues, > > This note starts a Working Group Last Call for draft-ietf-appsawg-file-scheme. > This document has been with us for a while and feedback has fallen to a > trickle. We've gotten all the feedback from W3C that we expect, so we'd like to > move it toward publication. > > Please provide review comments or expressions of support for the current version > either on this list or privately to > draft-ietf-appsawg-file-scheme.all@tools.ietf.org > on or before November > 20, 2015. Be as detailed as possible. The co-chairs need to determine if the > document has working group consensus, which means we need to know people have > read the latest version and agree with its content and with the idea that it is > ready to proceed. A simple +1 doesnt tell us anything. > > Also, if any participant has knowledge of IPR that needs to be declared on this > work, please do so, as required by BCPs 78 and 79. > > Dave Crocker is fulfilling the duties of document shepherd. > > -MSK, APPSAWG co-chair > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Wed Nov 25 02:09:38 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F841A1A34; Wed, 25 Nov 2015 02:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 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_DE=0.35, RP_MATCHES_RCVD=-0.585, 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 zYWQNS7RW7iW; Wed, 25 Nov 2015 02:09:33 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF601A1A10; Wed, 25 Nov 2015 02:09:29 -0800 (PST) Received: from [192.168.1.158] (unknown [217.91.35.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 66FE215A04B2; Wed, 25 Nov 2015 11:09:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1448446167; bh=yLHQwgjl6NXtobGxt+fJCXqeQMh+Iz7bdpfVFqIBnk4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=R69ADN1YNUkb63yz9FOJHN5R9nuUhuCGbt9KO1t/90OXzVrUC3B8nhOcVpMHNfTQC I+Y6ppLrLK+E+8QAKv3h2d9E24NlXX70N0YSOC2zTuvTt6oiDjsDKWxNb3ZsPqc3LC CeAsA2w8eY6w01nfCyi+6DYyGCMayhVRSDm50vG4= To: ietf@ietf.org References: <20151120205655.17511.99851.idtracker@ietfa.amsl.com> From: Julian Reschke Message-ID: <565588D8.50402@greenbytes.de> Date: Wed, 25 Nov 2015 11:09:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151120205655.17511.99851.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-http-problem@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Problem Details for HTTP APIs) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 10:09:37 -0000 On 2015-11-20 21:56, The IESG wrote: > > The IESG has received a request from the ART Area General Applications > Working Group WG (appsawg) to consider the following document: > - 'Problem Details for HTTP APIs' > as Proposed Standard > > 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 2015-12-04. 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 > > > 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. > > Note to Readers > > This draft should be discussed on the apps-discuss mailing list [1]. > ... I don't believe that all of my WGLC feedback from December 2014 has been addressed (and that includes subjects on where we agreed on changes). See . Best regards, Julian From nobody Wed Nov 25 14:45:30 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DC61B31FB; Wed, 25 Nov 2015 14:45:28 -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 7uXLtqXBEAyW; Wed, 25 Nov 2015 14:45:26 -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 0D2861B31F8; Wed, 25 Nov 2015 14:45:26 -0800 (PST) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3E8FE22E200; Wed, 25 Nov 2015 17:45:20 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mark Nottingham In-Reply-To: <565588D8.50402@greenbytes.de> Date: Thu, 26 Nov 2015 09:45:18 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151120205655.17511.99851.idtracker@ietfa.amsl.com> <565588D8.50402@greenbytes.de> To: "Julian F. Reschke" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-http-problem@ietf.org, ietf@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Problem Details for HTTP APIs) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 22:45:28 -0000 Sorry about that, Julian. I've updated to include everything except the XML-related questions; = Erik?=20 See: http://mnot.github.io/I-D/http-problem/ = http://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-appsawg-http-problem-01&ur= l2=3Dhttps://mnot.github.io/I-D/http-problem/index.txt > On 25 Nov 2015, at 9:09 pm, Julian Reschke = wrote: >=20 > On 2015-11-20 21:56, The IESG wrote: >>=20 >> The IESG has received a request from the ART Area General = Applications >> Working Group WG (appsawg) to consider the following document: >> - 'Problem Details for HTTP APIs' >> as Proposed Standard >>=20 >> 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 2015-12-04. 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. >>=20 >> Abstract >>=20 >>=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 >> Note to Readers >>=20 >> This draft should be discussed on the apps-discuss mailing list = [1]. >> ... >=20 >=20 > I don't believe that all of my WGLC feedback from December 2014 has = been addressed (and that includes subjects on where we agreed on = changes). See = .= >=20 > Best regards, Julian -- Mark Nottingham https://www.mnot.net/ From nobody Wed Nov 25 17:30:36 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430341A8835 for ; Wed, 25 Nov 2015 17:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, 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 Hx9y3V40h2um for ; Wed, 25 Nov 2015 17:30:32 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6851B1A8833 for ; Wed, 25 Nov 2015 17:30:32 -0800 (PST) Received: by qgec40 with SMTP id c40so45179156qge.2 for ; Wed, 25 Nov 2015 17:30:31 -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=6IY4IxckcGdaOsj7mI4FMr7eeyNBRXmofuujmmdS4e8=; b=QIkrxcRTm4JCoYLfgrfOm9r7AeLHZ+AFCV7IEuInXYuhtctbJXk6r297ZWDIeGetde F5tJUUqRJAhNm4VUVedtsfMMT9jG05wuEYlhrGfiwDfJP7NdXcTl+2xGX2dp5SZJb62m Yim9qbT8v/qee7Aw93QZUl/MDnBSQl6RDni4P8WcwoDccJoML/qReZhaGSLO5wMTyfXZ 6Ib+z08k759/LmsN/3IQdvhHII/bQvJlJMrltYmF4n+Jlt7COwY1zocd/q+fBCJuQ98Q 9g2n/MY4dqaSLdo1yPWTWx814cFlDp9aT450cm81YR8dTtufP+M1pWWxB/dIXBHRL1z9 Zbbw== MIME-Version: 1.0 X-Received: by 10.140.249.137 with SMTP id u131mr6480699qhc.53.1448501431654; Wed, 25 Nov 2015 17:30:31 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.55.184.129 with HTTP; Wed, 25 Nov 2015 17:30:31 -0800 (PST) In-Reply-To: <01e701d126a2$726600e0$4001a8c0@gateway.2wire.net> References: <01e701d126a2$726600e0$4001a8c0@gateway.2wire.net> Date: Thu, 26 Nov 2015 11:30:31 +1000 X-Google-Sender-Auth: o9jq1Nsy2tql5nSOODS1awKaryU Message-ID: From: Matthew Kerwin To: "t.petch" Content-Type: multipart/alternative; boundary=001a113a0ffe4a648605256785af Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call fordraft-ietf-appsawg-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, 26 Nov 2015 01:30:35 -0000 --001a113a0ffe4a648605256785af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the review, I'll incorporate all the straight-forward suggestions (see inline). On 24 November 2015 at 20:24, t.petch wrote: > > > > Ah well, in that case I shall have to make some editorial suggestions:-) > > s1.1 > **/former/the former/ > > References > [Win32-Namespaces] > lacks a URL > =E2=80=8BThanks, I'll fix these. > =E2=80=8B > =E2=80=8B > > Appendix C > The phrase which starts > " Regular DOS or Windows file URIs, ..." > threw me at first, until I realised that it was an 'i.e.' for the three > lines above. There was a case recently where the RFC Editor removed the > indentation and turned comprehensible pseudo-code into > easy-to-misunderstand pseudo-code so something similar might happen here > I think that the text should be reordered so that the indentation is not > needed to make this easy to understand. For example, > > OLD > This is intended to support URIs of the form: > > o "file:///c|/path/to/file" > > o "file:/c|/path/to/file" > > o "file:c|/path/to/file" > > Regular DOS or Windows file URIs, with vertical line characters > in the drive letter construct. > > NEW > > This is intended to support regular DOS or Windows file URIs, with > vertical line characters in the drive letter construct e.g. > > o "file:///c|/path/to/file" > > o "file:/c|/path/to/file" > > o "file:c|/path/to/file" > > > This applies in several places in Appendix C. > =E2=80=8BI see the point here, and do want to avoid any potential issues w= ith readability. The current layout hangs over from when there was a single large list of examples of all the supported constructs. Now the "real" list shows up in Appendix A, with the non-standard fragments scattered throughout Section C. I'd like there to be consistency between the various examples; I'll think a bit more on how to present it. > =E2=80=8B > =E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B > Appendix F > > This imports rules from the non-Normative Appendix C and is thus, I > presume, non-Normative. > > =E2=80=8BYes, I'll make that explicit.=E2=80=8B > Tom Petch > > =E2=80=8BCheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a113a0ffe4a648605256785af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the review, I'll incorporate all t= he straight-forward suggestions (see inline).

On 24 November 2015 at 20:24, t.petch <ietfc@btconnect.com> wrote:

<tp>

Ah well, in that case I shall have to make some editorial suggestions:-)
s1.1
**/former/the former/

References
=C2=A0 =C2=A0[Win32-Namespaces]
lacks a URL

=E2= =80=8BThanks, I'll fix these.
=C2=A0
=E2=80=8B
=E2=80= =8B

Appendix C
The phrase which starts
" Regular DOS or Windows file URIs, ..."
threw me at first, until I realised that it was an 'i.e.' for the t= hree
lines above.=C2=A0 There was a case recently where the RFC Editor removed t= he
indentation and turned comprehensible pseudo-code into
easy-to-misunderstand pseudo-code so something similar might happen here I think that the text should be reordered so that the indentation is not needed to make this easy to understand.=C2=A0 For example,

OLD
This is intended to support URIs of the form:

=C2=A0 =C2=A0o=C2=A0 "file:///c|/path/to/file"

=C2=A0 =C2=A0o=C2=A0 "file:/c|/path/to/file"

=C2=A0 =C2=A0o=C2=A0 "file:c|/path/to/file"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regular DOS or Windows file URIs, with ve= rtical line characters
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the drive letter construct.

NEW

This is intended to support regular DOS or Windows file URIs, with
vertical line characters in the drive letter construct e.g.

=C2=A0 =C2=A0o=C2=A0 "file:///c|/path/to/file"

=C2=A0 =C2=A0o=C2=A0 "file:/c|/path/to/file"

=C2=A0 =C2=A0o=C2=A0 "file:c|/path/to/file"


This applies in several places in Appendix C.

= =E2=80=8BI see the point here, and =C2=A0do want to avoid any potential iss= ues with readability. The current layout hangs over from when there was a s= ingle large list of examples of all the supported constructs. Now the "= ;real" list shows up in Appendix A, with the non-standard fragments sc= attered throughout Section C. I'd like there to be consistency between = the various examples; I'll think a bit more on how to present it.
=

=C2=A0
=E2=80=8B
=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B
Appendix= F

This imports rules from the non-Normative Appendix C and is thus, I
presume, non-Normative.


=E2=80=8BYes, I'll make t= hat explicit.=E2=80=8B

=C2=A0
Tom Petch


=E2=80=8BCheers
--
=C2=A0 Matthew Kerwin
=C2= =A0 http://matt= hew.kerwin.net.au/
--001a113a0ffe4a648605256785af-- From nobody Wed Nov 25 17:50:26 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B791A8902 for ; Wed, 25 Nov 2015 17:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.373 X-Spam-Level: X-Spam-Status: No, score=0.373 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 YYbJkcM3qQdx for ; Wed, 25 Nov 2015 17:50:22 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DDDA1A88FF for ; Wed, 25 Nov 2015 17:50:22 -0800 (PST) Received: by qkda6 with SMTP id a6so22655813qkd.3 for ; Wed, 25 Nov 2015 17:50: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=lrbKco7Kyn0wyIAZy7pwQgXf+yrfgBABSdrXH0zumhg=; b=0z1hhJ4agKppBw0CnGBEFUItJWbL/dDcspuz6e4Mnqr8Z4q4rDqdLHlOlAEb84B1q8 TB8Wj0X4/k/gNXYC700pV8OVzRYPda6uo2lfm4XQk2JhaBCzaow1V9Q+CqPsjMNGWLK7 UFacm1KOP4RYm9yBfRoE6WW8ICqonvqCb230+BRE6FP7ABCQx4Bwi3BEdNl+Pcoj84gy WZDjc77E8ESeDYEKsiQW2Gv+Fg4GNLRg/6iig9snvusrgLkz9n36EfNbb+Dzt0BBjauU 1KVuxrndj4aGTI1Dll8dMJED2waOE32Km7BwImS/MpTlDzgcMepA4caL9mGTmUXVl34R D1Zw== MIME-Version: 1.0 X-Received: by 10.55.79.86 with SMTP id d83mr22901102qkb.22.1448502621569; Wed, 25 Nov 2015 17:50:21 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.55.184.129 with HTTP; Wed, 25 Nov 2015 17:50:21 -0800 (PST) In-Reply-To: <56545687.3010400@ninebynine.org> References: <56545687.3010400@ninebynine.org> Date: Thu, 26 Nov 2015 11:50:21 +1000 X-Google-Sender-Auth: HsOe08EPTISbrdQRHK6On6eS4uw Message-ID: From: Matthew Kerwin To: Graham Klyne Content-Type: multipart/alternative; boundary=001a114a727e37099b052567cc10 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-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, 26 Nov 2015 01:50:24 -0000 --001a114a727e37099b052567cc10 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 24 November 2015 at 22:22, Graham Klyne wrote: > All, > > Apologies for my late response - I missed the original last call, and > early follow-up. > > I would be happy for this to go forward as-is, but I do have a couple of > minor comments to offer (if only to prove I actually read it again!). > > =E2=80=8BThanks, it's appreciated.=E2=80=8B > ... > > [Minor] In section 3, I'm finding the reference to "implementation" a bit > vague (does this mean URI generators, parsers, or what?), though I suppos= e > it's easy enough to figure from the context. > > Suggest: > > OLD: > 3. Operations on file URIs > > Implementations SHOULD, at a minimum, provide a read-like operation > to return the contents of a file located by a file URI. Additional > operations MAY be provided, such as writing to, creating, and > deleting files. See the POSIX file and directory operations [POSIX] > for examples of standardized operations that can be performed on > files. > > NEW: > 3. Operations on file URIs > > Implementations that provide dereferencing operations on file: URIs > SHOULD, at a minimum, provide a read-like operation > to return the contents of a file located by a file URI. Additional > operations MAY be provided, such as writing to, creating, and > deleting files. See the POSIX file and directory operations [POSIX] > for examples of standardized operations that can be performed on > files. > > (I hope it's clear that "dereference" is used here in the sense of sectio= n > 1.2.2 of RFC3986 - https://tools.ietf.org/html/rfc3986#section-1.2.2) > > =E2=80=8BYeah, that's a fair call. I'll take the suggested addition.=E2=80= =8B > ... > > [Minor] In section 3, the text "can only be dereferenced" seems a bit > strong - in that it appears to prohibit dereferencing lon-local file URIs= . > > Suggest: > > OLD: > A file URI can only be dereferenced or translated to a local file > path if it is local. A file URI is considered "local" if it has a > blank or no authority, or the authority is the special string > "localhost". > > > NEW: > A file URI can be dependably dereferenced or translated to a local fil= e > path only if it is local. A file URI is considered "local" if it has = a > blank or no authority, or the authority is the special string > "localhost". > > =E2=80=8BAgain, yes, that's good. I think it better expresses the intent. = This is a little different from 1738, which seemed to carry the weight of judgement (remote files are bad, don't read them) but I don't think that's what we want to say now. > ... > > (Section 6, aside: it's really strange for me to read "HP OpenVMS Systems > Documentation" -- but of course, it's quite correct.) > > Starlet? VAX? Micro? (I used Wikipedia to look those up; to me they're just arcane words you see from time to time in ancient manuals.) > ... > > Good work! > > #g > -- > > =E2=80=8BThanks! =E2=80=8BCheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a114a727e37099b052567cc10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 24 November 2015 at 22:22, Graham Klyne = <gk@ninebynine.or= g> wrote:
All,

Apologies for my late response - I missed the original last call, and early= follow-up.

I would be happy for this to go forward as-is, but I do have a couple of mi= nor comments to offer (if only to prove I actually read it again!).


=E2=80=8BThanks, it's app= reciated.=E2=80=8B

=C2=A0
...

[Minor] In section 3, I'm finding the reference to "implementation= " a bit vague (does this mean URI generators, parsers, or what?), thou= gh I suppose it's easy enough to figure from the context.

Suggest:

OLD:
3.=C2=A0 Operations on file URIs

=C2=A0 =C2=A0Implementations SHOULD, at a minimum, provide a read-like oper= ation
=C2=A0 =C2=A0to return the contents of a file located by a file URI.=C2=A0 = Additional
=C2=A0 =C2=A0operations MAY be provided, such as writing to, creating, and<= br> =C2=A0 =C2=A0deleting files.=C2=A0 See the POSIX file and directory operati= ons [POSIX]
=C2=A0 =C2=A0for examples of standardized operations that can be performed = on
=C2=A0 =C2=A0files.

NEW:
3.=C2=A0 Operations on file URIs

=C2=A0 =C2=A0Implementations that provide dereferencing operations on file:= URIs
=C2=A0 =C2=A0SHOULD, at a minimum, provide a read-like operation
=C2=A0 =C2=A0to return the contents of a file located by a file URI.=C2=A0 = Additional
=C2=A0 =C2=A0operations MAY be provided, such as writing to, creating, and<= br> =C2=A0 =C2=A0deleting files.=C2=A0 See the POSIX file and directory operati= ons [POSIX]
=C2=A0 =C2=A0for examples of standardized operations that can be performed = on
=C2=A0 =C2=A0files.

(I hope it's clear that "dereference" is used here in the sen= se of section 1.2.2 of RFC3986 - https://tools.ietf= .org/html/rfc3986#section-1.2.2)


=E2=80=8BYeah, that's a f= air call. I'll take the suggested addition.=E2=80=8B

=C2=A0
...

[Minor] In section 3, the text "can only be dereferenced" seems a= bit strong - in that it appears to prohibit dereferencing lon-local file U= RIs.

Suggest:

OLD:
=C2=A0 =C2=A0A file URI can only be dereferenced or translated to a local f= ile
=C2=A0 =C2=A0path if it is local.=C2=A0 A file URI is considered "loca= l" if it has a
=C2=A0 =C2=A0blank or no authority, or the authority is the special string<= br> =C2=A0 =C2=A0"localhost".


NEW:
=C2=A0 =C2=A0A file URI can be dependably dereferenced or translated to a l= ocal file
=C2=A0 =C2=A0path only if it is local.=C2=A0 A file URI is considered "= ;local" if it has a
=C2=A0 =C2=A0blank or no authority, or the authority is the special string<= br> =C2=A0 =C2=A0"localhost".


=E2=80=8BAgain, yes, that'= ;s good. I think it better expresses the intent.=C2=A0 This is a little dif= ferent from 1738, which seemed to carry the weight of judgement (remote fil= es are bad, don't read them) but I don't think that's what we w= ant to say now.
=C2=A0
...

(Section 6, aside: it's really strange for me to read "HP OpenVMS = Systems Documentation" -- but of course, it's quite correct.)


Starlet? VAX? Micro? (I used = Wikipedia to look those up; to me they're just arcane words you see fro= m time to time in ancient manuals.)

=C2=A0
...

Good work!

#g
--


= =E2=80=8BThanks!

=E2=80=8BCheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a114a727e37099b052567cc10-- From nobody Sat Nov 28 12:29:40 2015 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6201B35A2; Sat, 28 Nov 2015 12:29:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151128202938.6893.25935.idtracker@ietfa.amsl.com> Date: Sat, 28 Nov 2015 12:29:38 -0800 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-mdn-3798bis-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: Sat, 28 Nov 2015 20:29:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ART Area General Applications Working Group Working Group of the IETF. Title : Message Disposition Notification Authors : Tony Hansen Alexey Melnikov Filename : draft-ietf-appsawg-mdn-3798bis-04.txt Pages : 32 Date : 2015-11-28 Abstract: This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-mdn-3798bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-mdn-3798bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-mdn-3798bis-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 Mon Nov 30 16:43:53 2015 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4191A1B34AB; Mon, 30 Nov 2015 16:43:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151201004350.6084.94598.idtracker@ietfa.amsl.com> Date: Mon, 30 Nov 2015 16:43:50 -0800 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-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: Tue, 01 Dec 2015 00:43:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ART Area General Applications Working Group Working Group of the IETF. Title : The file URI Scheme Author : Matthew Kerwin Filename : draft-ietf-appsawg-file-scheme-05.txt Pages : 20 Date : 2015-11-30 Abstract: This document specifies the "file" Uniform Resource Identifier (URI) scheme, obsoleting the definition in RFC 1738. It attempts to define a common core which is intended to interoperate across the broad spectrum of existing implementations, while at the same time documenting other current practices. Note to Readers (To be removed by the RFC Editor) This draft should be discussed on the IETF Applications Area Working Group discussion list . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-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 Nov 30 16:56:35 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC83F1B34FC for ; Mon, 30 Nov 2015 16:56:33 -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 3uircKC62PmD for ; Mon, 30 Nov 2015 16:56:32 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB0E1B34F6 for ; Mon, 30 Nov 2015 16:56:31 -0800 (PST) Received: by qgec40 with SMTP id c40so133366304qge.2 for ; Mon, 30 Nov 2015 16:56: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:content-type; bh=q17R8yb6ZdmO33hQC1/PObuRX5tkOgiRDJRc3QRn2dg=; b=vYI7oTGntkksyha+Ma4ntg6Mzl2GMgIygcZPHri7ZLKvC3J9mW2knNzmIVOh6EQ3wU h8Q805LRZqiSZ+o4eW9LdBKfs0D14emBRgatQ97x/iM/sCQY062zvr90ZiZiZaB1jT5f DhQHUgKVWscFDGLGHduXEEAdhhzqfpRSZmTwxKGPPj4VzO7XCTFqeLDtYDV+pLNB0S3J YU/zcHYS+iBprVs/aCSTvj5JPCPerVyTpfyjw0dlKvJGpc2UTMhTe6Cpp+b6qyZWfZoU V4CCG/wNZNaRvbtNKNknvf+A85Ps3N30f/lLsGCnlAW2vAa9Lwyi0+K7wDodT+NzrUVv yeuA== MIME-Version: 1.0 X-Received: by 10.140.249.131 with SMTP id u125mr36732932qhc.53.1448931390168; Mon, 30 Nov 2015 16:56:30 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.55.184.129 with HTTP; Mon, 30 Nov 2015 16:56:30 -0800 (PST) In-Reply-To: <20151201004350.6084.94598.idtracker@ietfa.amsl.com> References: <20151201004350.6084.94598.idtracker@ietfa.amsl.com> Date: Tue, 1 Dec 2015 10:56:30 +1000 X-Google-Sender-Auth: 2tZrSsmRRJfXJXuIfit3KcWRvHQ Message-ID: From: Matthew Kerwin To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a113a8a2cd0a6410525cba080 Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-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: Tue, 01 Dec 2015 00:56:34 -0000 --001a113a8a2cd0a6410525cba080 Content-Type: text/plain; charset=UTF-8 Hi folks, I've pushed out a new version of the file URI draft which I believe addresses most of the feedback received over the past couple of weeks. Looking at the rfcdiff[1] the biggest changes were: being more clear about how we're using/overriding components like "authority" from RFC 3986, and rearranging the examples throughout the appendices to be "description - example" (from "example - description".) I also misspelled "ooperation." :\ Cheers [1]: https://tools.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-05.txt On 1 December 2015 at 10:43, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the ART Area General Applications Working > Group Working Group of the IETF. > > Title : The file URI Scheme > Author : Matthew Kerwin > Filename : draft-ietf-appsawg-file-scheme-05.txt > Pages : 20 > Date : 2015-11-30 > > Abstract: > This document specifies the "file" Uniform Resource Identifier (URI) > scheme, obsoleting the definition in RFC 1738. > > It attempts to define a common core which is intended to interoperate > across the broad spectrum of existing implementations, while at the > same time documenting other current practices. > > Note to Readers (To be removed by the RFC Editor) > > This draft should be discussed on the IETF Applications Area Working > Group discussion list . > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-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/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Matthew Kerwin http://matthew.kerwin.net.au/ --001a113a8a2cd0a6410525cba080 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,

I'= ve pushed out a new version of the file URI draft which I believe addresses= most of the feedback received over the past couple of weeks. Looking at th= e rfcdiff[1] the biggest changes were: being more clear about how we're= using/overriding components like "authority" from RFC 3986, and = rearranging the examples throughout the appendices to be "description = - example" (from "example - description".)
<= br>
I also misspelled "ooperation." =C2=A0:\
<= div class=3D"gmail_default" style=3D"font-family:georgia,serif;color:rgb(7,= 55,99)">
Cheers

[1= ]: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-fi= le-scheme-05.txt


On 1 December 2015 at 10:= 43, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the ART Area General Applications Workin= g Group Working Group of the IETF.

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

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

=C2=A0 =C2=A0It attempts to define a common core which is intended to inter= operate
=C2=A0 =C2=A0across the broad spectrum of existing implementations, while a= t the
=C2=A0 =C2=A0same time documenting other current practices.

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

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


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

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

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


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

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

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



--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwi= n.net.au/
--001a113a8a2cd0a6410525cba080--