Re: The 'javascript' scheme

* Frank Ellermann wrote:
>Above all it must be clear and concise that javascript URIs belong
>into the "worse" department of "bad ideas", maybe you find a better
>way to express this.
>
>Finding serious references, WAI etc., to support this point, should
>be possible.  I just listed a few obvious, or as you say trivial,
>issues with this scheme.

It is also possible to find references that support the opposite point
of view. As I said, I don't think there is consensus about the status
of the scheme as you describe it above.

>Which characters must be percent-encoded (based on RFC 3986), which
>should not be percent-encoded (based on whatever user agent you pick
>to check this), and what about the conflicts, if there are any.
>
>More examples, in addition to the "#" case.  Would %23 work, and if
>not, what does that say about the scheme ?

>I haven't found it, sorry.  Can I use say "<" in an expression ?
>Can I use %3C ?  With javascript:1<2 as "location" I get true, is
>that as it should be ?

>How about a line of ABNF, something like:
>
>    javascriptURI = "javascript:" *pchar
>
>Obviously no reserved character.  And folks would also know that
>they have to percent-encode anything that's not directly allowed.
>I can't tell from your text if that's really the idea.

Given a 'javascript' resource identifier, the draft defines whether it
conforms to the specification and if, what source text it represents.
These definitions can be found in section 2 and 3 of the draft. They
imply which characters are allowed, which characters have to be escaped,
and how to construct the resource identifier for any given source text.

If you could cite a resource identifier where you think it is unclear
which source text it represents or whether it conforms to the draft, or
cite a specific example of source that where you think it is unclear how
to construct the corresponding resource identifier, I will happily
explain why I don't think this is unclear.

As for your examples above, neither '#' nor '<' can occur in the scheme-
specific parts of the resource identifier as currently defined, as such
these questions cannot arise. %23 and %3C can occur but not everywhere.
Where they are allowed is defined by the draft.

The grammar you have above is incorrect, it allows, for example, use of
"javascript:%F6". This not not allowed by the draft. I do not think it
would aid readability of the document to include incorrect grammars. If
it is possible to provide a complete ABNF, it would span several dozens
of pages.

>More about why script URIs can be dangerous.  Bypassing spam and
>phishing filters, manipulate the behaviour of the UA, the works.
>Maybe you could copy the relevant part of 2397 and build on that.

I think they are exactly as "dangerous" as data:application/javascript,
resource identifiers and the draft says just that, except as noted in
the draft. I think it is bad practise to copy text to avoid making any
reference to other documents.

>Maybe you can write "n/a" or "IETF" in a template contained in an
>I-D approved by the IESG.  If you don't want the template to be
>published together with the RFC maybe you can say that it should
>be removed during the publication after IANA copied/registered it.

I don't want to fill out the template *at all* and I've explained why.

>This application is the only justification to register this scheme
>at all, otherwise I'd propose to ignore it as harmful.  As soon as
>it's registered folks will claim that it's a good "official" scheme
>and multiply their efforts to abuse it (my crystal ball says).

The justification to register this scheme is that it is in common use.
Like any technology, it may not be suitable in all cases, and may even
be abused. What would you have me write? "Please don't feel encouraged
to further abuse this scheme"?
-- 
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 Sunday, 5 November 2006 12:47:14 UTC