Subject: [Uri-review] Comments on draft-hoehrmann-javascript-scheme (was: Proposal regarding draft-hoehrmann-javascript-scheme)

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 30 Jun 2011 13:12:39 +0300

Hello Bjoern, all,

I'm copying this to uri-review list.  These are comments on 
draft-hoehrmann-javascript-scheme 
(http://tools.ietf.org/html/draft-hoehrmann-javascript-scheme-03), 
currently expired (these comments are in no particular order).

Some substantial comments:

As I identified before, the document is missing the syntax description.  
URIs have a limited number of allowed characters; some disallowed ones 
might be legal in Javascript code.  Therefore, if you define the URI 
scheme, those characters which do not suit to <unreserved> production of 
RFC 3986 should be percent-encoded within such URI, and this should be 
mentioned in the specification.  If you define IRI scheme, <reserved> in 
RFC 3987 are the same as in RFC 3986, which should be considered.  
Anyway, it's better to have formal definition of syntax using ABNF, even 
though it is going to be smth. like:

>      javascript-uri = "javascript:" code
>      code           = segment
>
>    where <segment> rule is defined in RFC 3986 [RFC3986].
If you add this ABNF, the following should be changed in Section 3:

>        1.  Represent the scheme-specific part as sequence of octets in
>            the UTF-8 character encoding.
s/the scheme-specific part/the <code> part.

Other comments to Section 3.
>        2.  Replace any percent-encoded octet by its corresponding octet.
s/corresponding octet/corresponding ASCII character (or UCS character, 
if you decide to define IRIs).

>        3.  If the sequence starts with the sequence 0xEF 0xBB 0xBF, the
>            UTF-8 signature, then discard this signature.
Probably editorial.  This is a tautology; I propose

>        3.  If the obtined chain of octets starts with 0xEF 0xBB 0xBF,
>            which is the UTF-8 signtaure, ignore these 3 octets.
Next,

>        4.  Decode the octet sequence using the UTF-8 character encoding
>            and transform the result into source text.
Probably it would be better to mention "Decode the octet sequence using 
the algorithm defined in Section 3 of RFC 3629; obtained ASCII text 
should be considered to be Javascript source code."

Section 3.2 (and global): I don't see why you chose the name "In-context 
evaluation".  Shouldn't "In-context execution" be better?

Section 7 is missing registration template required by RFC 4395 
(http://tools.ietf.org/html/rfc4395#section-5.4).

29.06.2011 19:36, Bjoern Hoehrmann wrote:
> * Mykyta Yevstifeyev wrote:
>> Actually, I have identified a number of other issues, the main of which
>> is absence of section dedicated to syntax of the javascript URI.  There
>> are a number of editorial flaws, too.  So please, when you decide to
>> proceed, reconsider my offer.
> The Conformance section is dedicated to syntax. There is nothing more to
> it as it's just "javascript:" followed by the scheme specific part which
> is restricted in prose as that is not feasible in ABNF beyond "anything
> goes" if you have a proper IRI to begin with. Editorial problems, please
> do report, either to me directly or uri-review or wheverever.
Among other minor/editorial issues:

Global: s/resource identifier/URI (should be explained in Abstract when 
first mentioned as Uniform Resource Identifier) or IRI, dependent on 
what you define.  I suppose URI is a better term for 'javascript' RI.

Abstract:

>     Using
>     this scheme, executable script code can be specified in contexts that
>     support resource identifiers.

I propose:

>     Using 'javascript' URIs, Javascript (also known as ECMAScript)
>     executable code may be specified in such URI and executed by
>     the application resolving it.

Section 2:

>    Resource identifiers, including percent-encoding and requirements for
>    IRIs, are defined in STD 66, [RFC3986], and [RFC3987].  Source text
>    and the media type application/javascript are defined in [RFC4329],
>    the 'data' scheme in [RFC2397], and UTF-8, including the term byte
>    order mark, in STD 63, [RFC3629].

I think mentioning specification for these terms in the text of the 
document itself rather than combining them in one section seems to be a 
better option.  This will add clarity to the document.

Section 1:

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

Ibid:

> <a href='javascript:doSomething()'>...</a>
For the purpose of an example, it would be better to mention something like

> <a href='javascript:doSomething()'>Run doSomething</a>
Ibid:

>     script, style sheet, HTML document, resource identifier, or other
>     type of resource, as appropriate for the context.
Considered you provide this list as an illustration of the previous 
phrase "like an Internet media type, how to process it" I should note 
URIs aren't classified as some media type so it's better to remove URIs 
from this list.  Moreover, probably you meant "MIME media type", not 
"Internet media type".  Also, informative reference to RFC 2046 is 
probably missing.

I hope my remarks were useful.

Thanks,
Mykyta Yevstifeyev

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 30 Jun 2011 15:43:30 +0200

* Mykyta Yevstifeyev wrote:
>I'm copying this to uri-review list.

Please see RFC 1855, section 2.1.1., bullet point #4.

>>      javascript-uri = "javascript:" code

Then people would read this as saying certain resource identifiers are
conforming because they match the grammar even though they would not be
conforming under the current definition.

>should be considered to be Javascript source code."

As pointed out in the draft, "source text" is a concept used in the
ECMAScript specification, and while people recognize "UTF-8", they
likely need to look up what is "RFC 3629"; that UTF-8 is defined in
STD 63 is pointed out in the draft.

>evaluation".  Shouldn't "In-context execution" be better?

You execute statements (instructions) and evaluate expressions. It would
be weird to say for javascript:'1' you "execute" the string literal.

>(http://tools.ietf.org/html/rfc4395#section-5.4).

See http://www.w3.org/mid/[email-masked] and list archives.

>what you define.  I suppose URI is a better term for 'javascript' RI.

My usage is consistent with draft-hansen-iri-4395bis-irireg-00.

>>     the application resolving it.

JavaScript is not also known as ECMAScript. JavaScript is essentially a
proprietary language where parts of it are standardized under the ECMA-
Script moniker. The JavaScript scheme is for JavaScript. "Execution" and
"URI" have the same problems as discussed above.

>better option.  This will add clarity to the document.

I disagree, I would find inline references for terms like "UTF-8" in the
middle of the text rather distracting.

>Maybe here s/defines which script code/defined how to determine the 

I don't see why that would be an improvement.

>> <a href='javascript:doSomething()'>Run doSomething</a>

No, that would draw undue attention and I would regard this kind of link
text a bad practise, much as using this kind of link is a bad practise
for reasons mentioned in the document. It's what people are likely to be
familiar with though, so that's why I use the example.

>"Internet media type".  Also, informative reference to RFC 2046 is 

The term "MIME media type" is obsolete, RFC 4288 for instance just calls
them "media types", and Internet media type is the common term to tell
those apart from some other "media types". I do not think a reference to
RFC 2046 would be useful here, I also don't have a reference to HTML or
Unicode even though I mention HTML documents and use "U+002F SOLIDUS".
-- 
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 06:00:04 +0300

> Please see RFC 1855, section 2.1.1., bullet point #4.
You personally encouraged me to copy comments to uri-review.
>> scheme, those characters which do not suit to<unreserved>  production of
>> mentioned in the specification.  If you define IRI scheme,<reserved>  in
The current definition comparable to syntax 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.
which in fact refers the reader to RFC 4329, explicitly Section 4, which 
says:

>    Implementations that support binary source text MUST support binary
>    source text encoded using the UTF-8 [RFC3629] character encoding
>    scheme.
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.  So do UTF-16 and UTF-32, which are also 
allowed by

> Other character encoding schemes MAY be supported.
As for the formal syntax.  From RFC 4395, Section 2.2:

>    All URI scheme
>    specifications MUST define their own syntax such that all strings
>    matching their scheme-specific syntax will also match the
> <absolute-URI> grammar described in Section 4.3 of RFC 3986.

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.
> STD 63 is pointed out in the draft.
Section 3 of RFC 3629 defined how to decode UTF-8 encoded -> Unicode.  
Pointing that (citing the draft):

> UTF-8, including the term byte
>     order mark, in STD 63
isn't too generic to point to this information.
> be weird to say for javascript:'1' you "execute" the string literal.
OK, I agree on this now.
 From Section 5.4 of RFC 4395:

>     This template describes the fields that must be supplied in a URI
>     scheme registration request:
where we have the non-normative must.

Section 5.2 ibid., with normative SHOULD, required the template for 
registration process.
> My usage is consistent with draft-hansen-iri-4395bis-irireg-00.
First, this is Internet-Draft and RFC 4395 is still BCP 35.  You need to 
be guided by current and active procedural documents.  And, 
draft-ietf-iri-4395bis-irireg-01 
(http://tools.ietf.org/html/draft-ietf-iri-4395bis-irireg-01), which is 
the most current version, uses "URI/IRI" rather than "resource 
identifier".  Yet, we haven't had any instances of use of such term in 
recently published URI scheme specifications.
> middle of the text rather distracting.
However, this is acceptable.  In recently published RFCs defining URI 
schemes, such as RFC 6068 (http://tools.ietf.org/html/rfc6068), RFC 6167 
(http://tools.ietf.org/html/rfc6167), RFC 6270 
(http://tools.ietf.org/html/rfc6270), we can see such reference formation.
> 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.
> familiar with though, so that's why I use the example.
OK, let's agree on this as well.
> Unicode even though I mention HTML documents and use "U+002F SOLIDUS".
RFC 4288 didn't draw distinction between (MIME) media types and Internet 
media types.  Neither did RFC 2046, which is currently on Standards 
Track.  Moreover, in some places you use "media type" while in others 
"Internet media type".  I personally think "media type" is fine, and its 
doesn't conflict with current RFCs.

Mykyta Yevstifeyev