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

"Roy T. Fielding" <> Thu, 08 December 2011 22:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CF2221F8545 for <>; Thu, 8 Dec 2011 14:23:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j2nlmi4Lyadj for <>; Thu, 8 Dec 2011 14:23:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id ACCAC21F851A for <>; Thu, 8 Dec 2011 14:23:47 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 5070A678055; Thu, 8 Dec 2011 14:23:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns;; b=sz6xNzNwTlGx6JS5 6kIT40uVDwoczxT9Y2tfdV/QgNXQse7E9FQLT5/hSqMjrrl+B9zgwYR+IA35C5mH 7EubISC/VzSSfrEVutOnJPqKQQzSqpY5Y8+vw417ZSd0cyOL64Iz2NxtjBA5mBwm JoUm7yNUs9LXvY6BczI3wdS2sXo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to;; bh=5qxOmO9KELfFSfQyI9RyWUsqWz0=; b=XtOR3HxjIdPdP6WvucN4Mrnf2rSD EgGUW4hPykxzKaUhFQEahjO/Y7tTvk4zo5ouLE75n90U2GINNfmBfXeOvDAy/x5P Q0x3af92GY9he2jgpJvrGTamKKWNdO/ioCUV16LL3rUK6JaYiVIVPAXi/4Neh4d4 qznZ+1DGeCk0j1g=
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 24AEC67803E; Thu, 8 Dec 2011 14:23:47 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=GB2312
From: "Roy T. Fielding" <>
In-Reply-To: <>
Date: Thu, 8 Dec 2011 14:23:50 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <89527141FD764100A4B43FEDBC6E027F@LENOVO47E041CF> <> <583806B95F08410DBEFE3E04E79D28A4@LENOVO47E041CF> <>
To: Mark Nottingham <>
X-Mailer: Apple Mail (2.1251.1)
Cc: "" <>, IETF Apps Discuss <>
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: Thu, 08 Dec 2011 22:23:48 -0000

On Dec 7, 2011, at 10:45 PM, Mark Nottingham wrote:
> On 08/12/2011, at 5:41 PM, Jiankang YAO wrote:
>>> Suggestion: for example, we just say "ALPHA, DIGIT are imported from RFC5234" instead of repeating
>>> "ALPHA          =  %x41-5A / %x61-7A   ; A-Z / a-z"
>> ==>Is this a discussion that's already taken place?
>> yes. the rule has been followed by EAI WG.
> Do you have a reference? I.e., is this an IESG ruling, or something that was decided in that WG? As has mentioned, taking the approach you outline will result in ABNF errors.

FWIW, I am opposed to making this change.  IMO, it is trivial for
any one of the reviewers prior to publication to verify that the
rules were copy and pasted correctly.  That's why they are all in
one section.  After that, the specification will be read by thousands
of people and used as a reference in hundreds of implementations, and
occasionally even automatically checked with abnf parsers.  The cost
of splitting the normative information across multiple specs is not
worth the theoretical notion that someone might copy them incorrectly.

These are not cases of independently developed protocol elements
that might be updated over time.  They are simply character sets.
We don't want them to be updated over time.  And they are essential
to understanding exactly what characters are allowed in each of
the rules in the main spec.

>> 4)There is a lot of "A URI Template" in section 1, but there is no precise definition of "URI Template" in section 1. The definition seems to appear on section 2.
>>> Comments: If the readers can understand it clearly, the definition should appear first.
>> ==>Could you make a concrete proposal here?
>> what is "URI Template" should be defined in section 1.
>> there is no precise or clear definition of "URI Template" in section 1.
> I was hoping for something more substantial. Let me take another look at it...

It is defined in the abstract. *shrug*