* Philip Jägenstedt wrote: >> RFC 3986 requires implementations when processing a fragment identifiers >> to treat %74 and "t" the same regardless of where either occurs, as "t" >> is not a reserved character and URIs that differ only in the escaping of >> unreserved characters are defined to be equivalent. So the answer here >> is "all components". You can only have special requirements for reserved >> characters when they occur unescaped. > >If I understand this correctly, this means that percent-decoding must be >performed on all names and values, which I welcome. > >However, given this situation, how is it possible to express parsing in a >single layer of ABNF? When the ABNF says "t", it really means "t" or >"%74", if these are indeed supposed to be equivalent. How do other specs >layered on top of URI handle this? The only way would be to actually say `%x74 / "%72"` in each of these cases, which would make the grammar rather unreadable. A workaround would be to require a pre-processing step that removes escaping for octets that are not reserved and then work with the result. >(I think it would be cleaner to split the syntax into two levels -- one >that identifies arbitrary name-value pairs, and one that is defined in >terms of the Unicode strings that those names/values represent.) I agree. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/Received on Tuesday, 6 July 2010 15:33:49 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:39 GMT