On 14 May 2014 22:47, Doug Ewell <doug@ewellic.org> w= rote:

Mark Davis =E2=98=95=EF=B8= =8F <mark at macchiato dot com> wrote:

> I'm sure you're not implying that I think invalid UTF-8 would = have
> been a good idea, but your statement might not be clear to others.

To clarify, I got that impression from Dave's remark, which is wh= y I
originally quoted it:

] Many years ago, Mark Crispin and Chris Newman had a proposal for

] embedding language tags in invalid UTF-8; I seem to recal= l they
] publicly renounced their proposal rather dramatically in favour of a
] Unicode Consortium proposal for embedding the language tags somewhere
] in Plane 14 - published as RFC 2482.
]
] The fact it was all initiated in order to support the pressing needs
] of ACAP might give you some hints as to why it never really took off,
] but as a counter-proposal to language tags in metadata, it might be
] worth re-examining.

I'm not sure, upon re-reading this, whether Dave meant to say tha= t Plane
14 tags or invalid UTF-8 was worth re-examining.

<= /div>

Either/neither/both.

Of course, an inval= id-UTF-8 based proposal simply means that it's no longer UTF-8 per-se, = and so needs itself to be tagged differently. Other than that, I don't = see it's a bad idea from a technical standpoint. The use of the word &q= uot;invalid" probably scares people, but I note that's really a sh= orthand for "not backwards compatible by existing UTF-8 processors&quo= t;.

Exactly the same caveats apply to Plane 14 tagging, min= d, and moreover, we could invent our own - indeed, that's what we'r= e doing by having these arrays of (tag, string) tuples.

Inline tagging is out of fashion, I agree - and as I said, it never re= ally caught on in part because the only protocol that cared - ACAP - never = caught on itself. What I was suggesting was that this technique exists, and= a new type for "language tagged string" is not impossible to arr= ange, and actually aligns with the goal here.

Whether this is the right solution here is an entirely = different question, and the one I was hoping wouldn't be rejected out o= f hand - in no small part because all we're doing here is inventing a n= ew bespoke format for CBOR to do the same thing.

The main consideration, I think, is what happens when a= CBOR processor encounters a language-tagged string when it doesn't und= erstand the concept. Extending UTF-8 seems generally undesirable since the = UTF-8 processor is likely to be an off-the-shelf black box, Plane 14 shows = up as unknown characters, and the array-of-tuple shows up as arrays of tupl= es. I'm not sure any of those are desirable.

I'd further note that CBOR processors are, at this = stage, likely to be bespoke, so changes there seem acceptable. Either of th= e latter two can be handled that way.

Finally, I d= on't have a horse in this race, I was just wondering if anyone else had= noticed there were other horses.

Dave.

--047d7b472832db8e8804f96b75f2-- From nobody Thu May 15 05:26:10 2014 Return-Path: X-Original-To: ltru@ietfa.amsl.com Delivered-To: ltru@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5081A04CA for ; Thu, 15 May 2014 05:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.352 X-Spam-Level: X-Spam-Status: No, score=-1.352 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0ULW60zEITt for ; Thu, 15 May 2014 05:26:07 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6A011A03D4 for ; Thu, 15 May 2014 05:26:07 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WkuR0-0002cv-UR; Thu, 15 May 2014 08:06:54 -0400 Date: Thu, 15 May 2014 08:06:50 -0400 From: John Cowan To: Dave Cridland Message-ID: <20140515120647.GH13350@mercury.ccil.org> References: <20140514144716.665a7a7059d7ee80bb4d670165c8327d.4ebffc2f64.wbe@email03.secureserver.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/ltru/Iii9Z6Tj-9znf3MB-iUnd2GLqjQ Cc: LTRU Working Group , Doug Ewell Subject: Re: [Ltru] [apps-discuss] Fwd: Defining a CBOR tag for RFC 5646 Language Tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 12:26:10 -0000 Dave Cridland scripsit: > Of course, an invalid-UTF-8 based proposal simply means that it's no > longer UTF-8 per-se, and so needs itself to be tagged differently. The whole point of the invalid-UTF-8 was that the less fussy decoders of the day would quietly drop the hidden information and display the string. That is much less likely to happen now. > Exactly the same caveats apply to Plane 14 tagging, mind, Not so much. Unicode renderers that don't understand language tags will not display them (because stuff on plane E is never displayed per its Unicode properties), or if the renderer doesn't even understand that, will at worst generate boxes or other "character unknown" glyphs, often only three of them. > The main consideration, I think, is what happens when a CBOR processor > encounters a language-tagged string when it doesn't understand the concept. Agreed, and if that is a serious problem, Plane E starts to look better. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org [P]olice in many lands are now complaining that local arrestees are insisting on having their Miranda rights read to them, just like perps in American TV cop shows. When it's explained to them that they are in a different country, where those rights do not exist, they become outraged. --Neal Stephenson From nobody Thu May 15 05:31:46 2014 Return-Path: X-Original-To: ltru@ietfa.amsl.com Delivered-To: ltru@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9201A0285 for ; Thu, 15 May 2014 05:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tivd055EveyH for ; Thu, 15 May 2014 05:31:33 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C2E1A029A for ; Thu, 15 May 2014 05:31:29 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id m1so1141529oag.14 for ; Thu, 15 May 2014 05:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mTI6/IpeeotEkVe2zqEjEK5pimD5evUMeh7mdcyWT7A=; b=VaEfhE3B7QzWYLkls96valwP1SzugLuC+rbsB70kv86HQ7Ge8DVxagxACIsAkx45ZN EPVNWmBex/kahTDchITXjrM6JeXEmuWu4ovaUfaW82c34sUWORMmC4/VqSvtuERk8amm Yl8gEVn/ojlqe9QV6VQqIawyo+8fOgurhLmbI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mTI6/IpeeotEkVe2zqEjEK5pimD5evUMeh7mdcyWT7A=; b=gk2aem/UHKEcpQBPkE1gC/h/VbVQ/ew/z01JcOJEpL/CTQTj/vfPnCmiNqDPoKeBIk wSTXpKpny8RECL8BdFNmD1bEpkOTdOMr8edQSfFH+Itm2VAg0wd9e/1hNGzf1GBRcH3d z+E8vU9BpU0YkgldzhT8uT1FX+wxZuXzPouLvx1ArZNY4tDBH3HdSc9hjTpO4PFZwKBS iv7j44qTR9MBbwdqwks6HuAIhoYORSdhKZpV3WGFX0c0OJ7IGCpSlqc9eJEspyX/etTF qqzyMcWiLrTmra70U6igr2WLVHIkXBhGL9f0jt2g1aZe/gdCOswkzSrSdkly1I55LfYP Zq3w== X-Gm-Message-State: ALoCoQl+r9dsYdA2L88oV8lXLQstdT2p2CtQwJGaeWIUqvZSQ0yvYtqAz97mqG81DSLQo9gLy5Q0 MIME-Version: 1.0 X-Received: by 10.60.44.100 with SMTP id d4mr44959oem.6.1400157082770; Thu, 15 May 2014 05:31:22 -0700 (PDT) Received: by 10.60.60.100 with HTTP; Thu, 15 May 2014 05:31:22 -0700 (PDT) In-Reply-To: <20140515120647.GH13350@mercury.ccil.org> References: <20140514144716.665a7a7059d7ee80bb4d670165c8327d.4ebffc2f64.wbe@email03.secureserver.net> <20140515120647.GH13350@mercury.ccil.org> Date: Thu, 15 May 2014 13:31:22 +0100 Message-ID: From: Dave Cridland To: John Cowan Content-Type: multipart/alternative; boundary=001a11c2ee228c6eb804f96f79fc Archived-At: http://mailarchive.ietf.org/arch/msg/ltru/fp7cEoR6lgenySFvpnOX9ix1dss Cc: LTRU Working Group , Doug Ewell Subject: Re: [Ltru] [apps-discuss] Fwd: Defining a CBOR tag for RFC 5646 Language Tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 12:31:34 -0000 --001a11c2ee228c6eb804f96f79fc Content-Type: text/plain; charset=UTF-8 Thanks for the corrections; I shall now slouch into silence because I honestly have very little opinion. On 15 May 2014 13:06, John Cowan wrote: > Dave Cridland scripsit: > > > Of course, an invalid-UTF-8 based proposal simply means that it's no > > longer UTF-8 per-se, and so needs itself to be tagged differently. > > The whole point of the invalid-UTF-8 was that the less fussy decoders of > the day would quietly drop the hidden information and display the string. > That is much less likely to happen now. > > > Exactly the same caveats apply to Plane 14 tagging, mind, > > Not so much. Unicode renderers that don't understand language tags will > not display them (because stuff on plane E is never displayed per its > Unicode properties), or if the renderer doesn't even understand that, > will at worst generate boxes or other "character unknown" glyphs, > often only three of them. > > > The main consideration, I think, is what happens when a CBOR processor > > encounters a language-tagged string when it doesn't understand the > concept. > > Agreed, and if that is a serious problem, Plane E starts to look better. > > --001a11c2ee228c6eb804f96f79fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Than= ks for the corrections; I shall now slouch into silence because I honestly = have very little opinion.

