Subject: Re: [Uri-review] Comments on draft-hoehrmann-javascript-scheme

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 01 Jul 2011 12:37:21 +0200

* Mykyta Yevstifeyev wrote:
>You personally encouraged me to copy comments to uri-review.

Assume that I think it's entirely impossible that anyone would ever
think about forwarding private correspondence to a public mailing list
without very explicitly asking whether that is okay, and then read what
I wrote again. Not that it matters here, but if you don't feel like
keeping private correspondence private, then send only public mails.

>However a number of UTF-8 encoded octets are not allowed in URIs and 
>IRIs as well.  They are those which do not match the <unreserved> and 
><iunreserved>, respectively.  Moreover, as UTF-8 is the dominant 
>character encoding for application/javascript, I don't see any reasons 
>to define IRI scheme.  UTF-8 encodes any UCS char as ASCII char, many of 
>which are allowed in URIs.

There is no need for individual schemes to re-inforce which characters
are allowed (though they should not cause confusion by, say, defining
overly permissive grammars, for instance).

>Here it is preliminarily assumed that URI syntax is defined with ABNF 
>(in order to match the <absolute-URI>).  Moreover, we have MUST here, 
>which is the normative requirement.  I don't think the registration 
>without the syntax definition will be OK.

The syntax is defined in the draft. Your proposal to define that the
syntax is "javascript:" followed by a `segment` does not define the
syntax, as that allows for strings that are non-conforming. I'd be all
for having some sort of formal grammar in the document, but only if it
actually fully defines the syntax constraints. As it is, doing this via
prose is much simpler.

>>>>      The first operation, source text retrieval, defines which script code
>>>>      a given 'javascript' resource identifier represents.
>>> Maybe here s/defines which script code/defined how to determine the
>>> script code.
>> I don't see why that would be an improvement.
>Because "which script code" assumes there is a finite array of valid 
>Javascript codes whereas javascript URI refers to a member of such 
>array.  However, since Javascript codes are not limited in size, we can 
>assume that such array is infinite.  This is a grammar question mostly.

Well, I am happy to change "which", but I do not think I want to change
"represents" into "how to determine"; although, this is the Introduction
so I don't care much either.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 01 Jul 2011 18:46:57 +0300

> keeping private correspondence private, then send only public mails.
If you do feel so, I apologize.  Sorry.
>> IRIs as well.  They are those which do not match the<unreserved>  and
You document does not clearly mention whether it defined URIs or IRIs, 
which is very important, including the respect of allowed characters.
>> (in order to match the<absolute-URI>).  Moreover, we have MUST here,
Are there any provisions regarding valid syntax of Javascript code in 
official Javascript specification?
> so I don't care much either.
Please do feel free to consider my comment to that extent you personally 
deem fine.

Mykyta Yevstifeyev

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 01 Jul 2011 18:02:57 +0200

>If you do feel so, I apologize.  Sorry.

No worries.

>which is very important, including the respect of allowed characters.

It defines a scheme, it does not matter, for the definition of the
scheme, whether you use the scheme with URIs or with IRIs.

>official Javascript specification?

Yes, of course. `(` for instance is not a proper program, and so the
resource identifier `javascript:(` is also malformed.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 01 Jul 2011 19:12:23 +0300

>> If you do feel so, I apologize.  Sorry.
Thanks.
> scheme, whether you use the scheme with URIs or with IRIs.
IRIs may be considered to be a superset of URIs too.  Therefore defining 
IRI scheme is clearer and allows it to be used in URIs.  However, I 
don't see why you want IRI scheme - Javascript code is UTF-8 encoded 
ASCII text, per RFC 4329, so non-ASCII chars are inappropriate here.
> resource identifier `javascript:(` is also malformed.
I mean that such syntax could be formed as ABNF from such provisions in 
Javascript specification and put in the draft.

Mykyta Yevstifeyev

---

From: Julian Reschke <[email-masked]>
Date: Fri, 01 Jul 2011 18:17:49 +0200

On 2011-07-01 18:12, Mykyta Yevstifeyev wrote:
> ...
> IRI scheme is clearer and allows it to be used in URIs. However, I don't

As long as we do not revise the underlying specs, it' URI schemes that 
we formally define.

> see why you want IRI scheme - Javascript code is UTF-8 encoded ASCII
> text, per RFC 4329, so non-ASCII chars are inappropriate here.

Doesn't compute. The most important use case for javascript URIs is 
embedding into HTML, in which case what you have is a sequence of 
characters (after extraction from the containing document), not a 
sequence of octets.

> Javascript specification and put in the draft.

a) Maybe it could not (depends on how precise you want it to be).

b) What's the use case for something that sounds like an enormous amount 
of work?

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 01 Jul 2011 19:28:21 +0300

