- From: Frank Ellermann <nobody@xyzzy.claranet.de>
- Date: Sat, 04 Nov 2006 16:07:59 +0100
- To: uri@w3.org
- Cc: uri-review@ietf.org
Bjoern Hoehrmann wrote:
> http://www.websitedev.de/ietf/draft-hoehrmann-javascript-ri-00.txt
> is a first draft defining the 'javascript' scheme.
Some thoughts about that:
In the security considerations you could mention that some user agents
support other names like "mocha:" for this scheme.
In the interoperability considerations you could say that various
versions of "javascript" are known, e.g. my favourite browser could
handle Javascript 1.1, but nothing "better".
Either here or in the security considerations you could mention that
many browsers don't support Javascript, by design or by configuration.
In the abstract you say "for applications that need to specify script
code", IMO that should be "wish", elaborated later, explaining how to
avoid it with onclick-handlers or similar.
At the moment the "encoding considerations" required for the RFC 4395
template are hard to find in your text, in chapter 2 you mention that
using "/" might be a bad idea, in chapter 4 you mention "#".
IMO you need a complete list of allowed characters in javascript URIs,
and maybe that's as simple as "MUST be <pchar>".
Out of curiosity, can Javascript code really start with a BOM ? If
"yes" that part is clear in your memo, but apparently it depends on
the version. My browser supporting JS 1.1 doesn't know what Unicode
is, let alone a BOM.
Maybe a point for your I18N considerations, or for step (4) in 3.1:
What does "decode UTF-8 into source code" mean - if the evaluation
(in 3.2) can't handle UTF-8 source code, what else does it expect as
result from 3.1, UTF-16BE ?
In the security considerations you say that it's the _same_ issue as
for the data: scheme. IMNSHO this hand waving is not appropriate.
> what to do about the RFC 4329 reference
Nothing, it's okay.
> As I understand RFC 4395 the template does not have to be part of
> the document; it would be rather silly to include one
It's not possible to review a scheme registration template without
the template. What's the intended status ? I propose "historical".
What's the semantics, ECMAscript ? Who's the change controller, as
the name says ECMA, or the IETF, or you ? Certainly not Netscape.
Etc., if parts of the template are silly you could try references
like "see section 5" for the security considerations.
> 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.
Some characters are certainly not allowed in URIs, CTL, SP, DEL, <,
>, {, }, etc. And probably some are not allowed in Javascript, if
it's simple enough like "don't try %00" you could mention it.
> I also considered saying something about javascript:void(...) style
> references, but I don't think this would be useful either.
You should discuss favlets / bookmarklets, that's the only case I'm
aware of where this scheme is sometimes useful, folks can copy code
by bookmarking it.
Nested "'" and '"' in <a href="javascript: etc. contexts are a pain,
here's an example working for me (if I'd enable JS 1.1):
javascript:P=window.open('','','width=512,height=32');P.document.write('<title>document.lastModified</title><div align=center><form><input type=button value='+unescape('%22')+document.lastModified+unescape('%22')+' onclick=self.close() /></form></div><a href='+document.URL+'>'+document.URL+'</a>');void(P.document.close())
In the document http://purl.net/xyzzy/lab.htm#favelets that's:
<a href="javascript:P=window.open('','','width=512,height=32');P.document.write('<title>document.lastModified</title><div align=center><form><input type=button value='+unescape('%22')+document.lastModified+unescape('%22')+' onclick=self.close() /></form></div><a href='+document.URL+'>'+document.URL+'</a>');void(P.document.close())">document.lastModified</a>
Frank
Received on Saturday, 4 November 2006 15:32:30 UTC