On 15 May 2014 13:06, John Cowan <cowan@mercury.ccil.org> wrote:

Dave Cridland scripsit:

> Of course, an invalid-UTF-8 based proposal simply means that it's = no
> longer UTF-8 per-se, and so needs itself to be tagged differently.

The whole point of the invalid-UTF-8 was that the less fussy decoders= of
the day would quietly drop the hidden information and display the string. That is much less likely to happen now.

> Exactly the same caveats apply to Plane 14 tagging, mind,

Not so much. =C2=A0Unicode renderers that don't understand langua= ge tags will
not display them (because stuff on plane E is never displayed per its
Unicode properties), or if the renderer doesn't even understand that, will at worst generate boxes or other "character unknown" glyphs,=
often only three of them.

> The main consideration, I think, is what happens when a CBOR processor=
> encounters a language-tagged string when it doesn't understand the= concept.

Agreed, and if that is a serious problem, Plane E starts to look bett= er.

--001a11c2ee228c6eb804f96f79fc-- From nobody Thu May 15 08:40:10 2014 Return-Path: X-Original-To: ltru@ietfa.amsl.com Delivered-To: ltru@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137161A00DF for ; Thu, 15 May 2014 08:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zi1uW0oGD3Up for ; Thu, 15 May 2014 08:40:03 -0700 (PDT) Received: from p3plwbeout03-02.prod.phx3.secureserver.net (p3plsmtp03-02-2.prod.phx3.secureserver.net [72.167.218.214]) by ietfa.amsl.com (Postfix) with ESMTP id 923361A008D for ; Thu, 15 May 2014 08:40:03 -0700 (PDT) Received: from localhost ([72.167.218.245]) by p3plwbeout03-02.prod.phx3.secureserver.net with bizsmtp id 2Ffw1o0035JG3DC01FfwTq; Thu, 15 May 2014 08:39:56 -0700 X-SID: 2Ffw1o0035JG3DC01 Received: (qmail 29233 invoked by uid 99); 15 May 2014 15:39:56 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 208.51.143.189 User-Agent: Workspace Webmail 5.6.47 Message-Id: <20140515083955.665a7a7059d7ee80bb4d670165c8327d.b69c089194.wbe@email03.secureserver.net> From: "Doug Ewell" To: "Dave Cridland" Date: Thu, 15 May 2014 08:39:55 -0700 Mime-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ltru/u_3YextF2L7GwVxlwtZGckU71rs Cc: LTRU Working Group Subject: Re: [Ltru] [apps-discuss] Fwd: Defining a CBOR tag for RFC 5646 Language Tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 15:40:05 -0000 Dave Cridland wrote:=0A=0A> Of course, an invali= d-UTF-8 based proposal simply means that it's no=0A> longer UTF-8 per-se, a= nd so needs itself to be tagged differently.=0A> Other than that, I don't s= ee it's a bad idea from a technical=0A> standpoint. The use of the word "in= valid" probably scares people, but=0A> I note that's really a shorthand for= "not backwards compatible by=0A> existing UTF-8 processors".=0A=0AThe prop= osal from 1997 ("MLSF") did call it an extra layer on top of=0AUTF-8, and i= ncluded lots of health warnings that it was not really=0AUTF-8. That didn't= remove the danger, though, because it looked so much=0Alike UTF-8. John's = response about decoders was spot-on.=0A=0A> Exactly the same caveats apply = to Plane 14 tagging, mind, and=0A> moreover, we could invent our own - inde= ed, that's what we're doing by=0A> having these arrays of (tag, string) tup= les.=0A=0ASince CBOR processors are likely to be bespoke, as you said, but = the=0Aunderlying UTF-8 processor is not -- as you also said -- it would be= =0Amuch easier to strip out Plane 14 characters for display if necessary=0A= than to implement a whole new UTF-8=E2=80=93like decoding-stream layer that= =0Aunderstands MLSF.=0A=0AAs Mark knows, I never bought into the deprecatio= n argument about how=0Aevil Plane 14 tag characters are. Handling them corr= ectly just isn't=0Athat difficult. For CBOR, you may be better off with the= tag/string=0Atuples; the tags in that case are much easier to see and don'= t need to=0Abe stripped from the string for display or comparison. But if t= his=0A"tagged text" model is too far out of step with the CBOR/JSON way of= =0Athinking, Plane 14 is out there.=0A=0A--=0ADoug Ewell | Thornton, CO, US= A=0Ahttp://ewellic.org | @DougEwell=0A From nobody Thu May 15 09:35:33 2014 Return-Path: X-Original-To: ltru@ietfa.amsl.com Delivered-To: ltru@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED3A1A04F8; Thu, 15 May 2014 09:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ik-OF1S8kL7P; Thu, 15 May 2014 09:35:30 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47FA31A00C2; Thu, 15 May 2014 09:35:30 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id a108so2123969qge.36 for ; Thu, 15 May 2014 09:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=gT2eh/GxUgPIJQiherfxI26U1jhsnYLTUYajrtm6Fxs=; b=Y7tG7Os/Gn5S/wH9eU8V26APdS7YVwix+aN7ZGNuGT4lFGymEWYbPIaodCi/cxyjOJ GFliDKxBj17qkzZAwBA0SjnOMh6nEO7bnIOYMl08dD1GFlmt6xW+7OgqyPUOgASLh6lM zk0vSJYtfj3lOoF2b1uWn+JCICYvFWPPpoMIViADkMGTgZesekt/NY+QtL7ynk2H9e5j qUIOfwtTo4nJQM+JkS+y+iL2JYIpgD6c4SFh8V8rXDtZyqNuJ2BQO2yugJ/SCSIswRit 48vt5d17P8troLot3nLvAVwxy6xyvAjP05/641xH0ykZaNdu6aOo2j+bpWeXKhTIJ7fd lj+Q== X-Received: by 10.224.119.131 with SMTP id z3mr14609582qaq.91.1400171722542; Thu, 15 May 2014 09:35:22 -0700 (PDT) Received: from PeterPC (c-50-169-108-108.hsd1.ma.comcast.net. [50.169.108.108]) by mx.google.com with ESMTPSA id w2sm8635191qar.21.2014.05.15.09.35.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 May 2014 09:35:21 -0700 (PDT) Message-ID: <15955C4E122344DDBBAA53E803A8F08E@PeterPC> From: "Peter Occil" To: "LTRU Working Group" , References: <18971982.1399873468367.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <9BE5D3F7FAEE4CAB8FD3326ED8F1ED75@PeterPC> <0C126A09-1909-449E-B0B4-9F41677710E2@tzi.org> <92A56D2F207E4A9893AEDBC13336FA28@PeterPC> In-Reply-To: <92A56D2F207E4A9893AEDBC13336FA28@PeterPC> Date: Thu, 15 May 2014 12:35:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-Antivirus: avast! (VPS 140515-0, 05/15/2014), Outbound message X-Antivirus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/ltru/9iBJcee_PvQegHqVy11iARLqsRg Cc: Carsten Bormann Subject: Re: [Ltru] [apps-discuss] Defining a CBOR tag for RFC 5646Language Tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 16:35:31 -0000 I have updated my specification on language-tagged strings. http://peteroupc.github.io/CBOR/langtags.html The two things new are: - The "NOTE" section. - The sentence "Both the language tag and the arbitrary string can optionally be annotated with CBOR tags." --Peter From nobody Thu May 15 16:37:39 2014 Return-Path: X-Original-To: ltru@ietfa.amsl.com Delivered-To: ltru@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFB51A01C2 for ; Thu, 15 May 2014 16:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8_x8eauXDPS for ; Thu, 15 May 2014 16:37:35 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 386C11A01F1 for ; Thu, 15 May 2014 16:37:35 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id l6so3115809qcy.9 for ; Thu, 15 May 2014 16:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=53hIThFS/6Fk86z8TKTrT6KQQWvZhyTKaSGnRi5hqZw=; b=Lr4Y0sZDONQqEjOd9lHy31TmiFSL8Av2W5b2aub7V9OoXOhaabb2oThRxvJPjpmeW0 y/IMseGo9L1dv5Ce/FOttTDgG1odHbc/FajeVI4+DpDyJTaAQIIbMS4m8/Ri58xqGrZ+ 0YHUYEw/JRnsqqDGcfF2LODewAXJqClkgmG14hWZCzBIwwRC5lyXGAM/9J7ahfCWh4nm RmkdRHyF2ftlRGeNmYZX6E+B3u4qylNvezyQqhgObBHxF15V1f+ZoZW1Ls/pO+VRMYcp e0X3NncjRu2aiXOw0Rr2sJavZ6SecGIo2ygRDBxu/eiJaT5Vs3QvG58gcSYdvSbbOy2M shwA== X-Received: by 10.224.161.83 with SMTP id q19mr18050746qax.56.1400197047604; Thu, 15 May 2014 16:37:27 -0700 (PDT) MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.229.151.81 with HTTP; Thu, 15 May 2014 16:37:07 -0700 (PDT) In-Reply-To: <20140515083955.665a7a7059d7ee80bb4d670165c8327d.b69c089194.wbe@email03.secureserver.net> References: <20140515083955.665a7a7059d7ee80bb4d670165c8327d.b69c089194.wbe@email03.secureserver.net> From: =?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?= Date: Thu, 15 May 2014 16:37:07 -0700 X-Google-Sender-Auth: Z3IPOU6ubfg3UKE8yyd6OpE__Lw Message-ID: To: Doug Ewell Content-Type: multipart/alternative; boundary=089e0149ccdea35e9d04f978c7c2 Archived-At: http://mailarchive.ietf.org/arch/msg/ltru/WowmfjeIF0JXsOL5Tv541d0hjDI Cc: LTRU Working Group , Dave Cridland Subject: Re: [Ltru] [apps-discuss] Fwd: Defining a CBOR tag for RFC 5646 Language Tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 23:37:36 -0000 --089e0149ccdea35e9d04f978c7c2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, May 15, 2014 at 8:39 AM, Doug Ewell wrote: > But if this > "tagged text" model is too far out of step with the CBOR/JSON way of > thinking, Plane 14 is out there. > =E2=80=8BI was perhaps not forceful enough. Deprecated Unicode characters s= hould *never* be generated by any modern software, and that includes the language tags. They certainly should not be used in any new protocol. Mark *=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94* --089e0149ccdea35e9d04f978c7c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, May 15, 2014 at 8:39 AM, Doug Ewell <doug@ewellic.org> wrote:

