IETF Logo Mail Archive

Re: [netmod] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt

Carsten Bormann <cabo@tzi.org> Fri, 14 September 2018 11:14 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820F9130E36 for <netmod@ietfa.amsl.com>; Fri, 14 Sep 2018 04:14:38 -0700 (PDT)
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=unavailable autolearn_force=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 aPaA3frBTS2U for <netmod@ietfa.amsl.com>; Fri, 14 Sep 2018 04:14:37 -0700 (PDT)
Received: from mailhost.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 3E35B130E35 for <netmod@ietf.org>; Fri, 14 Sep 2018 04:14:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w8EBESPQ016555; Fri, 14 Sep 2018 13:14:28 +0200 (CEST)
Received: from [192.168.217.114] (p54A6C24D.dip0.t-ipconnect.de [84.166.194.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42BXwN2JCZzDWdb; Fri, 14 Sep 2018 13:14:28 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <becad6b4-16f6-1d42-cdee-5fcf487b7d6e@cisco.com>
Date: Fri, 14 Sep 2018 13:14:27 +0200
Cc: Joel Jaeggli <joelja@bogus.com>, netmod@ietf.org
X-Mao-Original-Outgoing-Id: 558616465.939656-4f1c88a6deb317e8ab49f9f22c0f6367
Content-Transfer-Encoding: quoted-printable
Message-Id: <C0044BB4-1C2A-47AD-BE27-5A1697112B44@tzi.org>
References: <153617788181.19783.8030234113753073864.idtracker@ietfa.amsl.com> <5404BB62-C21E-4A70-AABC-6FEF1FC5C44F@juniper.net> <072a01d44771$0da216b0$28e64410$@olddog.co.uk> <8e62fa6d-b4a9-a6e3-b13f-145d2e50d208@cisco.com> <5ED5E487-E172-482B-ADB2-CD52A1EBCA14@bogus.com> <becad6b4-16f6-1d42-cdee-5fcf487b7d6e@cisco.com>
To: Robert Wilton <rwilton=40cisco.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Jv1clXsiIetwG7zx3iJxcvWS8sI>
Subject: Re: [netmod] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Sep 2018 11:14:39 -0000

On Sep 14, 2018, at 13:05, Robert Wilton <rwilton=40cisco.com@dmarc.ietf.org> wrote:
> 
> If all input files that we might ever want to fold and include in an RFC are guaranteed to never contain tabs then I agree with the position that they can just be rejected. 

Yep.

> But if there is some future file format that we want to fold that might contain tabs, then I wonder whether it would not be more robust to look at whether they could be handled in some way.

VT characters (colloquially tabs) should not be significant in any file format designed in the last couple of decades (i.e., they should be replaceable by spaces).  If they (or any other characters not representable in RFCs) are, or preserving byte wise identity is important, follow the lead of RFC 6716 and base64-encode.

Grüße, Carsten

v2.23.0 | Report a Bug | By Email