W3C home > Mailing lists > Public > uri@w3.org > February 2004

Re: draft-fielding-uri-rfc2396bis-03, section 1 and 2

From: Roy T. Fielding <fielding@gbiv.com>
Date: Sun, 8 Feb 2004 01:37:53 -0800
Cc: uri@w3.org
To: Martin Duerst <duerst@w3.org>
Message-Id: <77B63E06-5A1A-11D8-92BD-000393753936@gbiv.com>

Generally speaking, I have fixed all of the problems you noted in
sections 1 and 2, with the exceptions being

> 1.2.2: Please add examples for "resolution", "dereference", and
>        "retrieval".

I don't have any such examples in text form.

> 1.2.3: The URI syntax is organized ... decreasing order from left to 
> right.
>     Please mention the exception of the components of 'hostname'.

I am not talking here about the internal composition of data
within the components, but rather their relation to each other.

> 1.3 Syntax Notation
>     Why are we not using MUST/SHOULD, and don't reference their
>     official definition? Are we using different language?
>     Do we think we can avoid lots of useless discussion?

A careful read of RFC 2119 will reveal why.  Their purpose is to
define specific interoperability requirements for Internet hosts.
Most of the time, specifications misuse them for simple requirements.

However, I have moved to a more straightforward use of must and
should, rather than recommended, as I rewrite sections.

> Section 2.1 in RFC 2396 contained more material, in particular also
> the following small diagram:
>    URI character sequence->octet sequence->original character sequence
> In discussion on the W3C TAG list, I proposed to clarify this area
> of the specification with a more extended diagram. Why have neither
> of these diagrams been used?

Because they did not serve to clarify the situation.  The distinction
you make between those words don't mean anything to people who haven't
carefully studied the definitions and dealt with the issues that are
better described by RFC 2978.  The examples were better, so I used those
where appropriate.

Received on Sunday, 8 February 2004 04:46:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:07 UTC