Subject: [Uri-review] Re: The 'javascript' scheme

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 04 Nov 2006 19:57:11 +0100

* 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:[email-masked] · 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/ 

_______________________________________________
Uri-review mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/uri-review

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 05 Nov 2006 13:47:07 +0100

* 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:[email-masked] · 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/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 05 Nov 2006 19:50:37 +0100

* Frank Ellermann wrote:
>Obviously I don't understand it, and don't know how to construct
>a javascript: URI from a given JS source, or how to implement it.

The simplest way to put it is this: the scheme-specific part of a
'javascript' resource identifier is a percent-encoded UTF-8 encoded
application/javascript entity; you should percent-encode the octet
that represents the '/' character, for all other characters RFC 3987
and RFC 3986 imply the relevant rules.

>> If it is possible to provide a complete ABNF, it would span
>> several dozens of pages.
>
>As far as the URI scheme is concerned I'd expect a few lines,
>addressing interesting cases for URI consumers and producers,
>with some examples.

It does address the '#', '/', and BOM cases, there are no other
interesting cases and there are several examples, valid and invalid.
-- 
Björn Höhrmann · mailto:[email-masked] · 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/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 05 Nov 2006 21:53:42 +0100

* Bjoern Hoehrmann wrote:
>  http://www.websitedev.de/ietf/draft-hoehrmann-javascript-ri-00.txt is
>a first draft defining the 'javascript' scheme. [...]

http://www.websitedev.de/ietf/draft-hoehrmann-javascript-scheme-00.txt
is what I have submitted for publication as Internet-Draft, taking into
account some of Frank's comments; in particular, I have included a new
paragraph in the Interoperability Considerations warning about possible
issues that may arise from certain uses of the scheme, and some minor
editorial changes.
-- 
Björn Höhrmann · mailto:[email-masked] · 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/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 05 Nov 2006 23:10:40 +0100

* Paul Hoffman wrote:
>At 7:50 PM +0100 11/5/06, Bjoern Hoehrmann wrote:
>I see two examples, one valid and one invalid. A section of examples 
>reinforcing the rules would probably be very helpful. We certainly 
>found this to be the case for the mailto: URI specification.

You can use any character allowed in IRIs in the scheme-specific part,
and in most cases you can use any character so long as the result is a
valid javascript program. As an example, there is nothing wrong with

  xlink:href="javascript:if (foo == 'Björn') { ... }"

in an XML document, because the XLink specification requires to percent-
encode all disallowed characters before processing the attribute value
as resource identifier. So if I had an example that reinforces that you
cannot use spaces or curly braces in resource identifiers, it would mis-
lead many readers of the specification because the rules do not affect
them. The draft even suggests to extend this for

  example="javascript:_scrollTo('#example')"

so that "example" would not be considered a fragment identifier, which
is necessary for many real world documents. So the only invalid examples
that would not require elaborate discussion to ensure not to mislead
readers would be examples with UTF-8 errors and with invalid javascript
code. I think that you cannot use invalid javascript is trivial, and
UTF-8 errors alone don't merit discussion. That leaves us with valid
examples; I don't know of any that both demonstrates good use of the
scheme and is short enough to fit a single line. Long examples would
then have to explain how line wraps and indentation are to be ignored.

In http://www.ietf.org/internet-drafts/draft-hoehrmann-urlencoded-00.txt
I have an extensive set of examples that demonstrate just about any edge
case making the set of examples a suitable initial test suite, and I do
agree that this is very helpful to clarify certain aspects of the spec,
but I do not see how I could construct something similar for the 'java-
script' scheme specification. In the end there are no non-trivial rules
that I could reinforce.
-- 
Björn Höhrmann · mailto:[email-masked] · 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/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 08 Nov 2006 17:16:28 +0100

* Graham Klyne wrote:
>What is the "resource" that is identified by a javascript: URI?  If you mean the
>javascript code, then how is the result of dereferencing the URI [1] (executing
>the code) to be considered a "representation" of that resource?  In this
>respect, I find the comparison with data: URIs to be misleading, since the
>resource identified by a data: URI is clearly represented in some way by its body.

