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

[Bjoern Hoehrmann <[e-mail]>]

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

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

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

I disagree. If I were to add a definition like:

>>      javascript-uri = "javascript:" code
>>      code           = segment

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.

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

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.

>Section 3.2 (and global): I don't see why you chose the name "In-context 
>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.

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

See http://www.w3.org/mid/[e-mail] and list archives.

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

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

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

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.

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

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

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

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

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

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.

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

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:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/