javascript URI scheme not registered - spec seems to be missing

Digging around a question recently posed to me reveals that the commonly-used
(pseudo-)URI scheme 'javascript:' is not registered [1], and I also note that
the specification [3] noted by one web site [2] is no longer available.

BTW, the web page [4] ("What schemes are out there?") might be a useful resource
in considering what schemes might be candidates for provisional registration
(possibly with health warnings) if they're not already registered.

#g
--

[1] http://www.iana.org/assignments/uri-schemes.html

[2] http://esw.w3.org/topic/UriSchemes/javascript

[3] http://developer.netscape.com/docs/manuals/js/client/jsref/index.htm (no
longer available)

[4] http://esw.w3.org/topic/UriSchemes

--

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Re: javascript URI scheme not registered - spec seems to be missing

Hello Graham,

I noticed there was one URI scheme missing from that list of known URI schemes.

In the old Netscape Navigator web browsers, there was something like a
WYSIWYG URI scheme.  (Although I think it wasn't exactly "WYSIWYG"...
but had one of the letters different.)

I remember it coming up every now about then when you were just going
about normal web browsing.  (Back then I thought it was some kind of
bug that made it show up.)

Not sure if anyone else remembers this.

On 9/4/06, Graham Klyne <GK <at> ninebynine.org> wrote:
> Digging around a question recently posed to me reveals that the commonly-used
> (pseudo-)URI scheme 'javascript:' is not registered [1], and I also note that
> the specification [3] noted by one web site [2] is no longer available.
>
> BTW, the web page [4] ("What schemes are out there?") might be a useful resource
> in considering what schemes might be candidates for provisional registration
> (possibly with health warnings) if they're not already registered.
>
> #g
> --
>
> [1] http://www.iana.org/assignments/uri-schemes.html
>
> [2] http://esw.w3.org/topic/UriSchemes/javascript
>

Volunteer needed to serve as IANA charset reviewer

The Applications Area is soliciting volunteers willing to serve as the
IANA charset reviewer.  This position entails reviewing charset registrations
submitted to IANA in accordance with the procedures set out in
RFC 2978.  It requires the reviewer to monitor discussion on the
ietf-charsets mailing list (moderating it, if necessary); it also requires
that the reviewer interact with the registrants and IANA on the
details of the registration.  There is currently a small backlog, and
it will be necessary to work to resolve that backlog during the initial
period of the appointment.

If you are willing to serve in this capacity, please notify the
ADs by September 20th, 2006.  A short summary of your experience
in the area should be included.

Re: Volunteer needed to serve as IANA charset reviewer

(IETF list removed, since this is about to become specialized)

--On Wednesday, 06 September, 2006 11:04 -0700 Ted Hardie
<hardie <at> qualcomm.com> wrote:

> The Applications Area is soliciting volunteers willing to
> serve as the IANA charset reviewer.  This position entails
> reviewing charset registrations submitted to IANA in
> accordance with the procedures set out in RFC 2978.  It
> requires the reviewer to monitor discussion on the
> ietf-charsets mailing list (moderating it, if necessary); it
> also requires that the reviewer interact with the registrants
> and IANA on the details of the registration.  There is
> currently a small backlog, and it will be necessary to work to
> resolve that backlog during the initial period of the
> appointment.
>...

Perhaps the need for a new volunteer in this area is the time to
ask a broader question: 

At the time 2978 (and its predecessor, 2278) were defined, there
were a large number of charsets in heavy use and there was some
general feeling in the implementer community that, despite the
provisions of RFC 2277, Unicode/ISO 10646 were not quite ready.
Although we probably still have some distance to go (the issues
with my net-Unicode draft may be illustrative), I wonder if we
are reaching the point at which a stronger "use Unicode on the
wire" recommendation would be in order.   The implications of
such a recommendation would presumably include a 2978bis that

Re: Volunteer needed to serve as IANA charset reviewer

On Sep 6, 2006, at 11:45 AM, John C Klensin wrote:

> I wonder if we
> are reaching the point at which a stronger "use Unicode on the
> wire" recommendation would be in order.   The implications of
> such a recommendation would presumably include a 2978bis that
> made the requirements for registration of a new charset _much_
> tougher, e.g., requiring a demonstration that the then-current
> version of Unicode cannot do the relevant job and/or evidence
> that the newly-proposed charset is needed in deployed
> applications.

Yes, please.  Unicode is not perfect, but it's actually very good in  
quite a few different ways, and network effects have pretty well  
taken over, so if you're doing any text on the network at all, it's  
almost certainly the right thing to use Unicode.

As a Certified Unicode Bigot(tm) I would volunteer to help with such  
a redraft.

  -Tim

Re: Volunteer needed to serve as IANA charset reviewer

> (IETF list removed, since this is about to become specialized)