It may well be that the draft doesn't use the best available terminology
and I am happy to change it if someone can come up with better terms. It
currently does not say what resource is being identified, instead it de-
fines two forms of "URI dereference". I think that executing code is not
"the result" of dereference, but part of it. I further think that deref-
erence, as defined in RFC 3986, does not imply retrieval of a resource/
representation--and as such I don't think your second question is valid.

  URI "resolution" is the process of determining an access
  mechanism and the appropriate parameters necessary to
  dereference a URI; this resolution may require several
  iterations.  To use that access mechanism to perform an
  action on the URI's resource is to "dereference" the URI.

In the "resolution" process you determine whether you use only content
retrieval or in-context evaluation, and in case of the latter other pa-
rameters like a ECMAScript global object, what type of code you have to
bind the `this` object, etc. Then you dereference the identifier as the
draft requires for the access method of your choosing. Note again that
there is nothing in the draft that says

  <script src='javascript:...' ...

is any different from

  <script src='data:...' ...

It may be, and often is, but in some cases, like X3D and VRML, it is
not. If that wasn't the case, it would have been possible to say that
a javascript:... resource identifier identifies a JavaScript object 
or nothing, and that to determine what it identifies, you have to per-
form in-context evaluation. But as this would contradict ISO standards
and probably cause similar confusion, I have not attempted to define
what resource is being identified, and the "result" of the evaluation
is termed "dereference by-product". As I said, there may be better ways
to phrase things; suggestions welcome.
-- 
Björn Höhrmann · mailto:[email-masked] · 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/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 08 Nov 2006 23:23:59 +0100

* Graham Klyne wrote:
>This gets closer to the nub.  While I agree that it does not imply "retrieval",
>I do think that obtaining a "representation" is implied, and it the nature of
>this representation -- what is it a representation *of* -- that I am questioning.

>What I'm trying to do here is establish common uses of javascript: URI-alike
>things correspond to URI dereferencing.  Anything else would, I think, violate
>the principle of least surprise -- when I type a URI into a browser address bar,
>or click on a hyperlink, I think its commonly held that the browser performs a
>dereferencing operation on the URI.

When you click on one of the following links,

  <a href='news:de.comp.text.xml'>...
  <a href='mailto:[email-masked]'>...
  <a href='mailto:[email-masked]?body=...'>...
  <a href='telnet://example.org'>...
  <a href='irc://irc.example.org/channel'>...
  <a href='tel:555-5555'>...

would you say your browser obtains representations?
-- 
Björn Höhrmann · mailto:[email-masked] · 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/

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Nov 2006 15:46:19 -0800

>would you say your browser obtains representations?

Yes
No
No
No
No
No

That is, some URI schemes get representations, and many others get 
actions. We have dealt with this for a very long time, particularly 
when we worked on the big revision to mailto: in 1997-1998.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 08 Nov 2006 16:26:10 +0100

Graham Klyne schrieb:
> I have rather mixed feelings about this proposal.
> 
> On one hand, it clearly describes a common practice that is better documented
> than not, and as such is to be welcomed.
> 
> On the other hand, I struggle to see how a javascript: URI-like string can be
> conceived as a "resource identifier" in the sense of RFC3986:
 > ...

+1

It's probably good to document it, but maybe to actually claim that is a 
URI is a mistake.

Best regards, Julian

---

From: Martin Duerst <[email-masked]>
Date: Thu, 09 Nov 2006 19:06:05 +0900

I tend to agree with Bjoern and Paul here that 'javascript:'
is a perfectly valid URI scheme, for the following reasons
(not all of them totally consistent maybe, but all of them
pointing in the same direction):

- It very often results in actually getting a representation.
  The way this is done is often much more complicated and
  context-dependent than e.g. for http:, but that's because
  it's turing-complete, after all.

- There are many bad and useless uses of javascript: URIs, but there
  are also extremely useful and appropriate uses. The one I'm personally
  most fond of are bookmarklets (also called favelets).

