- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 22 Jan 2007 09:21:13 +1100
- To: Benjamin Carlyle <benjamincarlyle@optusnet.com.au>
- Cc: Marc Hadley <Marc.Hadley@Sun.COM>, Joe Gregorio <joe@bitworking.org>, James M Snell <jasnell@gmail.com>, uri@w3.org
That goes too far; after all, the're "URI Templates", and should take advantage of URIs. If there's a backwards-incompatible change, the result won't be called URIs (see: IRIs), and we can come up with a *RI Templates then... On 2007/01/21, at 3:08 PM, Benjamin Carlyle wrote: > This actually suggests to me that perhaps no blanket rule should be > included in the specification. It is simply the responsibility of the > supporting instructions to construct a valid URL. Encoding > ( iprivate / > iunreserved / ireserved) into the specification ties uri templates to > the current uri rfc, creating unnecessary coupling. > > Even restricting resultant urls to be valid may be overreaching. After > all, should a browser decide the url isn't valid and stop the > submission? Shouldn't it just pass the information it doesn't > understand > through and let the server side decide what is valid and what is > not? I > would be as circumspect as possible in the specification as to what > constitutes valid output. -- Mark Nottingham http://www.mnot.net/
Received on Sunday, 21 January 2007 22:20:58 UTC