Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-03.txt

"Patrik Fältström " <paf@frobbit.se> Fri, 21 December 2018 21:31 UTC

Return-Path: <paf@frobbit.se>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3D3130E95 for <dnsop@ietfa.amsl.com>; Fri, 21 Dec 2018 13:31:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.722
X-Spam-Level:
X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=frobbit.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-tERSXcErAm for <dnsop@ietfa.amsl.com>; Fri, 21 Dec 2018 13:31:52 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6D52130E74 for <dnsop@ietf.org>; Fri, 21 Dec 2018 13:31:51 -0800 (PST)
Received: from [192.165.72.241] (unknown [IPv6:2a02:80:3ffc:0:310e:953c:915a:665b]) by mail.frobbit.se (Postfix) with ESMTPSA id BAEA1276E2; Fri, 21 Dec 2018 22:31:48 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1545427908; bh=+7oCjAjDm8LIt/VdSvSDFTMhPuZPCAMajSY0NpfDQdQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cQmPUfcfbDsf3lKr1SsiY9OOQe/pM/tCQo9JHpARSuK7b13V7dOWlKS/IClPPPBXz XGccJZ48KEkY9qv2y6T9JAyie1lfU/qn4kT6YROjBlcVwJPgVE5aVSeTpz8L8OobgV yXutImrnRVqInR6yBBet3Bs2SiMGS781D2xLE4/0=
From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" <paf@frobbit.se>
To: "Warren Kumari" <warren@kumari.net>
Cc: "Wes Hardaker" <wjhns1@hardakers.net>, dnsop <dnsop@ietf.org>, "Jared Mauch" <jared@puck.nether.net>
Date: Fri, 21 Dec 2018 22:31:46 +0100
X-Mailer: MailMate (1.12.3r5579)
Message-ID: <FA097DC4-0611-4D05-BD41-4B2A491C0EB0@frobbit.se>
In-Reply-To: <CAHw9_i+PA8sACct_eC8XrT0tk21yWWDCzsCj4dU_fJp4XnipTA@mail.gmail.com>
References: <154534677023.19023.8195828695262063685@ietfa.amsl.com> <yblwoo3bxah.fsf@w7.hardakers.net> <48B3C12B-DE2A-4008-8E4E-D1C508C762BF@puck.nether.net> <ybl5zvmhin7.fsf@w7.hardakers.net> <CAHw9_i+PA8sACct_eC8XrT0tk21yWWDCzsCj4dU_fJp4XnipTA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_139362AC-85AA-4795-962D-AC6DBA7C165E_="; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/096_jz0fEdvYGzKVBo5_veptZAU>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-03.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Dec 2018 21:31:53 -0000

On 21 Dec 2018, at 21:28, Warren Kumari wrote:

> On Fri, Dec 21, 2018 at 12:52 PM Wes Hardaker <[wjhns1@hardakers.net](<mailto:wjhns1@hardakers.net>)> wrote:
>
>> Jared Mauch <[jared@puck.nether.net](<mailto:jared@puck.nether.net>)> writes:
>>
>>  > We went through some of this in IDR about routing protocols and how to leave
>>  > a partner device a message.  UTF-8 is the supported method.  7-bit ASCII lacks
>>  > language support.
>>
>>  That's a fair point.  I'd be happy with a change to it. 
>
> +1. Wes and I had a chat about this before specifying ASCII - he was all for specifying UTF-8, I suggested ASCII because it is the "standard" in DNS, and I was arguing for simplicity.

RFC2130, updated by RFC6055.

Be careful though as UTF-8 is only an encoding. Matching or comparing strings in UTF-8 is not something that should be done without a bunch of extra rules. See IDN.

But for "display strings", perfect!

UTF-8 please!

   Patrik