Re: [apps-discuss] APPSDIR review of draft-gregorio-uritemplate-07

Frank Ellermann <> Wed, 07 December 2011 15:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 355E221F8922 for <>; Wed, 7 Dec 2011 07:33:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.799
X-Spam-Status: No, score=-103.799 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, GB_I_LETTER=-2, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VNTTRPtWsbPl for <>; Wed, 7 Dec 2011 07:33:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 41DC921F86EC for <>; Wed, 7 Dec 2011 07:33:36 -0800 (PST)
Received: by bkbzs8 with SMTP id zs8so672543bkb.31 for <>; Wed, 07 Dec 2011 07:33:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=1thCHtJGYgUourSDmmj8LMYKD7srw1FO0JZdQ63T4mM=; b=cdFFHvmZzlNZFfpxTpydKV5PO9yOs7UKKe49MVt4yPdV5cjuQXwIM6dV724BlDyMoW uTakRZKqRY4PVIj9lQ81cw3EyTV8WSXl9zk4GKtDoaeomcvbC/frPJ5WyL4o2sBbQBto bVtIrpGwNG5hpTFXUizyGknOMdt3Ov4Ng7yB0=
Received: by with SMTP id l7mr24751220wil.51.1323272015383; Wed, 07 Dec 2011 07:33:35 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 7 Dec 2011 07:32:53 -0800 (PST)
In-Reply-To: <89527141FD764100A4B43FEDBC6E027F@LENOVO47E041CF>
References: <89527141FD764100A4B43FEDBC6E027F@LENOVO47E041CF>
From: Frank Ellermann <>
Date: Wed, 7 Dec 2011 16:32:53 +0100
Message-ID: <>
To: Jiankang YAO <>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] APPSDIR review of draft-gregorio-uritemplate-07
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Dec 2011 15:33:37 -0000

On 7 December 2011 04:18, Jiankang YAO <> wrote:

> Major issues:
> 1) In section 1.5.  Notational Conventions

> There is a repetition of definition of ALPHA, DIGIT, HEXDIG,......

> There is a discussion in IETF: we should not give the repetition of
> definition of ABNF syntax if we can refer it to other documents. The
> reason is that repetition may bring the errors or misunderstanding.

Well, we're not supposed to "redefine" terms unless we really want it,
but I fear that your suggestion misses another important point:

> for example, we just say "ALPHA, DIGIT are imported from RFC5234"

If you write that only in prose Bill's syntax checker would flag the
terms as "undefined".  IMO the best way for imports is something in
the direction of

   ALPHA = <ASCII letters as specified in appendix X of RFC 5234>

Or similar, it's an editorial nit, and not really a major issue here,
after all this draft doesn't try to redefine any STD 68 terms ;-)

> 3)Normative reference [1] points to
> <> which is maillist archive
> and can not be Normative.

LOL, yes, that is an xml2rfc artefact, at some point it tries to dump
all pending URI references.  AFAIK the authors intend to add three or
more missing informative references, that should also take care of the
discussion list URI.  Using <eref ... /> might also help to get rid of
this non-normative oddity.

> Discussion issues:
> 1)No IANA actions are required by this document.

> comments or suggestions: I suggest something in the document to be
> added to IANA, for example,the operators in section 2 and 3 of this
> document.
> If we register these operators in IANA, it will help the future use
> of these operators/characters.

IMHO IANA registries should only be created when they are required,
and if they are (supposed to be) helpful.  That's not the case here,
all used operator characters are fully specified, and all remaining
potential operator characters are enumerated:  It is the job of any
later draft to create a registry if the "KISS" approach (= complete
enumeration in one memo) does not more work.

> 1) "after UTF-8 encoding" in the first paragraph In section 1.2
> Levels and Expression Types need a reference to UTF-8

For some reasons major parts of the terminology ended up in 1.5 and
1.6 _after_ some preliminary uses in 1.2 ... 1.4.  Normally the
order of 1.x sections in a draft is no issue, but here 1.2 is rather
long; hopefully the order can be rearranged, or improved by forward

> 3) In the 4th paragraph of section 1.6, Normalization Form C needs
> a reference.

The given reference UAX #15 is good enough for my purposes, this is
no draft where a reference to RFC 5198 would be clearer.  YMMV, and
lists "UTF-8" as a well-known term, but does not yet star "NFC".