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

[Mykyta Yevstifeyev <[e-mail]>]

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