- Graham is asking how a representation (e.g. Web page) obtained
  as the result of 'dereferencing' (i.e. executing) a javascript:
  URI can be considered as the representation of that resource.
  Well, take a bookmarklet that lets you validate a Web page
  with the W3C validator. The resource is "Validate current Web page",
  the representation obtained is the validator output. As a resource,
  this is just as valid as "today's weather in Oaxaca"
  (see http://www.w3.org/TR/webarch/#intro).

- To use another analogy, assume I put up a CGI script somewhere
  on a server that (with all security bells and whistles) executes
  some snippets of programs in a particular programming language,
  and returns the results. The script is given in the query
  part of the http uri that points to my server CGI.
  How is this conceptually different from a javascript URI?
  The syntax is different, but the concepts are very similar.

- As Paul points out, not all URI schemes obtain representations,
  but they still designate resources. The mailto: URI scheme
  (currently RFC 2368, efforts for updating it underway as
   http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-03.txt)
  describes this as follows:
     A mailto URL designates an "internet resource", which is the mailbox
     specified in the address. When additional headers are supplied, the
     resource designated is the same address, but with an additional
     profile for accessing the resource. While there are Internet
     resources that can only be accessed via electronic mail, the mailto
     URL is not intended as a way of retrieving such objects
     automatically.

- We have other cases that are context-dependent, in particular
  the file: URI.

- <cynical pragmatic mode>
  If tomorrow, we found some new cool and useful way to let something
  happen when clicking on a link in a Web page, or otherwise when
  activating a field that contains an URI, we would just create
  an URI scheme for it, and would try to make the URI theory
  (resources, representations, and such) fit the practice. And if
  the theory wouldn't be able to explain things, we would/should
  get a better theory, not try to exclude useful functionality.
  </cynical pragmatic mode>

Regards,     Martin.

At 08:46 06/11/09, Paul Hoffman wrote:
>That is, some URI schemes get representations, and many others get actions. We have dealt with this for a very long time, particularly when we worked on the big revision to mailto: in 1997-1998.
>

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp      mailto:[email-masked]

---

From: Graham Klyne <[email-masked]>
Date: Thu, 09 Nov 2006 10:11:01 +0000

Hi Paul,

>> would you say your browser obtains representations?

I'd say "yes" to (at least) all the mailto: cases.  Someone else described this
better, but roughly the resource in case is a mail submission form.  Ah, hang
on, there's one with your name on it:
[[
   A mailto URL designates an "internet resource", which is the mailbox
   specified in the address. When additional headers are supplied, the
   resource designated is the same address, but with an additional
   profile for accessing the resource. While there are Internet
   resources that can only be accessed via electronic mail, the mailto
   URL is not intended as a way of retrieving such objects
   automatically.
]]
-- http://www.ietf.org/rfc/rfc2368.txt

Hmmm... that's not the particular description I was looking for, but it helps to
illustrate.

> actions. We have dealt with this for a very long time, particularly when
> we worked on the big revision to mailto: in 1997-1998.

(The revision appears to agree with me - see above.)

I *do* get a representation (presented, as it happens, in my mail client) when I
enter this URI into my browser:

  mailto:[email-masked]?body=hello

I can then interact with this representation and eventually invoke an action
(when I press the "send" button).  I think that that action is distinct from the
resource representation .

My unease with the javascript: case is that it's not so easy to identify an
identified resource.  How is one to interpret a javascript: URI if it appears in
a non-hyperlink type of context where other URIs can and do appear?

#g

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Nov 2006 11:17:05 -0800

At 9:15 AM +0100 11/9/06, Julian Reschke wrote:
>You need to install software on your machine (not in the browser) 
>that knows how to handle "tel" URIs.

I believe that even if the machine has software for handling "tel" 
URIs, that software will not "obtain a representation" of a phone 
number: it will initiate a phone call.

>-- http://www.ietf.org/rfc/rfc2368.txt

It may be "better", but I consider handwaving to achieve consensus to 
justify a decision that had been made earlier.

>   mailto:[email-masked]?body=hello

It is a representation, but it is a representation of a message, not 
of an internet resource, IMO.

---

From: Martin Duerst <[email-masked]>
Date: Fri, 10 Nov 2006 15:15:43 +0900

>a non-hyperlink type of context where other URIs can and do appear?

Hello Graham,

Sorry, but I somewhat don't get "a non-hyperlink type of context
where other URIs can and do appear". Can you give examples?

One example I have come up would be an XML namespace URI.
In that case, the namespace would just be identified literally
(i.e. by character-for-character comparison with other URIs
to check whether they are the same namespace or not). Same
for URIs/IRIs used in an RDF context.

Did you have this in mind (which in my eyes looks a bit too trivial
for asking the question above) or something else?

Regards,     Martin.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 10 Nov 2006 09:26:28 +0100

Paul Hoffman schrieb:
>> You need to install software on your machine (not in the browser) that 
>> knows how to handle "tel" URIs.
> 
> I believe that even if the machine has software for handling "tel" URIs, 
> that software will not "obtain a representation" of a phone number: it 
> will initiate a phone call.

It will start an application capable of doing phone calls, just as 
"mailto" starts an application allowing to send email.

Best regards, Julian

---

From: Graham Klyne <[email-masked]>
Date: Fri, 10 Nov 2006 11:23:29 +0000

> where other URIs can and do appear". Can you give examples?

Well:
 * as a namespace identifier in XML
 * as a profile identifier in BEEP
 * as a resource identifier in RDF
 * as an XML schema URI
 * as the object of an owl:imports statement in an OWL schema
 * as the object of a log:semantics statement in CWM

> for asking the question above) or something else?