But if this
"tagged text" model is too far out of step with the CBOR/JSON way= of
thinking, Plane 14 is out there.

=E2=80= =8BI was perhaps not forceful enough. Deprecated Unicode characters should = never be generated by any modern software, and that includes the lan= guage tags. They certainly should not be used in any new protocol.

Mark

=E2=80=94 Il meglio = =C3=A8 l=E2=80=99inimico del bene =E2=80=94

--089e0149ccdea35e9d04f978c7c2-- From nobody Thu May 15 19:32:41 2014 Return-Path: X-Original-To: ltru@ietfa.amsl.com Delivered-To: ltru@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF481A0032 for ; Thu, 15 May 2014 19:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.539 X-Spam-Level: * X-Spam-Status: No, score=1.539 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, STOX_REPLY_TYPE=0.439] 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 FT3YYW6OPQWI for ; Thu, 15 May 2014 19:32:38 -0700 (PDT) Received: from p3plsmtpa07-05.prod.phx3.secureserver.net (p3plsmtpa07-05.prod.phx3.secureserver.net [173.201.192.234]) by ietfa.amsl.com (Postfix) with ESMTP id C04611A000F for ; Thu, 15 May 2014 19:32:38 -0700 (PDT) Received: from DougEwell ([65.128.12.85]) by p3plsmtpa07-05.prod.phx3.secureserver.net with id 2SYV1o0051q5wH501SYV3D; Thu, 15 May 2014 19:32:31 -0700 Message-ID: <63CE3F1B0A474CD9B023A3D330BEED32@DougEwell> From: "Doug Ewell" To: =?utf-8?Q?Mark_Davis_=E2=98=95=EF=B8=8F?= References: <20140515083955.665a7a7059d7ee80bb4d670165c8327d.b69c089194.wbe@email03.secureserver.net> In-Reply-To: Date: Thu, 15 May 2014 20:32:49 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Archived-At: http://mailarchive.ietf.org/arch/msg/ltru/Ka6SN5wiPrDXMKgG9bn2ngUoZ5M Cc: LTRU Working Group , Dave Cridland Subject: Re: [Ltru] [apps-discuss] Fwd: Defining a CBOR tag for RFC 5646 Language Tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 02:32:39 -0000 Mark Davis 🍶 wrote: >> But if this "tagged text" model is too far out of step with the >> CBOR/JSON way of thinking, Plane 14 is out there. > > I was perhaps not forceful enough. Deprecated Unicode characters > should *never* be generated by any modern software, and that includes > the language tags. They certainly should not be used in any new > protocol. And if Peter and Dave had decided that an out-of-band tagging model for CBOR was simply unworkable (which they did not, thankfully), and they were left with a choice between Plane 14 tags, invalid UTF-8 sequences, and some other homegrown, MLSF-like hack, what would be your recommendation to them? -- Doug Ewell | Thornton, CO, USA http://ewellic.org | @DougEwell From nobody Thu May 15 20:00:37 2014 Return-Path: X-Original-To: ltru@ietfa.amsl.com Delivered-To: ltru@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF971A007E for ; Thu, 15 May 2014 20:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qN3yVR5hzYKG for ; Thu, 15 May 2014 20:00:33 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C75AF1A0032 for ; Thu, 15 May 2014 20:00:33 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id x3so3325707qcv.24 for ; Thu, 15 May 2014 20:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=4+Nd79hIYw40TUarXWvdOTvg9h6hFfEBLzOkHEE74Mc=; b=BnBXMWGQDNbIIhFng27jKKMuXZRUaxuxOhkd/UoHdeZjDUTpS4lIs3E58WbncrAxjV ej+jNLhrYnB8QE/K3RwJDCOsmtlTlgXJCrYGHGDvGQrSx4ygSUysSiJDMie8CDdqsqep 094PjfRIJLA9Y6rE1uO003fGWbmMA5iFqUpc6Ziubo5Mdv8o3Nza9UjeRT75w/MX2aeh 7XzOQZhAnHNSDng+jet9Bh8N27R2yTYEAfhwfwr7QRHmRP6Z3PdGffIdrkuDc/uMLLlz JSXQYd0Z0HhBzUKLbCh7lXFVHZmBWZ6iE4kQX9OFBZ1+LmSbfVljDHQZfsjmFa3RjnZW 3YgQ== X-Received: by 10.140.49.76 with SMTP id p70mr20131996qga.86.1400209226161; Thu, 15 May 2014 20:00:26 -0700 (PDT) MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.229.151.81 with HTTP; Thu, 15 May 2014 20:00:05 -0700 (PDT) In-Reply-To: <63CE3F1B0A474CD9B023A3D330BEED32@DougEwell> References: <20140515083955.665a7a7059d7ee80bb4d670165c8327d.b69c089194.wbe@email03.secureserver.net> <63CE3F1B0A474CD9B023A3D330BEED32@DougEwell> From: =?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?= Date: Thu, 15 May 2014 20:00:05 -0700 X-Google-Sender-Auth: US7v3tISTYPhoP4HlAmmQ03QIa0 Message-ID: To: Doug Ewell Content-Type: multipart/alternative; boundary=001a11370a3489654004f97b9dfb Archived-At: http://mailarchive.ietf.org/arch/msg/ltru/DaOfHujVRU8KVBrRfNZ6_pK-Iag Cc: LTRU Working Group , Dave Cridland Subject: Re: [Ltru] [apps-discuss] Fwd: Defining a CBOR tag for RFC 5646 Language Tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 03:00:35 -0000 --001a11370a3489654004f97b9dfb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, May 15, 2014 at 7:32 PM, Doug Ewell wrote: > And if Peter and Dave had decided that an out-of-band tagging model for > CBOR was simply unworkable (which they did not, thankfully), and they wer= e > left with a choice between Plane 14 tags, invalid UTF-8 sequences, and so= me > other homegrown, MLSF-like hack, what would be your recommendation to the= m? > =E2=80=8BI would say that they need to go back and look at out-of-band tagg= ing. CBOR already handles a variety of data formats and can handle sequences of variable length text and other items, so there is no need =E2=80=8Bto say w= hat's the best of a set of other choices, all of which are awful. Mark *=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94* --001a11370a3489654004f97b9dfb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, May 15, 2014 at 7:32 PM, Doug Ewell <doug@ewellic.org> wrote:

