Subject: [Uri-review] Updated 'javascript' scheme draft

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 15 Sep 2010 15:52:08 +0200

Hi,

  http://www.ietf.org/id/draft-hoehrmann-javascript-scheme-02.txt is an
updated draft for the registration of the "javascript" scheme. I do not
think I've received any feedback on it since I published the previous
version a year ago. Earlier feedback [1] [2] [3] should be accounted for
except some requests for elaboration on how the scheme is different or
wrong or dangerous or something along those lines. I had no inspiration
concerning that in the past year, but I am happy to consider proposals
with spec-ready text on that. Otherwise I intend to propose publication
of the document as Informational RFC pretty much as it is.

[1] http://lists.w3.org/Archives/Public/uri/2006Nov/thread.html
[2] http://www.ietf.org/mail-archive/web/uri-review/current/thrd13.html
[3] http://www.ietf.org/mail-archive/web/uri-review/current/thrd14.html

regards,
-- 
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: Wed, 15 Sep 2010 16:13:57 +0200

> [3] http://www.ietf.org/mail-archive/web/uri-review/current/thrd14.html

Hi Björn,

thanks for the work on this.

One major comment I have is that it seems that you define a IRI scheme. 
My understanding was that the current way to do this is that you define 
a URI scheme, and then just let RFC 3987 apply to it, resulting in an 
IRI scheme.

That being said, a few nits...:

>    The first operation, content retrieval, defines which script code a
>    given 'javascript' resource identifier represents.  This operation is
>    fully defined in this document and some applications might take
>    advantage of only this operation.

Maybe "content retrieval" is misleading -- after all, nothing is being 
retrieved. Maybe "content identification" or "script code identification"?

>    A resource identifier conforms to this specification if and only if
>    it is a valid IRI and application of the content 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.

This implies that most javascript URIs are invalid due to the use of SP 
characters. There's nothing we can do about it, but maybe it should be 
mentioned.

Q: will implementations treat %20 properly?

>       3.  If the sequence starts with the sequence 0xEF 0xBB 0xBF (the
>           UTF-8 signature, or byte order mark), discard this sequence.

"this sequence" is ambiguous here :-)

>    For instance, a 'javascript' resource identifier might be embedded in
>    a HTML document and depened on properties of the document.  A typical

"depend"

>    The in-context evalutation operation necessitates extreme caution in

"evaluation"

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 17 Sep 2010 08:17:01 +0200

>a URI scheme, and then just let RFC 3987 apply to it, resulting in an 

That is an invalid distinction. IRIs are URIs except that they permit a
greater set of unreserved characters; implementations are required to
treat unreserved characters appearing literally the same as they would
treat their percent-encoded form, so you cannot make a "IRI scheme" that
would somehow be different from the corresponding "URI scheme" without
violating constraints of the URI or IRI specification. RFC 3987 in fact
explicitly notes there is no such thing as an "IRI scheme".

RFC 3987 requires to avoid and delay turning unreserved characters into
their percent-encoded equivalent to the extent possible. That is what
the draft does, it defines when a resource identifier conforms to the
specification and how to retrieve the source text from it regardless of
what form it is in. If I defined this only for URIs then IRIs would have
to be transformed into URIs always; that is not necessary here, so doing
that would be contrary to RFC 3987.

>retrieved. Maybe "content identification" or "script code identification"?

The first sense on http://en.wiktionary.org/wiki/retrieve#English is to
"regain or get back" which seems exactly right here. "Script retrieval"
wouldn't be quite right, but I could consider "source text retrieval" if
you find that much better. "Identification" seems worse in any case.

>Q: will implementations treat %20 properly?

As far as I am aware, percent-encoding works as much as anything works
in web browsers. I do not think there is anything special about spaces
that needs to be discussed specifically for this scheme.

Thanks for pointing out the typos, I will see that they get fixed.
-- 
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, 17 Sep 2010 08:52:33 +0200

> explicitly notes there is no such thing as an "IRI scheme".

Agreed. I don't think what you do is incorrect *technically*, just 
process-wise.

The risk in doing it the way you do indeed *is* to create something that 
doesn't conform to RFC 3987. That's probably not the case here, though.

> that would be contrary to RFC 3987.

Hm?

The scheme can't change the requirements of the context the identifiers 
appear in.

If you need a URI, you need it, no matter what the scheme definition says.

Why is "javascript:" different here from HTTP, FTP, or even ABOUT?

Now, in practice "javascript" is used in HTML, and the HTML(5) speac 
already states that the markup takes (a superset of) IRIs, so I'm not 
sure what the problem is.

> you find that much better. "Identification" seems worse in any case.

Replacing "content" with the more specific "source text" sounds good to me.

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 17 Sep 2010 10:06:51 +0200

>sure what the problem is.