I'd agree those are trivial most of the time, but I think the apparent
triviality here-and-now may mask future difficulties with evolving use of URIs
within the Web architectural framework.  What about, say, use as an owl:import
in an OWL ontology, or in application like CWM as the object of a log:semantics
statement?  In both of these cases, there's a cross-over between
URI-as-identifer and URI-for-retrieval.

The purpose of my initial question wasn't to say categorically that javascript
as URI is bad, but to try and understand how a URI scheme like this plays to
wider issues of web architecture.  The Web community has put much effort into
trying to avoid a messy dichotomy between these cases of URI-as-identifier vs
URI-as-mechanism - and I feel it would be good if we can understand how new URI
schemes can fulfil the various roles to which they are called. [*]

#g
--

[*] As it happens, I think there *is* at least one way to square this circle
w.r.t. javascript: URIs, but it's a bit obscure and to explain it I'd fall back
a bit on some theory of programming languages, so I haven't tried to offer it
thus far.  I offer it now not as a real suggestion, but to try and suggest some
direction in which the unease I raise might be addressed.

Roughly, a program can be thought of as an expression.  This is easy to see in a
pure functional programming language like Haskell:  a program is just an
expression that denotes a value - that value would be a representation of some
resource.  Thus far, it's quite like a data: URI.

But some programs are context dependent, in that the expression depends on
values out there in the real world (i.e. they perform input), and their
evaluation may also update values in the real world (outputs, or side effects).
 All these programs can be expressed in a pure functional form, though in doing so:
 (a) programs that take input have to be regarded as functions with "the real
world" as an input;  HTTP URIs can behave like this too, so no problem. (In
Haskell, this means they are evaluated in what is called the "IO monad".)
 (b) programs that have side effects, or perform output, are treated as
functions that return a new value of the real world -- Haskell also handles this
though its "IO monad", but describing the actual visible effects outside a
single program aren't covered by this.

Putting aside javascript programs with side effects, we could then say that a
javascript URI identifies some resource (without actually saying what, which is
true to a lesser or greater extent of other URI schemes), a representation of
which is returned by the program regarded as a function applied to the
real-world context in which it is used.

Programs with visible side effects are, I think, more problematic.

