Re: Last Call: <draft-nottingham-rfc5988bis-05.txt> (Web Linking) to Proposed Standard

Carsten Bormann <cabo@tzi.org> Tue, 02 May 2017 19:21 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD80112D0C3; Tue, 2 May 2017 12:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] 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 wuV44xSX559H; Tue, 2 May 2017 12:21:47 -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 3F9D3129461; Tue, 2 May 2017 12:18:39 -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 v42JIW7D005375; Tue, 2 May 2017 21:18:32 +0200 (CEST)
Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (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 3wHWKh3dJszDHjL; Tue, 2 May 2017 21:18:32 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Last Call: <draft-nottingham-rfc5988bis-05.txt> (Web Linking) to Proposed Standard
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <149339514498.2963.17820948075543728710.idtracker@ietfa.amsl.com>
Date: Tue, 02 May 2017 21:18:32 +0200
Cc: Alexey Melnikov <alexey.melnikov@isode.com>, Barry Leiba <barryleiba@computer.org>, draft-nottingham-rfc5988bis@ietf.org
X-Mao-Original-Outgoing-Id: 515445511.915529-2e154204e3f776008bf1e7519cbbb466
Content-Transfer-Encoding: quoted-printable
Message-Id: <4BECE06F-D3E5-4F9B-9DBF-AE9150942190@tzi.org>
References: <149339514498.2963.17820948075543728710.idtracker@ietfa.amsl.com>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/WHctL0CY-rCc4yT-aIRZoFttWxw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 May 2017 19:21:51 -0000

Review of draft-nottingham-rfc5988bis-05.txt
Reviewer: Carsten Bormann
Review result: Ready with a few issues

(This is not a complete review, but in its present state might serve
to initiate discussion of items relevant to RFC 6690 and thus
draft-ietf-core-links-json.)

This specification updates RFC 5988.  The objectives for this update
are not clearly stated, but it seems to be based on experience with
RFC 5988 as well as based on advances possible with the publication of
RFC 7230.

# Major technical

T1: The draft does not take position what should happen when
serializations allowed by RFC 5988 but not by the present spec occur,
e.g.: ;type=text/plain (would now need to be ;type="text/plain").

T2: The draft says "Serialisations SHOULD coordinate their target
attributes to avoid conflicts in semantics or syntax."  To me it seems
that this gives link applications such as the one specified in RFC
6690 the go-ahead to define their own registries of target attributes.
The draft should take a position on this.

# Minor technical

T3: One of the major items of progress that this specification exhibits
is that target attributes are no longer defined by the ABNF of the
link-header serialization (which usually has two alternatives, one of
which may be forgotten) but by the ABNF of the attribute value string
itself.  ANBF tools usually can process ABNF rules, but not directly
the bare ABNF "alternations" (rule RHS) used here.  This may also make
it a bit harder to reference the ABNF from a dependent specification,
as there is no rule name for that alternation given.

# Minor editorial

E1: The abstract should probably mention that this replaces RFC 5988.

# Nits

The spec seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but
does not include the phrase in its RFC 2119 key words list.  (Pet
peeve.)

s/ for indicate/ for indicating/

Grüße, Carsten