Closed Bug 130089 Opened 23 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.