Re: Literal slashes in javascript: IRIs

On Nov 23, 2007, at 13:14, Bjoern Hoehrmann wrote:

> * Henri Sivonen wrote:
>> http://tools.ietf.org/html/draft-hoehrmann-javascript-scheme-00 says:
>>> Use of a byte order mark and literal use of the character "/" should
>>> be avoided.
>>
>> The latter requirement seems impractical. Why is this requirement
>> present? Could it be relaxed?
>
> How is it "impractical"? This essentially replicates RFC 4395 2.2,
>
>  URI schemes that are not intended for use with relative URIs SHOULD
>  avoid use of the forward slash "/" character, which is used for
>  hierarchical delimiters, and the complete path segments "." and ".."
>  (dot-segments).
>  ...
>  URI schemes that do not contain a conformant hierarchical structure
>  in their <scheme-specific-part> SHOULD NOT use double slashes
>  following the "<scheme>:" string.
>
> Which of these would you want me to break with,

Preferably both, although being able to use javascript://... is not  
that important.

> and what argument could I use to persuade the IETF community, the  
> IESG, and the URI Scheme re-
> viewer that either or both must be optional for 'javascript:'?

The "running code" part of "rough consensus and running code" says  
that an unescaped slash works just fine and, moreover, most likely has  
to be supported in order to be able to deal with existing content.  
Thus a validator telling its users to escape slashes would waste its  
users' time for no tangible benefit. Stipulating machine-checkable  
conformance requirements is pointless if you aren't expecting  
validators to check for those requirements.

> Note that my text is "should be avoided" which is slightly weaker  
> than a possible "SHOULD NOT use" with RFC 2119 implications,

Yeah, it looked like something that was written as a token gesture to  
the theorists but is expected to get ignored in practice.

> precisely because using the slashes ala javascript:example('example/ 
> example.html') is quite common.

That's an argument the IETF communtity, the IESG and the reviewer  
should consider.

> The same can be done for slashes (you would define e.g. an attribute  
> by
> saying the value is a string that is turned into a resource identifier
> reference by doing something about backslashes, spaces, ... and if it
> starts with 'javascript:' you escape slashes, #, etc. as necessary,  
> and
> then process the result as IRI Reference or whatever; a conformance
> testing tool would then not report a warning since by the time it  
> checks
> for scheme-conformance the slashes would be gone). This is not pretty,
> but it would not be pretty either to define that the #example part is
> actually content and break with the RFC 4395 requirements above.

That's one possibility, but it would be much more useful if the specs  
for IRIs/URIs actually suited the original and most common use case-- 
use in HTML href attributes--without definitional preprocessing  
gymnastics.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Friday, 23 November 2007 17:45:54 UTC