And = if Peter and Dave had decided that an out-of-band tagging model for CBOR wa= s simply unworkable (which they did not, thankfully), and they were left wi= th a choice between Plane 14 tags, invalid UTF-8 sequences, and some other = homegrown, MLSF-like hack, what would be your recommendation to them?

=E2=80=8BI would say that they n= eed to go back and look at out-of-band tagging.

CBOR already handles a variety of data formats and can ha= ndle sequences of variable length text and other items, so there is no need= =E2=80=8Bto say what's the best of a set of other choices, all of whic= h are awful.

Mark

<= div style=3D"margin:0px;background-color:transparent">

=E2=80=94 Il meglio = =C3=A8 l=E2=80=99inimico del bene =E2=80=94

--001a11370a3489654004f97b9dfb-- From nobody Fri May 16 02:18:23 2014 Return-Path: X-Original-To: ltru@ietfa.amsl.com Delivered-To: ltru@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8DE1A01C6 for ; Fri, 16 May 2014 02:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 eZBXNr7E7lfD for ; Fri, 16 May 2014 02:18:20 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id CABF91A01C5 for ; Fri, 16 May 2014 02:18:19 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 4970A32E49E; Fri, 16 May 2014 18:18:11 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 6177_f8e4_22b13d96_3816_427d_b833_dfa2ee16d931; Fri, 16 May 2014 18:18:10 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 73653C0312; Fri, 16 May 2014 18:18:10 +0900 (JST) Message-ID: <5375D7C5.3060609@it.aoyama.ac.jp> Date: Fri, 16 May 2014 18:17:57 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Doug Ewell , Dave Cridland References: <20140515083955.665a7a7059d7ee80bb4d670165c8327d.b69c089194.wbe@email03.secureserver.net> In-Reply-To: <20140515083955.665a7a7059d7ee80bb4d670165c8327d.b69c089194.wbe@email03.secureserver.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ltru/7wbjt4PftpkfgLPqvUZ6KAEQrog Cc: LTRU Working Group Subject: Re: [Ltru] [apps-discuss] Fwd: Defining a CBOR tag for RFC 5646 Language Tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 09:18:22 -0000 On 2014/05/16 00:39, Doug Ewell wrote: > Dave Cridland wrote: > >> Of course, an invalid-UTF-8 based proposal simply means that it's no >> longer UTF-8 per-se, and so needs itself to be tagged differently. But this is highly counter-productive. US computer and Internet technology was so successful among else because everything was ASCII. We are finally getting close to a place where (almost) everything is UTF-8. Some of us already in 1997 (or even earlier) knew that that was the direction to go. UTF-8 "variants" would have killed a lot of the advantages of moving towards UTF-8. >> Other than that, I don't see it's a bad idea from a technical >> standpoint. The use of the word "invalid" probably scares people, but >> I note that's really a shorthand for "not backwards compatible by >> existing UTF-8 processors". It was not such a bad idea on the level of "let's use a screw to hold these two pieces of metal together". I was a very bad idea because much of technological (prospect of) success is or has to be measured not by how many good pieces of technology you have (how many different sizes of screws), but how *few* of them you have. > The proposal from 1997 ("MLSF") did call it an extra layer on top of > UTF-8, and included lots of health warnings that it was not really > UTF-8. Only after quite a bit of pressure on the authors (including from me). See http://tools.ietf.org/rfcdiff?url2=draft-ietf-acap-mlsf-01.txt. > That didn't remove the danger, though, because it looked so much > like UTF-8. John's response about decoders was spot-on. It was an extremely ugly chameleon mixing character encoding with higher-level information, messing around with the structural cleanness and heuristic detectability of UTF-8, and inviting all kinds of other crazy cludges for other "UTF-8-but-not-quite" chimeras. >> Exactly the same caveats apply to Plane 14 tagging, mind, and >> moreover, we could invent our own - indeed, that's what we're doing by >> having these arrays of (tag, string) tuples. Plane 14 language tags are strictly within UTF-8 and also of course work with UTF-16. They are therefore quite a bit less bad than MLSF, but still bad enough. > As Mark knows, I never bought into the deprecation argument about how > evil Plane 14 tag characters are. Handling them correctly just isn't > that difficult. There are hundreds of ideas that look "not that difficult" to implement. But usually, everything turns out to be more difficult than estimated, and what's more important, the combinations of the different ideas turn out to be the killer. In some ways, plane 14 language tags were born dead. Putting them in plane 14 was an explicit decision that sent a clear message that there was no expectation that they would or should be used frequently. > For CBOR, you may be better off with the tag/string > tuples; the tags in that case are much easier to see and don't need to > be stripped from the string for display or comparison. But if this > "tagged text" model is too far out of step with the CBOR/JSON way of > thinking, Plane 14 is out there. As far as I understand, the tagged text model should work well, about as well as lang/xml:lang attributes for HTML and XML. Regards, Martin. From nobody Mon May 19 15:35:18 2014 Return-Path: X-Original-To: ltru@ietfa.amsl.com Delivered-To: ltru@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202621A0413; Mon, 19 May 2014 15:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.588 X-Spam-Level: X-Spam-Status: No, score=0.588 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 Hpn_f1eSWxjj; Mon, 19 May 2014 15:35:13 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937761A038B; Mon, 19 May 2014 15:35:13 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id q108so9846703qgd.33 for ; Mon, 19 May 2014 15:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-type:content-transfer-encoding:importance; bh=I1dJiZJQZGk4MlefvEoOG4+ge/Olxk1hOgbyAkUznxM=; b=xoBzU2n0oC2zApSIO4mf0h6uQKA0oMB6bdDvt2DjjxAhifUhzUvXxKhHNBMToZGO+z CudAw6QP+MbpUITG6F9p8kRL02fgW0oLZc+hgw21d82o724CSxvSf1Gz/JIt7xHebkE0 GHBB6TOBEazCGxrfst8CBJSYGWJF+0XNxzAA8o1awfDQIIHnW2YeKfzHSlEkthVtG5Al LkI9Fnv+UUsz63VlrH9aYHGJ7wf1o1EPJgwRbEbW8sTGBmDDl3ODcvdtb9PEPCmFFc+E Lshod0+3hT9hr4VxM6gDICqRuE1N5NDQNkMtP+8Z99IbO7N2FpWN0UFRiG7hS1ECEnMO ag9A== X-Received: by 10.224.55.83 with SMTP id t19mr52510487qag.42.1400538912891; Mon, 19 May 2014 15:35:12 -0700 (PDT) Received: from PeterPC (c-50-169-108-108.hsd1.ma.comcast.net. [50.169.108.108]) by mx.google.com with ESMTPSA id w4sm19886151qat.5.2014.05.19.15.35.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 15:35:12 -0700 (PDT) Message-ID: <2C9B140A7DFC42BEAE99AAA458EC9354@PeterPC> From: "Peter Occil" To: "Joe Hildebrand \(jhildebr\)" , "LTRU Working Group" , References: <18971982.1399873468367.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <9BE5D3F7FAEE4CAB8FD3326ED8F1ED75@PeterPC> <0C126A09-1909-449E-B0B4-9F41677710E2@tzi.org> <92A56D2F207E4A9893AEDBC13336FA28@PeterPC> <15955C4E122344DDBBAA53E803A8F08E@PeterPC> In-Reply-To: Date: Mon, 19 May 2014 18:35:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-Antivirus: avast! (VPS 140519-1, 05/19/2014), Outbound message X-Antivirus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/ltru/kHVgkTfZ9RZsvxBBByM5msthgUE Subject: Re: [Ltru] [apps-discuss] Defining a CBOR tag for RFC 5646Language Tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 22:35:16 -0000 As I recall, that is similar to the approach taken by JSON-LD when mapping the same text in different languages (there it's called a "language map"). However, one problem that I see is that this requires case-insensitive comparison of keys: if a decoder encounters a language map with two keys that differ only in case (for example, "en" and "EN"), which one should it use? The one defined earlier or later? While there are already CBOR tags in the registry that depend on such ordering (such as string references and shared references), I believe that defining further tags that depend on this kind of ordering of values in the CBOR stream should be avoided as much as possible. Another approach may be to forbid such an ambiguous language map or ignore ambiguous keys, but I don't know which is the best approach. Issues like those should be dealt with in another tag proposal; I don't mind if tag 38 (this proposal) is changed to use language maps, but additional discussion would have to be necessary. Until then, the simple language-tagged string is enough. --Peter -----Original Message----- From: Joe Hildebrand (jhildebr) Sent: Monday, May 19, 2014 3:25 PM To: Peter Occil ; LTRU Working Group ; apps-discuss@ietf.org Subject: Re: [apps-discuss] [Ltru] Defining a CBOR tag for RFC 5646Language Tags Hm. I was thinking: { "en": "Hello", "fr": "Bonjour" } for the case of alternatives. The wire size between [ "en": "Hello" ] and { "en": "Hello" } is zero; perhaps we could kill two birds with one stone? On 5/15/14, 10:35 AM, "Peter Occil" wrote: >I have updated my specification on language-tagged strings. > >http://peteroupc.github.io/CBOR/langtags.html > >The two things new are: > >- The "NOTE" section. >- The sentence "Both the language tag and the arbitrary string can >optionally be annotated with CBOR tags." > >--Peter > >_______________________________________________ >apps-discuss mailing list >apps-discuss@ietf.org >https://www.ietf.org/mailman/listinfo/apps-discuss > -- Joe Hildebrand From nobody Mon May 19 15:47:46 2014 Return-Path: X-Original-To: ltru@ietfa.amsl.com Delivered-To: ltru@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A18B1A0435; Mon, 19 May 2014 15:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, 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 aK13OYzUsN0L; Mon, 19 May 2014 15:47:39 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBBF81A015F; Mon, 19 May 2014 15:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s4JMlT4L002515; Tue, 20 May 2014 00:47:29 +0200 (CEST) Received: from [192.168.217.145] (p54893C54.dip0.t-ipconnect.de [84.137.60.84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2F94513E9; Tue, 20 May 2014 00:47:28 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann X-Priority: 3 In-Reply-To: <2C9B140A7DFC42BEAE99AAA458EC9354@PeterPC> Date: Tue, 20 May 2014 00:47:26 +0200 X-Mao-Original-Outgoing-Id: 422232446.806613-e6b2fbfc81d6ab6dcf6422d966010862 Content-Transfer-Encoding: quoted-printable Message-Id: References: <18971982.1399873468367.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <9BE5D3F7FAEE4CAB8FD3326ED8F1ED75@PeterPC> <0C126A09-1909-449E-B0B4-9F41677710E2@tzi.org> <92A56D2F207E4A9893AEDBC13336FA28@PeterPC> <15955C4E122344DDBBAA53E803A8F08E@PeterPC> <2C9B140A7DFC42BEAE99AAA458EC9354@PeterPC> To: Peter Occil X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ltru/h7HaN2SdHaEOdNwT269AOn10BGs Cc: LTRU Working Group , apps-discuss@ietf.org, "Joe Hildebrand \(jhildebr\)" Subject: Re: [Ltru] [apps-discuss] Defining a CBOR tag for RFC 5646Language Tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 22:47:41 -0000 On 20 May 2014, at 00:35, Peter Occil wrote: > However, one problem that I see is that this requires case-insensitive = comparison of > keys: if a decoder encounters a language map with two keys that differ = only in case (for example, "en" and "EN"), which one should it use? =20 We generally handle problematic cases like this well by simply = disallowing their use by the sender. It then matters less how a receiver handles incoming improper streams. Maybe this is another reason to require case-mapping to lower-case. More aggressively, maybe combine this with at least a =93SHOULD=94 for = canonical form as in section 4.5 of RFC 5646? Gr=FC=DFe, Carsten From nobody Mon May 19 15:57:53 2014 Return-Path: X-Original-To: ltru@ietfa.amsl.com Delivered-To: ltru@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FA01A0444; Mon, 19 May 2014 15:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.604 X-Spam-Level: ** X-Spam-Status: No, score=2.604 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, TVD_FINGER_02=1.215] 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 1jjrNvWnwTnD; Mon, 19 May 2014 15:57:49 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79FCA1A0442; Mon, 19 May 2014 15:57:49 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id q107so10127799qgd.1 for ; Mon, 19 May 2014 15:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=5zt3FXm9NcSG6PWVE1xPOzocM0h81ofrUDyJKPh7WDU=; b=oDHHkrdK9zOl/AjZjQxfYUnfWISkvY7n9dQWzUK0yRAJ/EjFOzm2u7OP2FZB4oUSv2 +b+ZR9rmbgClZpT8gOaUSFDWr7RHXhPJmyFgjawEnXRmB7jMqBeVSwPV9FzZbf3/RTC1 H9THiOGO2iCeEarwgxS7qhxbsT1TTr6Dg+xINTs/t2nOGFLWfisttUPEbNlOaBijAj3C r3yCZ2FOHQAQDCXUhu+U/hgOy6EC66mcDT8ALYDb9nnMdk0A5WJX6LJnMXJ/Onyq08fH T0gWYPab2LG0TAL12sZi4b3PPRr6O9HlL/5n/0dD+CV3Z32DcguZV1DdcNrj4sbAr81w HMxg== X-Received: by 10.224.29.76 with SMTP id p12mr10252133qac.84.1400540268729; Mon, 19 May 2014 15:57:48 -0700 (PDT) Received: from PeterPC (c-50-169-108-108.hsd1.ma.comcast.net. [50.169.108.108]) by mx.google.com with ESMTPSA id x1sm29709121qal.36.2014.05.19.15.57.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 15:57:48 -0700 (PDT) Message-ID: <4E728C7DF5A84CF0A21189FBF29381C4@PeterPC> From: "Peter Occil" To: "Carsten Bormann" References: <18971982.1399873468367.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <9BE5D3F7FAEE4CAB8FD3326ED8F1ED75@PeterPC> <0C126A09-1909-449E-B0B4-9F41677710E2@tzi.org> <92A56D2F207E4A9893AEDBC13336FA28@PeterPC> <15955C4E122344DDBBAA53E803A8F08E@PeterPC> <2C9B140A7DFC42BEAE99AAA458EC9354@PeterPC> In-Reply-To: Date: Mon, 19 May 2014 18:57:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-Antivirus: avast! (VPS 140519-1, 05/19/2014), Outbound message X-Antivirus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/ltru/sptivV6GFxZ8JFPIKHfdRfnfvWM Cc: LTRU Working Group , apps-discuss@ietf.org, "Joe Hildebrand \(jhildebr\)" Subject: Re: [Ltru] [apps-discuss] Defining a CBOR tag for RFC 5646Language Tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 22:57:51 -0000 A good idea. But my point still stands that a language map should be in a different tag proposal, if possible. There may still be other issues with changing this proposal from language-tagged strings to language-tagged maps that haven't been dealt with yet, but again, I don't mind if tag 38 eventually does take that course. --Peter -----Original Message----- From: Carsten Bormann Sent: Monday, May 19, 2014 6:47 PM To: Peter Occil Cc: Joe Hildebrand (jhildebr) ; LTRU Working Group ; apps-discuss@ietf.org Subject: Re: [apps-discuss] [Ltru] Defining a CBOR tag for RFC 5646Language Tags On 20 May 2014, at 00:35, Peter Occil wrote: > However, one problem that I see is that this requires case-insensitive > comparison of > keys: if a decoder encounters a language map with two keys that differ > only in case (for example, "en" and "EN"), which one should it use? We generally handle problematic cases like this well by simply disallowing their use by the sender. It then matters less how a receiver handles incoming improper streams. Maybe this is another reason to require case-mapping to lower-case. More aggressively, maybe combine this with at least a �SHOULD� for canonical form as in section 4.5 of RFC 5646? Gr��e, Carsten From nobody Mon May 19 16:27:28 2014 Return-Path: X-Original-To: ltru@ietfa.amsl.com Delivered-To: ltru@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B112F1A03CE; Mon, 19 May 2014 12:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 RlloyPNHdP7T; Mon, 19 May 2014 12:25:58 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1931A03CD; Mon, 19 May 2014 12:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1064; q=dns/txt; s=iport; t=1400527558; x=1401737158; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=IbelAiHVXAcThumVFUm1nOpwNYeas8uKVC1bXOwiC4U=; b=Gj2M1R3Bo/YsjaS7RcROZGUeiiMQAKwwBms6ntP6n2bFNedMVM38SqJh COm74F3H9YBnVxvRzGGLUlvLfSzQBAFu7dEsu+UpbVLD4vOrPNFtxKy3J M1HkD0eHQtsBv5YGxZ1qQtCJfYeQUVUVpLHZ+mLgaWKjOkahY2q9SrU+i M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4FABxaelOtJA2N/2dsb2JhbABZgwZRWIJppmkBAQEBAQeSboc9ARmBABZ0giYBAQQBAQEgETobAgEIDgwCJgICAh8GCxUQAgQBEogtAxENrW+eEA2GLxeBKoQrhW15gWI6gnWBSwEDl2aBdIE9i3GFbIM3bYFD X-IronPort-AV: E=Sophos;i="4.98,868,1392163200"; d="scan'208";a="323088128" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP; 19 May 2014 19:25:58 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4JJPvJd032211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 May 2014 19:25:57 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 19 May 2014 14:25:57 -0500 From: "Joe Hildebrand (jhildebr)" To: Peter Occil , LTRU Working Group , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] [Ltru] Defining a CBOR tag for RFC 5646Language Tags Thread-Index: AQHPcFu5j1m6+8TePkCSdIp/gGJKJ5tIPtQA Date: Mon, 19 May 2014 19:25:56 +0000 Message-ID: References: <18971982.1399873468367.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <9BE5D3F7FAEE4CAB8FD3326ED8F1ED75@PeterPC> <0C126A09-1909-449E-B0B4-9F41677710E2@tzi.org> <92A56D2F207E4A9893AEDBC13336FA28@PeterPC> <15955C4E122344DDBBAA53E803A8F08E@PeterPC> In-Reply-To: <15955C4E122344DDBBAA53E803A8F08E@PeterPC> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ltru/m8BW9tS3AMVhjI7bYc9VvuCiSgA X-Mailman-Approved-At: Mon, 19 May 2014 16:27:26 -0700 Subject: Re: [Ltru] [apps-discuss] Defining a CBOR tag for RFC 5646Language Tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 19:26:01 -0000 SG0uICBJIHdhcyB0aGlua2luZzoNCg0KeyAiZW4iOiAiSGVsbG8iLCAiZnIiOiAiQm9uam91ciIg fQ0KDQpmb3IgdGhlIGNhc2Ugb2YgYWx0ZXJuYXRpdmVzLiAgVGhlIHdpcmUgc2l6ZSBiZXR3ZWVu DQoNClsgImVuIjogIkhlbGxvIiBdIGFuZCB7ICJlbiI6ICJIZWxsbyIgfQ0KDQppcyB6ZXJvOyBw ZXJoYXBzIHdlIGNvdWxkIGtpbGwgdHdvIGJpcmRzIHdpdGggb25lIHN0b25lPw0KDQpPbiA1LzE1 LzE0LCAxMDozNSBBTSwgIlBldGVyIE9jY2lsIiA8cG9jY2lsMTRAZ21haWwuY29tPiB3cm90ZToN Cg0KPkkgaGF2ZSB1cGRhdGVkIG15IHNwZWNpZmljYXRpb24gb24gbGFuZ3VhZ2UtdGFnZ2VkIHN0 cmluZ3MuDQo+DQo+aHR0cDovL3BldGVyb3VwYy5naXRodWIuaW8vQ0JPUi9sYW5ndGFncy5odG1s DQo+DQo+VGhlIHR3byB0aGluZ3MgbmV3IGFyZToNCj4NCj4tIFRoZSAiTk9URSIgc2VjdGlvbi4N Cj4tIFRoZSBzZW50ZW5jZSAiQm90aCB0aGUgbGFuZ3VhZ2UgdGFnIGFuZCB0aGUgYXJiaXRyYXJ5 IHN0cmluZyBjYW4NCj5vcHRpb25hbGx5IGJlIGFubm90YXRlZCB3aXRoIENCT1IgdGFncy4iDQo+ DQo+LS1QZXRlciANCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPmFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCj5hcHBzLWRpc2N1c3NAaWV0Zi5v cmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vzcw0K Pg0KDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0KDQoNCg== From nobody Mon May 26 12:59:38 2014 Return-Path: X-Original-To: ltru@ietfa.amsl.com Delivered-To: ltru@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBD11A024D; Mon, 26 May 2014 12:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vyj79w7S3at9; Mon, 26 May 2014 12:59:33 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83FE01A023D; Mon, 26 May 2014 12:59:33 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e16so12665310qcx.27 for ; Mon, 26 May 2014 12:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=WciecxbOY2PcnNh0CVaSPcB6NpxS2Zb/j68dqarMPSI=; b=p2s05y4VMPN+pPZdbh/yEwMRT37sLJufpX/3cotRtQ320YyDnjs7pahRj3atfdfpUx XQL/zMETanyOp1YjQuvZD8EHqO2nFnwfl+gzSVpP47rLZoJKdStWDIrb7b6JkQEi7VB3 sO3SqksRu92eFVmgOI/YBdecNIkIOZsNby2GNdBQ3wg5U3CAbr4AL14lgUQI51CcyzJz 9U19xJ39Ihg7aONzfk7oPt1n31vWyXNrYmiJobDUSwtT1G26YZUn9rJsTDJ4alar8CVa HHLFfnUbbW1wpWkIuo6LM61+o4uUL4wmviNIDrtfvVyl/IuZfBR+3269vpjOy0dI4d7R tNng== X-Received: by 10.224.125.74 with SMTP id x10mr35539751qar.99.1401134370111; Mon, 26 May 2014 12:59:30 -0700 (PDT) Received: from PeterPC (c-50-169-108-108.hsd1.ma.comcast.net. [50.169.108.108]) by mx.google.com with ESMTPSA id a13sm8504790qgf.38.2014.05.26.12.59.29 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 26 May 2014 12:59:29 -0700 (PDT) Message-ID: <276CF85BB22348268BB456984A397BE7@PeterPC> From: "Peter Occil" To: "LTRU Working Group" , References: <18971982.1399873468367.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> <9BE5D3F7FAEE4CAB8FD3326ED8F1ED75@PeterPC> <0C126A09-1909-449E-B0B4-9F41677710E2@tzi.org> <92A56D2F207E4A9893AEDBC13336FA28@PeterPC> <15955C4E122344DDBBAA53E803A8F08E@PeterPC> In-Reply-To: <15955C4E122344DDBBAA53E803A8F08E@PeterPC> Date: Mon, 26 May 2014 15:59:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-Antivirus: avast! (VPS 140526-3, 05/26/2014), Outbound message X-Antivirus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/ltru/dy_-Z1I9aPAaVYc63Zpw53KIQmQ Cc: Carsten Bormann Subject: Re: [Ltru] [apps-discuss] Defining a CBOR tag for RFC 5646Language Tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 19:59:34 -0000 Is there any more discussion on this document? I feel like this CBOR tag is ready to be registered. --Peter -----Original Message----- From: Peter Occil Sent: Thursday, May 15, 2014 12:35 PM To: LTRU Working Group ; apps-discuss@ietf.org Cc: Carsten Bormann Subject: Re: [apps-discuss] [Ltru] Defining a CBOR tag for RFC 5646Language Tags I have updated my specification on language-tagged strings. http://peteroupc.github.io/CBOR/langtags.html The two things new are: - The "NOTE" section. - The sentence "Both the language tag and the arbitrary string can optionally be annotated with CBOR tags." --Peter From nobody Tue May 27 09:34:12 2014 Return-Path: X-Original-To: ltru@ietfa.amsl.com Delivered-To: ltru@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3A21A01A9 for ; Tue, 27 May 2014 09:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKsYrjXsbEBI for ; Tue, 27 May 2014 09:34:09 -0700 (PDT) Received: from p3plwbeout03-05.prod.phx3.secureserver.net (p3plsmtp03-05-2.prod.phx3.secureserver.net [72.167.218.217]) by ietfa.amsl.com (Postfix) with ESMTP id 03EAD1A0462 for ; Tue, 27 May 2014 09:34:08 -0700 (PDT) Received: from localhost ([72.167.218.244]) by p3plwbeout03-05.prod.phx3.secureserver.net with bizsmtp id 74Zz1o0015GyNsw014ZzMP; Tue, 27 May 2014 09:34:02 -0700 X-SID: 74Zz1o0015GyNsw01 Received: (qmail 4659 invoked by uid 99); 27 May 2014 16:33:59 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 208.51.143.189 User-Agent: Workspace Webmail 5.7.0 Message-Id: <20140527093358.665a7a7059d7ee80bb4d670165c8327d.f8941d8c46.wbe@email03.secureserver.net> From: "Doug Ewell" To: poccil14@gmail.com, ltru@ietf.org Date: Tue, 27 May 2014 09:33:58 -0700 Mime-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ltru/sm9vknOgrEec3_d7flccFppfTg0 Subject: Re: [Ltru] [apps-discuss] Defining a CBOR tag for RFC 5646 Language Tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 16:34:11 -0000 "Peter Occil" wrote:=0A=0A> Is there any more d= iscussion on this document? I feel like this CBOR=0A> tag is ready to be re= gistered.=0A=0ARFC 5646, Section 2.1.1 has a perfectly good description of = how to=0Ahandle tags that differ only in case, like "en" and "EN": they are= =0Acompletely equivalent in all respects. I'm not sure why the CBOR tag=0Ac= ouldn't just use this existing rule instead of defining its own rules=0Aon = case sensitivity and case mapping, but that's up to the CBOR folks.=0A=0A--= =0ADoug Ewell | Thornton, CO, USA=0Ahttp://ewellic.org | @DougEwell=0A From nobody Tue May 27 16:19:26 2014 Return-Path: X-Original-To: ltru@ietfa.amsl.com Delivered-To: ltru@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE851A0671 for ; Tue, 27 May 2014 16:19:25 -0700 (PDT) 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 6QpD9jnATNLS for ; Tue, 27 May 2014 16:19:24 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 985A51A02AF for ; Tue, 27 May 2014 16:19:24 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id lx4so9268286iec.5 for ; Tue, 27 May 2014 16:19:21 -0700 (PDT) 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=T3hjWQ00QJQqVr0IM6nN75O8zge+XUIyxLyvuZ0u8Ns=; b=bj07K4ZScvOj/aDkX5WP1q3Mo1rlJ65pKmZA7lVEyFSLi4LkHTdnx7lDqkguRlOyPv iSPSsqb8YtyNqKyukjWzCoZCCaJwrn5XHF7NSwMASajnJ9DosaBJewukCFKPWE6e7hus HcNsMrlDz1a+5vgHAmml0m64cxaTH6/hoN1K4vMeFjCjOJvlNAQJ0F5cf+NnZzN97Wf2 O6dzgYUz+Ue+7Y3t1vb1/HJHrfB5GarzxrxHVsclTwCnsG40ccmkF9GvzDDHpVPQaXzN rG7sVVEQJGLyokytwWjAxQuOPDEktNk67bDx6a/OV6wW+yAwsYbEBO2zF8rSIUw2/Ey0 chpA== MIME-Version: 1.0 X-Received: by 10.42.50.68 with SMTP id z4mr6773264icf.70.1401232761117; Tue, 27 May 2014 16:19:21 -0700 (PDT) Received: by 10.64.13.134 with HTTP; Tue, 27 May 2014 16:19:21 -0700 (PDT) Received: by 10.64.13.134 with HTTP; Tue, 27 May 2014 16:19:21 -0700 (PDT) In-Reply-To: <20140527093358.665a7a7059d7ee80bb4d670165c8327d.f8941d8c46.wbe@email03.secureserver.net> References: <20140527093358.665a7a7059d7ee80bb4d670165c8327d.f8941d8c46.wbe@email03.secureserver.net> Date: Tue, 27 May 2014 19:19:21 -0400 Message-ID: From: Peter Occil To: Doug Ewell Content-Type: multipart/alternative; boundary=90e6ba212499f9642704fa69ec30 Archived-At: http://mailarchive.ietf.org/arch/msg/ltru/rO5kdbuTjCxglosfRNLbIYFnQKE Cc: LTRU Working Group Subject: Re: [Ltru] [apps-discuss] Defining a CBOR tag for RFC 5646 Language Tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 23:19:25 -0000 --90e6ba212499f9642704fa69ec30 Content-Type: text/plain; charset=UTF-8 Your comment is addressed. I have made that part of the document a note and the document is now updated. --Peter On May 27, 2014 12:34 PM, "Doug Ewell" wrote: > "Peter Occil" wrote: > > > Is there any more discussion on this document? I feel like this CBOR > > tag is ready to be registered. > > RFC 5646, Section 2.1.1 has a perfectly good description of how to > handle tags that differ only in case, like "en" and "EN": they are > completely equivalent in all respects. I'm not sure why the CBOR tag > couldn't just use this existing rule instead of defining its own rules > on case sensitivity and case mapping, but that's up to the CBOR folks. > > -- > Doug Ewell | Thornton, CO, USA > http://ewellic.org | @DougEwell > > --90e6ba212499f9642704fa69ec30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Your comment is addressed.=C2=A0 I have made that part of th= e document a note and the document is now updated.

