Re: The 'javascript' scheme

* Frank Ellermann wrote:
>Some thoughts about that:

Thanks for your comments.

>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.

I think these are all either out of scope, widely known, or trivial. For
example, your last point amounts to saying that not all applications im-
plement the scheme--that is true for all schemes. I would rather have
the document as clear and concise as possible.

>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.

As I said, the Abstract isn't all that good, but I don't think making
just the replacement you suggest would improve it. If you have other
suggestions, please let me know. As for the rest, the best I could say
is that, in some situations, the scheme may not be the best solution.
I expect http://www.w3.org/TR/WCAG20-SCRIPT-TECHS/ to give advise here
as that document matures.

>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 "#".

Could you be more specific what is unclear?

>IMO you need a complete list of allowed characters in javascript URIs,
>and maybe that's as simple as "MUST be <pchar>".

The draft fully defines whether any given resource identifier conforms
to it; the list of legal characters is implied by this definition, so
I don't see any actual need to include it. I also do not think this
would do anything but confuse readers.

>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.

Well, application/javascript entities can, as defined in RFC 4329. As
I understand it, recent versions of Mozilla allow a "BOM" here, yes.

>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 ?

It is "source text", not "source code", and the term is defined in
the document by reference to ECMA-262; it might be better to call
this "transform" or "transcode" instead, I will look into making
this change.

>In the security considerations you say that it's the _same_ issue as
>for the data: scheme.  IMNSHO this hand waving is not appropriate.

For all I can tell, as established in the draft, they are equivalent.
This has precise implications, I would not consider this handwaving
in any way. What would you have me say instead?

>> 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.

As I understand it, no one needs to review any template, as such it
seems there is no problem. The intended status is given in the IANA
considerations section; the scheme is in common use, and I do not
think there is any kind of consensus that the scheme should not be
used, as such 'historical' would be inappropriate.

The document has extensive discussion on the semantics, if you think
there is anything unclear, please be more specific. As per RFC 4395,
the change controller matters only for provisional registrations
and as such is not specified by the registration.

>Etc., if parts of the template are silly you could try references
>like "see section 5" for the security considerations.

The filled out template would be a Table of Contents.

>> 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.

No, the question is, do I absolutely have to include "No character
is reserved" in the document.

>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.

If you could suggest how to do this without making the Introduction
longer, that would be great.
-- 
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, 4 November 2006 18:57:33 UTC