> As long as we do not revise the underlying specs, it' URI schemes that 
In terms of RFC 4395, yes.  RFC 3987 does not have any provisions 
regarding IRI schemes registration.
> characters (after extraction from the containing document), not a 
And those characters are UTF-8 encoded, ie. in ASCII range.  ASCII 
characters are fully encoded in URIs, except those which are reserved.  
When determining the source text UCS chars will be restored and then 
interpreted.
> b) What's the use case for something that sounds like an enormous 
> amount of work?
We should have a look at ECMA 262 aka ISO/IEC 16262:2011 to answer 
this.  It's better to define something generic rather than considering a 
great number of Javascript issues in ABNF, though.

Mykyta

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 01 Jul 2011 18:33:12 +0200

>ASCII text, per RFC 4329, so non-ASCII chars are inappropriate here.

Per RFC 3987 'there is no such thing as an "IRI scheme"'. The idea is
indeed to allow references like `javascript:'ö'`, though of course the
equivalent `javascript:'%C3%B6'` is okay, too. I am not really sure what
you think the problem is.

>Javascript specification and put in the draft.

There would be various problems, for instance, the formal grammar for
JavaScript (or rather ECMAScript) is not written in ABNF and cannot be
translated easily, and it does not account for %xx-escape sequences as
they would appear in the scheme-specific part of resource identifiers,
and, most importantly, the syntax is changed between revisions.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 01 Jul 2011 18:39:00 +0200

On 2011-07-01 18:28, Mykyta Yevstifeyev wrote:
...
> When determining the source text UCS chars will be restored and then

No, they are not. They are in the encoding of the enclosing HTML 
document. This may or may not be UTF-8.

> We should have a look at ECMA 262 aka ISO/IEC 16262:2011 to answer this.
> It's better to define something generic rather than considering a great
> number of Javascript issues in ABNF, though.

What's the use case?

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 02 Jul 2011 07:02:25 +0300

> you think the problem is.
The problem is that the draft fails to state whether valid javascript 
resource identifiers may be IRIs (to define IRI scheme, de facto) or 
they are limited to URIs (to define URI scheme, de facto and de jure).
> and, most importantly, the syntax is changed between revisions.
Yes, Javascript valid code is described by ABNF nowhere.  However, ECMA 
Standard 262, Section 6 defines what is a source code.  (See 
http://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B1y9iULaT86CZGVhZTBhZmYtZTYwMi00ZmJjLTkzZTAtODJkOGI4OTZmMmJk&hl=en_US).  
Therefore we may construct the ABNF definition is the following way:

    javascript-uri = "javascript:" source-code
    source-code    = <valid Javascript source code per Section 6 of 
[ECMA-262]>

... and point to the latest edition of ECMA-262.

Mykyta Yevstifeyev

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 02 Jul 2011 07:06:01 +0200

>they are limited to URIs (to define URI scheme, de facto and de jure).

The current text is

  A resource identifier conforms to this specification if and only if
  it is a valid IRI and application of the source text retrieval
  operation yields a valid application/javascript entity without
  generating any error.  Use of a byte order mark is discouraged;
  percent-encoding of "/" (U+002F SOLIDUS) characters is encouraged.

That allows for IRI-but-not-URI characters where application/javascript
allows them.

>... and point to the latest edition of ECMA-262.

That is not correct as %xx sequences are allowed but are not covered by
the ECMAScript specification, and ECMAScript is a subset of JavaScript.
I believe the reference to application/javascript is more appropriate.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 02 Jul 2011 08:58:45 +0300

> That allows for IRI-but-not-URI characters where application/javascript
Now I see what is this text about.  Probably mentioning of "resource 
identifiers" throughout the document rather than "IRIs" (or "URIs") is a 
bit confusing with this respect.
>>     source-code    =<valid Javascript source code per Section 6 of
>> [ECMA-262]>
>>
OK, in this case we can define source code as:

    source-code = <valid application/javascript entity per RFC 4329>

This will eliminate the problem with syntax definition.

Mykyta Yevstifeyev

---

From: Julian Reschke <[email-masked]>
Date: Sat, 02 Jul 2011 11:43:33 +0200

> This will eliminate the problem with syntax definition.

Remind me: what "problem" does adding a prose rule solve here?

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 02 Jul 2011 16:13:01 +0300

> Remind me: what "problem" does adding a prose rule solve here?
Absence of clear syntax definition required by RFC 4395.

Mykyta

---

From: Julian Reschke <[email-masked]>
Date: Sat, 02 Jul 2011 15:20:06 +0200

> Absence of clear syntax definition required by RFC 4395.

A prose rule in ABNF isn't any clearer than text prose that constrains 
the scheme-specific part.

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 02 Jul 2011 16:24:36 +0300

> the scheme-specific part.
There is no clear and explicit statement of what is allowed in 
hier-part.  At least clarifying it in the document won't be extra.

Mykyta