Closed Bug 130089 Opened 22 years ago Closed 9 years ago

[meta] URL: schemes should be named correctly ("wyciwyg", "keyword", etc.)

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: benc, Unassigned)

References

Details

(Keywords: meta) 

There are RFC's that describe the naming of URL schemes and their syntax.

On many occassions, we have demonstrated a disregard for these rules, and I've
had my fill of it.

Here's a couple examples:

1- Not using "X-" for schemes that are not accepted by IANA.

Things like "engine:" and "keyword:" are wrong. If you can't prove that the
scheme is registered and you are using it correctly, implement it with the "X-"
so everyone knows you are making something up.

2- Not using vendor strings (both Netscape and Mozilla do this wrong).

For example, really cryptic, barely making sense and unspecified URL schemes
like: "wyciwyg". If you really meant to make it so this is used in your
products, and you could not credibly conceive that anyone one else would (and
that you would share your intentions with an RFC), then register for the vendor
namespace and put your creations in your namespace, rather than cluttering up
the root level.

3- Incorrectly formated usage of RFC URLs:

Internally, news: URLs include a hostname|IP + port number. This is not how it
is describedin RFC 1738.

Take the advice given above in point #1 and #2. People have already started to
cut and paste these URLs into web pages, which might not make sense to other
browsers.
Speaking of #3, mozilla assumes that the @ in the path component of a 
news URL should always be replaced with %40 yet there is no RFC that 
requires that.
if we switched back to a grandfathered protocol could we keep the short name?
timeless: I'm not sure what you mean.
Ben: I find it refreshing that there are folks within AOL who care about this.
I've brought this up in the past, but the issue was dimissed. I'm not sure how
much help I can be, but I'll do what I can. I'm afraid this will be an uphill
battle, though.

It seems to me that the issues with "news" are separate from naming and thus
warrant a separate bug report.

Good point, maybe this should really be a meta bug...
Keywords: meta
Summary: URL schemes should be named correctly ("wyciwyg", "news", "keyword", etc.) → [meta]URL schemes should be named correctly ("wyciwyg", "news", "keyword", etc.)
Maybe it should be; but I really think we should wait until there are bugs for a
meta bug to track. Before filing those bugs, I think we should take this space
(or space on a newsgroup) to test the water and see if fixing this bug is really
tractable. There are political and legacy issues.

timeless: IMO, they should go away. The Problem is that Mozilla is invading a
governed public namespace. Just adding synonymous schemes doesn't fix the
problem; the offending identifiers need to be eliminated.

I have filed the news scheme issues in bug 133792 and bug 133793, and I modified
this bug's summary to remove "news".
Keywords: meta
Summary: [meta]URL schemes should be named correctly ("wyciwyg", "news", "keyword", etc.) → URL schemes should be named correctly ("wyciwyg", "keyword", etc.)
QA futuring of various bugs to focus on remaning bugs. If you think your bug
needs immediate attention for Mozilla 1.0, set the milestone to "--". I will
review these bugs (again) later.
Target Milestone: --- → Future
Keywords: meta
Summary: URL schemes should be named correctly ("wyciwyg", "keyword", etc.) → [meta] URL: schemes should be named correctly ("wyciwyg", "keyword", etc.)
Depends on: 953
mozilla does not escape the @ in a path component, if that happens mozilla must
take the segment as something else, the hostname perhaps. This is of course
possible because mozilla can't handle news:something urls. It will make
something the host. 

There are already a lot of bugs about this.

Oh yes, the news versus nntp thing ... we say news when mean nntp. The problem
also lies deeply burried with the structure of the mailnews component. 

In necko we know nsStandardURLs (hierachical) and nsSimpleURLs (flat, only
scheme:something). nntp is hierachical, news is simple. Mailnews defines its own
mailnewsurl which descents from nsStandardURL. The news url is based on
nsMailNewsURL which makes it hierachical ... as long as mailnews does not start
to use the necko URIs directly (or also havve a simple mailnewsurl) and make
news a simple uri there is no way this can be fixed.

But of course this will break the current usage of news urls which means we need
a preparser that looks at the structure of the url and then changes the scheme
accordingly before giving it to the real parser.
Regarding point 3.

The news URLs Mozilla implements are include extentions from
draft-gilman-news-url-00. It's unfortunate they never became official, because
news: is relatively useless without them. Since I don't ever install MailNews, I
wrote a little perl script that groks RFC 1738 + draft-gilman news: URLs. It's
ugly and unfinished, but it's worked like a champ for me for months. I'll throw
it up on my site in a few minutes... it'll be:

http://turbogeek.org/code/nurl

I believe Netscape 4.x did news: URLs the same way.

> Oh yes, the news versus nntp thing ... we say news when mean nntp.

No, we don't. nntp: has a different syntax. They're compared in the help output
of my script above (conveniently at the top of the source).
Jeremy: Good enough for me. I've marked bug 133792 INVALID. Bug 133793 is still
an issue, though. In URL-encoding the '@', Mozilla isn't representing RFC 1738
or  Gilman news: URLs correctly; and it's not correctly processing said URLs
that *are* represented correctly.
Depends on: 15372
Why does this bug depend on bug 953 and bug 15372? Neither of those bugs has to
do with correcting the URI schemes.
They are examples of schemes that are not named correctly.

They should all have an X- in front of them...

So? The bugs aren't about correcting the scheme names. And resolving those bugs
has brought this meta bug no closer to resolution. Or are you suggesting that
bug 953 and bug 15372 need to be reopened?

This is a tracking bug. We use the fields we got, I could say this bug "blocks"
them instead, but tha would make even less sense.

The dependency relationship is exactly what you want for a tracking bug. When
all the dependencies are resolved, the tracking bug goes away. Thus, resolving a
tracking bug's dependencies *does* bring the tracking bug closer to resolution.
That's clearly not happening here.

If you think it's appropriate to have a bug for each bogus URI scheme and have
those bugs block this one, that would make sense. But what this bug is being
used for now makes no sense at all. Either those bugs should be filed, or this
should not be a tracking bug.

Is this bug actually being used or usefull to anyone anymore, or can i kill it?
What do you mean by "useful"? Are you asserting that Mozilla should continue to
violate IETF guidelines for proprietary URI schemes? If not, do you have an
alternative proposal for addressing the problem (or at least noting it, which is
all this bug does)?

Travis: I don't know about other reporters, but I'd like to think all my bugs
are useful:)

Do you have an objection to the bug report itself? If not, please don't go into
bugs proposing they get closed, esp. if you are not carrying a lot of cred for
the area. 
keyword: was removed for FF 2.0. I guess that's progress.
Depends on: 337339
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.