Re: Rationalizing the term URI

I support Tim's suggestion, even though it will result in many 
descriptive
changes throughout the specification.

> 1) I think it's an extremely bad idea to simply change the definition 
> of the
> term, because it will negatively affect tons of other 
> RFCs/recommendations.
> If you need a simple term to talk about URIs + optional fragment, 
> define a
> new one.

That isn't actually a problem.  There is no current BNF rule for URI,
and thus any spec that used it would necessarily be doing so in an
informal way.  My observation has been that most specifications, when
referring to URI in an informal way, do expect the possibility that
it may include a fragment.

> 2) On the other hand, *if* the definition is changed, there's no way to
> avoid defining a *new* term for what a URI used to be. Or am I missing
> something?

The existing BNF rules already do that.  They would not be changed.

....Roy

Received on Thursday, 23 January 2003 12:25:58 UTC