- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Sat, 28 Oct 2006 11:49:11 +0200
- To: uri@w3.org
- Cc: uri-review@ietf.org
Hi, http://www.websitedev.de/ietf/draft-hoehrmann-javascript-ri-00.txt is a first draft defining the 'javascript' scheme. I intend to submit it for publication once publication resumes and I've figured out a good way to remove the normative reference to RFC 4329. I would appreciate feed- back concerning a better Abstract, a better first paragraph in the In- troduction, and what to do about the RFC 4329 reference. Also note: As I understand RFC 4395 the template does not have to be part of the document; it would be rather silly to include one, so I've omitted it. RFC 4395 has a non-normative recommendation Those who wish to describe resource identifiers that are useful as IRIs should define the corresponding URI syntax, and note that the IRI usage follows the rules and transformations defined in RFC 3987. This recommendation does not make any sense to me, so I did not do that either, at least not as I understand the text. I think I met the SHOULD level requirements concerning use of "/", ".", and ".." to the extent feasible. Concerning reserved characters, I think the draft is clear enough about it, if anyone thinks I absolutely have to state explicitly that no characters are reserved, please let me know. RFC 4395 further has In particular, Section 7 of RFC 3986 [5] describes general security considerations for URI schemes. The definition of an individual URI scheme should note which of these apply to the specified scheme. I did not do this as I would not know what to write, except perhaps that "Rare IP Address Formats" are obviously irrelevant to this scheme. I believe the draft meets all MUST-level requirements of RFC 4395. The issue of handling <javascript:_scrollTo('#example')>-style references is discussed in the Interoperability Considerations section. I think it would be possible to specify equivalent processing as part of the specification without violating the letter of the relevant specifications, but I wouldn't enjoy the inevitable discussion about how this violates the spirit of those specifications. What I have now is not without its problems, if there were specifications as suggested in the draft, you would typically be able to tell whether it is im- implemented thusly (e.g. by returning a HTML document with a script that check window.location.href) which would then reveal that current implementations do not behave this way, but oh well. Why the in-context evaluation operation is not fully defined in the document is explained in the Introduction. I considered to at least specify that the code is evaluated as global code, but once I do that someone would have the brilliant idea of defining that the 'this' object is not bound to the global object, and implementations would quickly be considered non-compliant. I also considered saying some- thing about javascript:void(...) style references, but I don't think this would be useful either. (An example of implementations actually disagreeing how to implement in-context evaluation is javascript:'ö' in an XHTML document). I considered also defining the 'ecmascript:' scheme as it is used in ISO/IEC 19775, but I don't think this is quite a 'permanent' scheme and provisional schemes cannot be registered from standards track documents, as I read RFC 4395. I might ask the Web3D Consortium to take care of that scheme in some other way. Finally, I thought about saying something about problems like when using javascript:example(...) and users try to open that in new windows or tabs, or mention bookmarklets, but I haven't found a good way to fit that into Abstract/Introduction without making them much longer. Thanks, -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Saturday, 28 October 2006 09:49:19 UTC