The content retrieval operation is much like HTTP GET. To "GET" a "http
IRI" you have to turn the IRI into a URI in order to meet constraints of
the HTTP protocol, which only allows URIs as Request-URI. To "GET" a
"javascript IRI" such a step is unnecessary and should thus be avoided
(keep in mind that IRI->URI conversion can be destructive, for instance,
if the IRI contains U+212A, the URI may end up with a "K" instead, see
the aptly numbered issue #23 in the IRI Working Group's issue tracker).
-- 
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, 17 Sep 2010 10:23:43 +0200

> "javascript IRI" such a step is unnecessary and should thus be avoided

I didn't say that it always needs to be converted. All I said is that it 
should be sufficient to define the URI syntax, and let the RFC 3987 
default handling imply the IRI form. As far as I know, that's the 
current practice in defining URI schemes.

The next thing I was going to do was check your URI registration 
template, but you don't have one. Why?

> the aptly numbered issue #23 in the IRI Working Group's issue tracker).

I consider this a bug in the IRI spec which needs to be fixed.

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 17 Sep 2010 12:16:43 +0200

>template, but you don't have one. Why?

It's not mandatory http://www.w3.org/mid/[email-masked] and
the fields would just be "See section ..." naming all the sections in
the document apart from the front page. That'd be a table of contents.
-- 
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, 17 Sep 2010 12:24:42 +0200

> the document apart from the front page. That'd be a table of contents.

Well, it would be useful to actually find the parts the template requires.

So, for instance, where are the Encoding Considerations?

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 17 Sep 2010 12:48:09 +0200

>So, for instance, where are the Encoding Considerations?

I believe the established practise is to discuss issues of character
encoding and internationalization in a section "Internationalization
Considerations", that is where the draft addresses this. You can find
the permissable syntax defined in the section on Conformance, the se-
mantics are essentially defined under Operations (which is so named as
RFC 4395 calls for the Definition of Operations and as you can find in
the previous discussion of the draft on this and the [email-masked] list,
some find "semantics" an unsuitable or confusing term for this scheme).

Security Considerations are under Security Considerations, the Inter-
operability Considerations under Interoperability Considerations, the
References under References, Contact information under Author's Address,
Author/Change controller is not applicable here, and "Applications/
protocols that use this URI scheme name" is in the Introduction. The
name of the scheme and the intended status are in the IANA consider-
ations. I am pretty sure it's all there and easy to locate.
-- 
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, 17 Sep 2010 13:31:54 +0200

On 17.09.2010 12:48, Bjoern Hoehrmann wrote:
> ...
> ...

That says:

6. Internationalization Considerations

    None beyond those inherent to resource identifiers and entities of
    type application/javascript.  Characters are encoded using UTF-8.

RFC 4395 asks in <http://tools.ietf.org/html/rfc4395#section-2.6>:

2.6. Internationalization and Character Encoding

    When describing URI schemes in which (some of) the elements of the
    URI are actually representations of human-readable text, care should
    be taken not to introduce unnecessary variety in the ways in which
    characters are encoded into octets and then into URI characters; see
    RFC 3987 [6] and Section 2.5 of RFC 3986 [5] for guidelines.  If URIs
    of a scheme contain any text fields, the scheme definition MUST
    describe the ways in which characters are encoded, and any
    compatibility issues with IRIs of the scheme.

So if I'd take the definition in your spec literally, I would end up 
with UTF-8 in javascript URIs. But what it should say is UTF-8 encoded, 
then percent-escaped, right?

(And yes, it would be great if a successor of RFC4395 would make it 
clearer and actually state the default handling)

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 17 Sep 2010 14:04:19 +0200

>then percent-escaped, right?

The characters in a URI that do not separate components are just fancy
representations for octets, "A" stands for 0x41, and so does %41. The
statement above is just saying the octets represented by the scheme-
specific part are characters in the UTF-8 character encoding. If it'd
specify UTF-16BE, then javascript:!& would have a scheme-specific part
that decodes to U+2126, the ohm sign. I could change the text so some-
thing like "The scheme-specific part represents characters using the
UTF-8 character encoding", but I do believe the current text is clear,
it's already just restating the effect of  the retrieval operation.
-- 
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, 17 Sep 2010 14:13:58 +0200

> it's already just restating the effect of  the retrieval operation.

You make it sound like this:

   javascript:alert("Hallo%20Björn")

(where "ö" is replaced by the octet sequence representing o umlaut in UTF-8)

is a valid javascript URI.

I think what's needed is a statement that characters not allowed in a 
URI need to be encoded, and how (that's my interpretation of RFC 4395, 
but maybe I imagine that).

With that, I'll leave it to the Expert Reviewer and the IETF process :-)

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 17 Sep 2010 15:12:38 +0200

>but maybe I imagine that).

It is common that character encodings encode the character "A" with the
octet 0x41, and in URIs you can represent the octet 0x41 using "A", and
that may make it seem as if "A" is somehow different from "ö" here, but
it is not; what is needed is saying how all characters map to octets,
for "A" and "ö" alike. I say "A" maps to 0x41 and "ö" maps to 0xC3 0xB6;
the URI specification says that "A%c3%B6", "%41%C3%b6", and so on, re-
present that octet sequence.
-- 
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, 17 Sep 2010 15:25:04 +0200

> present that octet sequence.

RFC 3986, Section 2:

"The URI syntax provides a method of encoding data, presumably for the 
sake of identifying a resource, as a sequence of characters."

Not octets.

The character repertoire is ASCII (minus delimiters). If an identifier 
contains characters outside this range, it needs to be mapped to a 
sequence of (ASCII) *characters* to create a legal URI.

I think we all agree how that mapping needs to work, so why not say it?

Best regards, Julian

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 01 Oct 2010 15:43:29 +0900

Hello Julian, Björn,

[cross-posting [email-masked]]

I have tried to follow your discussion in the thread started by the mail 
below (for the IRI WG: that mail is at 
http://www.ietf.org/mail-archive/web/uri-review/current/msg01215.html; 
the rest of the thread can easily be reached from that mail with the 
'Date Prev' button, sometimes jumping over another thread).

However, especially in respect to the question of whether to define an 
IRI scheme or an URI scheme, I think it would be much more productive to 
try and see whether this scheme proposal fits
http://www.ietf.org/id/draft-hansen-iri-4395bis-irireg-00.txt
(which allows registration of new schemes both as URIs and as IRIs and 
makes clear that there is only one registry), and on the other hand 
check whether draft-hansen-iri-4395bis-irireg is written so that it 
allows to do what works best in the case of the 'javascript:' scheme.

[followups please only to one or the other list, thanks]

Regards,    Martin.

On 2010/09/15 23:13, Julian Reschke wrote:
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>
>

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