The 'javascript' scheme

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:'&ouml;' 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