--Peter

On May 27, 2014 12:34 PM, "Doug Ewell"= <doug@ewellic.org> wrote:

"Peter Occil" <poccil14 at gmail dot com> wrote:

> Is there any more discussion on this document? I feel like this CBOR > tag is ready to be registered.

RFC 5646, Section 2.1.1 has a perfectly good description of how to
handle tags that differ only in case, like "en" and "EN"= ;: they are
completely equivalent in all respects. I'm not sure why the CBOR tag couldn't just use this existing rule instead of defining its own rules<= br> on case sensitivity and case mapping, but that's up to the CBOR folks.<= br>
--
Doug Ewell | Thornton, CO, USA
http://ewellic.org | @= DougEwell

--90e6ba212499f9642704fa69ec30-- From nobody Tue May 27 19:37:24 2014 Return-Path: X-Original-To: ltru@ietfa.amsl.com Delivered-To: ltru@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC8A1A02D9 for ; Tue, 27 May 2014 19:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.951 X-Spam-Level: X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 G-F2zaG1gZMy for ; Tue, 27 May 2014 19:37:20 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6CA31A06BC for ; Tue, 27 May 2014 19:37:08 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id q107so16058633qgd.10 for ; Tue, 27 May 2014 19:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:importance; bh=oYWMgdFxZT2uXw0oRr5jhjKM4BzGPVEWDM+3bsbO/hM=; b=qVd19+OLMAsPQ7kyYVz4omJz7hnWQF3xV00qthcWHcuiJf/tL6FLzjDyWwFGcreE3e iwUD2JRJworrHI9D5cuIbQaKUlMQ5Mxuop7jDAV6ggSdY/gz3xUfnpqdw0h7OKTOPd/G qKz1Yc9joeEGj1xT4WACSNMsa2RqCnHA7jTeemk1yZovOKf5Llj7bGkJO540+WYNsUPD xC6EDm4zoeGrlsyhzTYlpoJiW3f2aNZCjOt65tNaINig3oiZQGjJ4WI27yLKwRDg3q/o XX3Me5PFFDljTjAShoH2J78/ihfyTE3YGWFmSMA61pKqI1I2ovqV8TQIuNQdu5Ewm1NF /ifg== X-Received: by 10.224.115.139 with SMTP id i11mr26912188qaq.50.1401244625035; Tue, 27 May 2014 19:37:05 -0700 (PDT) Received: from PeterPC (c-50-169-108-108.hsd1.ma.comcast.net. [50.169.108.108]) by mx.google.com with ESMTPSA id l10sm15468215qae.41.2014.05.27.19.37.04 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 27 May 2014 19:37:04 -0700 (PDT) Message-ID: From: "Peter Occil" To: "Doug Ewell" References: <20140527093358.665a7a7059d7ee80bb4d670165c8327d.f8941d8c46.wbe@email03.secureserver.net> In-Reply-To: Date: Tue, 27 May 2014 22:36:48 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0069_01CF79FC.2594C520" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-Antivirus: avast! (VPS 140527-1, 05/27/2014), Outbound message X-Antivirus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/ltru/jVtNa4jPJQ4uEAx3yZCg6qx1xro Cc: LTRU Working Group Subject: Re: [Ltru] [apps-discuss] Defining a CBOR tag for RFC 5646 Language Tags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 02:37:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0069_01CF79FC.2594C520 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99ve now updated the document by editing the note further to = address Doug=E2=80=99s concerns. --Peter From: Peter Occil=20 Sent: Tuesday, May 27, 2014 7:19 PM To: Doug Ewell=20 Cc: LTRU Working Group=20 Subject: Re: [Ltru] [apps-discuss] Defining a CBOR tag for RFC 5646 = Language Tags Your comment is addressed. I have made that part of the document a note = and the document is now updated.=20 --Peter On May 27, 2014 12:34 PM, "Doug Ewell" wrote: "Peter Occil" wrote: > Is there any more discussion on this document? I feel like this CBOR > tag is ready to be registered. RFC 5646, Section 2.1.1 has a perfectly good description of how to handle tags that differ only in case, like "en" and "EN": they are completely equivalent in all respects. I'm not sure why the CBOR tag couldn't just use this existing rule instead of defining its own rules on case sensitivity and case mapping, but that's up to the CBOR folks. -- Doug Ewell | Thornton, CO, USA http://ewellic.org | @DougEwell ------=_NextPart_000_0069_01CF79FC.2594C520 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I=E2=80=99ve now updated the document by editing the note further = to address Doug=E2=80=99s=20 concerns.

--Peter

From: Peter Occil

Sent: Tuesday, May 27, 2014 7:19 PM

To: Doug=20 Ewell

Cc: LTRU Working=20 Group

Subject: Re: [Ltru] [apps-discuss] Defining a CBOR tag for = RFC 5646=20 Language Tags

Your comment is addressed. I have made that part of = the=20 document a note and the document is now updated.

--Peter

On May 27, 2014 12:34 PM, "Doug Ewell" <doug@ewellic.org> wrote:

"Peter=20 Occil" <poccil14 at gmail dot com> wrote:

> Is there = any more=20 discussion on this document? I feel like this CBOR
> tag is = ready to be=20 registered.

RFC 5646, Section 2.1.1 has a perfectly good = description of=20 how to
handle tags that differ only in case, like "en" and "EN": = they=20 are
completely equivalent in all respects. I'm not sure why the = CBOR=20 tag
couldn't just use this existing rule instead of defining its = own=20 rules
on case sensitivity and case mapping, but that's up to the = CBOR=20 folks.

--
Doug Ewell | Thornton, CO, USA
http://ewellic.org |=20 @DougEwell