A practical consequence of this approach would be, I think, is that, taking into
account [http://www.w3.org/TR/2004/REC-webarch-20041215/#safe-interaction]
(specifically:  "Principle: Safe retrieval - Agents do not incur obligations by
retrieving a representation."), some restrictions should be placed on the kinds
of Javascript that are acceptable in a javascript: URI -- specifically, not
allowing Javascript with side effects visible outside the browser or application
in which they may be used.  For example, a Javascript URI should not invoke any
functions that update publicly visible data file systems or perform HTTP PUT or
POST operations.  This requirement would go beyond normal security constraints
for browser-side Javascript, as a URI can be used in all manner of contexts
other than a browser.

---

From: Graham Klyne <[email-masked]>
Date: Fri, 10 Nov 2006 11:34:27 +0000

> will initiate a phone call.

If it did so without further user interaction, it could easily be in violation
of web architectural principles about "safe interactions" (e.g. by incurring the
cost of a phone call)
[http://www.w3.org/TR/2004/REC-webarch-20041215/#safe-interaction].

> It is a representation, but it is a representation of a message, not of
> an internet resource, IMO.

I do broadly agree with that point (except that I might say its a representation
of a message composition facility rather than a message, but that's an
unimportant detail here).

#g

---

From: "Mark Baker" <[email-masked]>
Date: Fri, 10 Nov 2006 07:55:40 -0500

> "mailto" starts an application allowing to send email.

Or, as with Google Mail (in conjunction with Google Desktop, I
believe), that "application", in effect, redirects the browser to a
new URI that opens an HTML compose window to that email address...
which is most definitely a representation.  IMO, this just goes to
show that whether a representation is returned or not depends on
context (client/browser configuration, proxy configuration, time), not
the URI scheme.

One could also imagine an AJAX based IRC or telnet service which was
similarly hooked to the browser.

I'll comment on the draft later, in the other thread.

Mark.

---

From: John Cowan <[email-masked]>
Date: Fri, 10 Nov 2006 09:33:44 -0500

Graham Klyne scripsit:

> triviality here-and-now may mask future difficulties with evolving
> use of URIs within the Web architectural framework.  What about, say,
> use as an owl:import in an OWL ontology, or in application like CWM
> as the object of a log:semantics statement?  In both of these cases,
> there's a cross-over between URI-as-identifer and URI-for-retrieval.

Well, I'd say that roughly speaking a URI can be a name, a reference,
or a source (for inclusion/transclusion).  In the first case, any URI
will do.  In the second case, we have a rough practical understanding
of what it means to dereference a javascript: URI (something happens).
The third case is problematic, but so it is for many existing schemes
like tel: and telnet:.

I make no claim to be comprehensive, but I think the burden of persuasion
is on someone who'd show that javascript: is more difficult than the
others like it.

-- 
My confusion is rapidly waxing          John Cowan
For XML Schema's too taxing:            [email-masked]
I'd use DTDs                        http://www.ccil.org/~cowan
If they had local trees --
I think I best switch to RELAX NG.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 19 Nov 2006 02:45:01 +0100

* Graham Klyne wrote:
>[...]

I just re-read this thread and I still do not see how I could change the
draft to address the concerns you have raised. Could you propose changes
you would like me to make?
-- 
Björn Höhrmann · mailto:[email-masked] · 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/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 19 Nov 2006 03:01:30 +0100

>for browser-side Javascript, as a URI can be used in all manner of contexts

I think such restrictions would be unreasonable, there is no difference
in this regard between using a hyperlink with a javascript:... URI that
triggers a POST request and a hyperlink with a onclick='...' script to
the same effect. Besides, the content retrieval operation defined in the
draft is essentially free of side-effects; I don't think performing the
in-context evaluation operation is "retrieving a representation". It is
probably true that one should not make HTML documents like

  <body onload='document.getElementById("form").submit()' ...
    <form id='form' method='post' action='http://...' ...

where the browser would perform a POST request automatically when the
document has finished loading, just as one might argue that regardless
of whether this is a bad practise, browsers should consult the user
before actually performing the POST request, but these issues apply to
scripting generally, and less so to the 'javascript' scheme.
-- 
Björn Höhrmann · mailto:[email-masked] · 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/

---

From: Graham Klyne <[email-masked]>
Date: Sun, 19 Nov 2006 16:35:37 +0000

> you would like me to make?

I wish I could.  My hope was that some clearer consensus would emerge out of the
ensuing discussion.

The best I can suggest right now is to add a note under security considerations
to the concern you responded to here:
  http://lists.w3.org/Archives/Public/uri/2006Nov/0067.html

E.g.
[[
Very great care should be taken with Javascript URIs whose execution can cause
side effects.  There are circumstances in which URIs may be used in the full
expectation that simply dereferencing it does not cause any obligation to be
incurred (cf. http://www.w3.org/TR/2004/REC-webarch-20041215/#safe-interaction),
and care may be needed to ensure that simply resolving the URI in such
situations does not violate the expectations for "safe" interactions (in the
sense of RFC2616, section 9.1.1).
]]

Otherwise, having raised the issue for discussion, and made what points I feel I
can, I'm not inclined to argue the case further.

I hope this helps.

#g