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

Hello Julian, Björn,

[cross-posting public-iri@w3.org]

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:
> On 15.09.2010 15:52, Bjoern Hoehrmann wrote:
>> 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,
>
> 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
> _______________________________________________
> Uri-review mailing list
> Uri-review@ietf.org
> https://www.ietf.org/mailman/listinfo/uri-review
>
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp