Re: [apps-discuss] draft-farrell-decade-ni-02 - we think this is done...

Carsten Bormann <cabo@tzi.org> Thu, 05 April 2012 21:56 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3588E21F8592 for <apps-discuss@ietfa.amsl.com>; Thu, 5 Apr 2012 14:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.949
X-Spam-Level:
X-Spam-Status: No, score=-106.949 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOYZwCpS194U for <apps-discuss@ietfa.amsl.com>; Thu, 5 Apr 2012 14:56:40 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2299C21F859F for <apps-discuss@ietf.org>; Thu, 5 Apr 2012 14:56:39 -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.3/8.14.3) with ESMTP id q35LuT33002789; Thu, 5 Apr 2012 23:56:29 +0200 (CEST)
Received: from [192.168.217.117] (p5489AB9F.dip.t-dialin.net [84.137.171.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 457ED7CD; Thu, 5 Apr 2012 23:56:29 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset="iso-8859-1"
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <4F7DFC47.2020604@cs.tcd.ie>
Date: Thu, 05 Apr 2012 23:56:28 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <DDCD3226-782B-46E5-9CEB-61E4773CE0B2@tzi.org>
References: <4F7DFC47.2020604@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.1257)
Cc: Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-farrell-decade-ni-02 - we think this is done...
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2012 21:56:41 -0000

** Summary:

This may seem nearly trivial, but upon looking closer really is awesome work, something truly only the IETF could create.

** Nits:

What is a "thing"?  (abstract)

The reference from section 3 to section 9.1 appears wrong -- I don't think 9.1 actually defines the registry required here.
If this is referencing 9.3, please make sure there that the "ID" column is left empty (and thus no number consumed) if a number for the binary encoding is not needed.

I don't like the sentence
   Since application
   code often attempts to enforce such encoding, decoders MUST recognize
   the use of URI escape encoding.
and the following sentences too much -- yes, you MUST implement URI syntax, but not just for this reason.
Add examples of percent-decoding (implementers implement from examples!).

How useful is:
   If an application is presented with a HTTP(S) URL with "/.well-
   known/ni/" as the start of its pathname component, then the reverse
   mapping to an ni URI either including or excluding the authority
   might produce an ni URI that is meaningful, but there is no guarantee
   that this will be the case.
Wouldn't it be more appropriate to mandate that /.well-known/ni *MUST* only be used in a way that makes this reverse mapping useful?

s/URL Fragment/URL Segment/ (Fragment is confusing, as it means something specific in URIs.)

Maybe the human-readable form should be prefixed by "ni;" so it is easily recognizable.

http://www.tcd.ie/.well-known/ni/sha256/UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q does not resolve (maybe you meant example.com?).

I believe for this to be the replacement of "unsecure links out of HTTPS", the secure media type issue must be solved in the base spec.
(Oh, and is there ever a need to discuss content-coding in this context???)

Please re-spin http://tools.ietf.org/html/draft-hallambaker-decade-ni-params-00 and make sure that Martin's concern is addressed...

** PS

Again, I'm still in awe that a 10-page specification can solve so many problems in one fell swoop.

Grüße, Carsten