Re: [dtn] working group last call on draft-ietf-dtn-bpbis

Carsten Bormann <cabo@tzi.org> Wed, 15 March 2017 22:47 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6671A129C4C for <dtn@ietfa.amsl.com>; Wed, 15 Mar 2017 15:47:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 SxuSm140Vfpn for <dtn@ietfa.amsl.com>; Wed, 15 Mar 2017 15:47:49 -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 E5B04129C47 for <dtn@ietf.org>; Wed, 15 Mar 2017 15:47:48 -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 v2FMliNf017362; Wed, 15 Mar 2017 23:47:44 +0100 (CET)
Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (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 3vk6FC75GWzDJ3J; Wed, 15 Mar 2017 23:47:43 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <b573e87b-e62b-56b6-7b89-6bcbde86dd82@cs.tcd.ie>
Date: Wed, 15 Mar 2017 23:47:43 +0100
Cc: dtn <dtn@ietf.org>
X-Mao-Original-Outgoing-Id: 511310863.156259-d3a894dbfc462c021e971f3ecaba8379
Content-Transfer-Encoding: quoted-printable
Message-Id: <56D2A818-8EA5-4F51-AED4-2E7E27CC7538@tzi.org>
References: <44B4919D-4283-4FDD-91E5-1EE5288D50AC@viagenie.ca> <b573e87b-e62b-56b6-7b89-6bcbde86dd82@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/3ezlznzPy-U4ZFLI9tqi8j7pTFc>
Subject: Re: [dtn] working group last call on draft-ietf-dtn-bpbis
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Mar 2017 22:47:51 -0000

On 24 Jan 2017, at 04:33, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 
> 
> - 4.1.5.1: RFC3986 is the correct reference here, so the spec
> text is correct as-is. It may however be worth taking a look at
> the whatwg web page that has sometimes claimed to supercede
> 3986 for the browser-related things in which whatwg have an
> interest.  That's just in case there're some useful error
> handling considerations on the whatwg web page, (on the day you
> look at it;-). It's also the case that since BP EIDs are URIs,
> it's possible that strings that comply with today's or
> yesterday's whatwg web page may end up in the BP, so it'd be
> good to know if any of those (that are not valid according to
> 3986) might cause a problem with the CBOR encoding.

Following this WG only with one eye:

Has there been any progress on this issue?

Will the IETF deprecate RFC 3986 and point to the WHATWG web page instead?

Do we know about any specific issues with the use of WHATWG URLs as URIs (except that the web page might change at any time)?

As far as I can see from the CDDL, you have insured yourself against any trouble here by representing the scheme-specific part as a byte string — a text string would be a bit more natural, but then if WHATWG decides their WHATWG URLs are no longer UTF-8 strings that might break.

(While I have your attention, I agree with the previous comment that the CRC should be a byte string, not a uint of possibly variable representation length.)

Grüße, Carsten