> --On Wednesday, 06 September, 2006 11:04 -0700 Ted Hardie
> <hardie <at> qualcomm.com> wrote:

> > The Applications Area is soliciting volunteers willing to
> > serve as the IANA charset reviewer.  This position entails
> > reviewing charset registrations submitted to IANA in
> > accordance with the procedures set out in RFC 2978.  It
> > requires the reviewer to monitor discussion on the
> > ietf-charsets mailing list (moderating it, if necessary); it
> > also requires that the reviewer interact with the registrants
> > and IANA on the details of the registration.  There is
> > currently a small backlog, and it will be necessary to work to
> > resolve that backlog during the initial period of the
> > appointment.
> >...

> Perhaps the need for a new volunteer in this area is the time to
> ask a broader question:

> At the time 2978 (and its predecessor, 2278) were defined, there
> were a large number of charsets in heavy use and there was some
> general feeling in the implementer community that, despite the
> provisions of RFC 2277, Unicode/ISO 10646 were not quite ready.
> Although we probably still have some distance to go (the issues
> with my net-Unicode draft may be illustrative), I wonder if we
> are reaching the point at which a stronger "use Unicode on the
> wire" recommendation would be in order.   The implications of
> such a recommendation would presumably include a 2978bis that

Re: Volunteer needed to serve as IANA charset reviewer

I concur with the need to maintain the current charset registry to
support legacy apps that use it.  

And I think Ned would be an excellent choice for reviewer, though it
wouldn' t bother me if he could have the assistance of people with
specialized expertise in Asian writing schemes.

As for utf-8 vs. Unicode, this is a bit tricky.  I agree that merely
specifying Unicode isn't sufficient given the potential for
incompatible CESs.  And yet I'm sympathetic to the notion that UTF-8
pessimizes storage and transmission of text written in certain
languages.  IMHO it's unreasonable to exclude the potential for a
Unicode based CES that has more-or-less equivalent information
density across a wide variety of languages.  But I do think that use of
multiple CESs in a new protocol should require substantial
justification, and that UTF-8 should be presumed to be the CES of
choice for any new protocol that requires ASCII compatibility for its
character representation.

Keith

Re: Volunteer needed to serve as IANA charset reviewer

[ My apologies for replying to a reply ]

Ned Freed <ned.freed <at> mrochek.com> wrote:

>>I wonder if we are reaching the point at which a stronger "use Unicode on
>>the wire" recommendation would be in order.   The implications of such a
>>recommendation would presumably include a 2978bis that made the requirements
>>for registration of a new charset _much_ tougher, e.g., requiring a
>>demonstration that the then-current version of Unicode cannot do the
>>relevant job and/or evidence that the newly-proposed charset is needed in
>>deployed applications.

The time is, IMO, certainly ripe for pushing UTF-8 much stronger, but the place
to do so is *not* at IANA — the registry of assigned names and numbers; protocol
values — but rather in the development of new specifications.

Not even the Unicode Consortium envisions a mass conversation of all legacy
content into, say, UTF-8. The IANA registry's documentary function is quite
orthogonal to the desire to avoid defining new charsets or mandating or even
just enabling legacy charsets in new specifications.

If a charset exists it should, modulo other factors, be registered with IANA.

--

-- 
Everytime I write a rhyme these people thinks its a crime
I tell `em what's on my mind. I guess I'm a CRIMINAL!
I don't gotta say a word I just flip `em the bird and keep goin,
I don't take shit from no one. I'm a CRIMINAL!

Re: Volunteer needed to serve as IANA charset reviewer

Re: Volunteer needed to serve as IANA charset reviewer

On Sep 6, 2006, at 2:45 PM, Keith Moore wrote:

> As for utf-8 vs. Unicode, this is a bit tricky.  I agree that merely
> specifying Unicode isn't sufficient given the potential for
> incompatible CESs.  And yet I'm sympathetic to the notion that UTF-8
> pessimizes storage and transmission of text written in certain
> languages.  IMHO it's unreasonable to exclude the potential for a
> Unicode based CES that has more-or-less equivalent information
> density across a wide variety of languages.  But I do think that  
> use of
> multiple CESs in a new protocol should require substantial
> justification, and that UTF-8 should be presumed to be the CES of
> choice for any new protocol that requires ASCII compatibility for its
> character representation.

Agreed on all counts.  Section 5.1 of RFC3470 (aka BCP70) says smart  
things about this, referencing 2277.  Basically, if you're going to  
use XML, there's probably no point trying to legislate against UTF-16  
since any conformant reader is required to accept it, and in practice  
all known XML software can handle 8859 and Shift-JIS and EUC.   But  
if you're not doing XML, compulsory UTF-8 removes a lot of failure  
points without costing much.

   -Tim