remove non-compliant text/xul mimetype.

RESOLVED FIXED in mozilla1.0

Status

()

defect
P3
normal
RESOLVED FIXED
20 years ago
18 years ago

People

(Reporter: braden, Assigned: braden)

Tracking

Trunk
mozilla1.0
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(7 attachments)

Assignee

Description

20 years ago
The content type currently used to identify XUL ("text/xul") is not a valid type
(that is, no such type has been assigned by IANA/ICANN) or an experimental type.

Updated

20 years ago
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → REMIND

Comment 1

20 years ago
Yeah-- fine. But it's an internal type, and I'm not altogether sure that it 
matters.
Assignee

Comment 2

20 years ago
What do you mean "it's an internal type"? XUL is a new XML application that
Mozilla will be presenting to Web developers everywhere. What's internal about
that?

Mozilla is Open Source. It should follow standard protocols, not trample them.
This matters.
Status: RESOLVED → REOPENED
Resolution: REMIND → ---

Comment 3

20 years ago
I'll take this.
Status: REOPENED → ASSIGNED
Target Milestone: M19

Comment 4

20 years ago
XUL is currently an internal XML schema that NETSCAPE invented for it's own 
purpose and (naturally) contributed to mozilla. We're not presenting this to web 
developers at this time; nor are we preventing them from using it. However, a 
lot of work must occur before this becomes anything like a web standard.

Hyatt: What is your intention?
Assignee

Comment 5

20 years ago
Then why are you impinging upon the MIME namespace by adopting their notation
and usage for something you seem to claim is unrelated?

In fact, it *isn't* unrelated, and RFC2048 makes ample accommodations for this
situation. The type "text/xul" is wrong and should be corrected. Your comments
confirm that it belongs in the vendor subtree, though they call into question
whether the vendor would be mozilla.org or Netscape. I should add here that the
notion that XUL falls under the authority of Netscape and not mozilla.org is
disturbing--I was not aware that Mozilla would be supporting closed, proprietary
formats.

Finally, your assertion that XUL has not been presented to Web developers is
patently wrong--it has been presented widely both through the open source
process and documentation among the mozilla.org Web pages.

The notion that a format must be a "Web standard" (quoted because I'm not really
sure what the qualifications for that title are) to have a registered MIME type
is also probably fallacy--just look at the list of existing types:

  <URL:http://www.isi.edu/in-notes/iana/assignments/media-types/media-types>

Comment 6

20 years ago
I agree with your assertion that using a vendor specific mimetype is the answer. 

As to your point about XUL/web developers: you're grossly underestimating the 
necessity of working within the realm of standards. It may be some time before 
we can work through the W3C processes to establish XUL as a standard. Netscape's 
history is littered with proprietary extensions, and it is not our objective to 
further fractionalize the web by unilaterally mandating new ones. Netscape plans 
to utilize XUL for it's own purposes, and invites third party developers to do 
the same. We will officially support XUL as a standard if and when it becomes 
one. Mozilla is free to act as it sees fit -- and you are of course free to 
behave according to your conscience.
Assignee

Comment 7

20 years ago
I think we just might be in agreement. I have made no assertion that XUL should
be presented to the W3C for standardization. Erik van der Poel is the one who
presented this *possibility* on the newsgroup
(<URL:news://news.mozilla.org/38A9C226.7DF332C0%40netscape.com>).

My contentions are:

 * The "xul" subtype belongs in the IETF subtree if and only if XUL is a
vendor-independent standard. (And I do consider mozilla.org a vendor and not a
standards body.)

 * As long as XUL is not a vendor-independent standard, the "xul" subtype
belongs in the vendor subtree when it is registered.

 * In either case, a MIME type needs to be registered--unless a subtype in the
experimental subtree is used (and I do not think that is a desirable
alternative).

Thus, my agreement with Erik's proposal of "text/vnd.moz.xul"
(<URL:news://news.mozilla.org/38A9C89E.89DABF6A%40netscape.com>).

Comment 8

20 years ago
My intent was to ignore it for a while (probably forever).  I don't think this 
is a big deal at all.  I think we could call it "foopy/goopy" and it wouldn't 
make a damn bit of difference.
Assignee

Comment 9

20 years ago
That's nice.

What, pray tell, is the grounds for the obvious aversion to registering a MIME
type?

Comment 10

20 years ago
I'm telling you I don't give a rat's ass.  I have more important things to worry 
about than the MIME type of XUL, like, say, making things actually work.  

Call it whatever you want.
Assignee

Comment 11

20 years ago
Yes, it's quite apparent that there's a good deal of nonchalance within Netscape
where MIME type procedures are concerned. A legacy of the historical disregard
for Web standards Rick spoke of, I suppose. Whether failure to RTFM or
deliberate disregard of established convention are the source of the current
bogus type, I can only guess. I just find it peculiar that I'm the one here
accused of "grossly underestimating the necessity of working within the realm of
standards".

Comment 12

20 years ago
In this case, it was failure to RTFM.

Comment 13

20 years ago
Handing over to hyatt to address. Thanks David.
Assignee: rickg → hyatt
Status: ASSIGNED → NEW

Comment 14

20 years ago
Looking for a patch... also pulling in slightly...


Status: NEW → ASSIGNED
Whiteboard: [HELP WANTED]
Target Milestone: M19 → M18

Comment 15

20 years ago
It's nice to hear that most people have reached a consensus that
"text/vnd.moz.xul" should be used. FWIW, Braden, I wholehartedly agree with you
here. You're not the only one who cares about this.

<rant>People who disagree: you have to realize that saying things like "it's an
internal type" just isn't appropriate in an open source project. There's no such
thing as "internal" here. It doesn't matter if Netscape invented it. At some
point, the technology was made part of MOZILLA, and at that moment, it became
very *public*. It's not an endorsed standard, but that doesn't give license to
ignore the RFCs. It's still public, so it should follow the rules.</rant>

Also, to get an idea of how things are from a technical standpoint, I did a
little check:
cx824225-a:~/src/mozilla$ fgrep -rl "text/xul" *
docshell/base/nsDSURIContentListener.cpp
gfx/src/nsImageNetContextAsync.cpp
htmlparser/src/nsIParser.h
layout/build/nsLayoutDLF.cpp
mailnews/base/src/nsMessenger.cpp
mailnews/base/src/nsMsgWindow.cpp
mailnews/compose/src/nsMsgQuote.cpp
mailnews/mime/build/nsMsgMimeCID.h
mailnews/mime/emitters/build/nsMimeEmitterCID.h
mailnews/mime/src/nsStreamConverter.cpp
mailnews/mime/tests/mimetest/mimetest.cpp
netwerk/mime/public/nsMimeTypes.h
rdf/content/src/nsXULDocument.cpp
xpfe/browser/src/nsBrowserInstance.cpp
xpfe/components/directory/nsDirectoryViewer.cpp
cx824225-a:~/src/mozilla$ 

That's 15 files -- not *too* bad. Maybe I'll make a patch. I'm not sure it's as
simple as replacing "text/xul" everywhere, tho. I'll have to investigate.

Comment 16

20 years ago
If you make a patch and it passes the pre-checkin tests, I will accept it.
Assignee

Comment 17

20 years ago
Thanks for the assistance here, Keith.

Note that this bug report speaks to the validity of the type in use. Changing to
another unregistered type--unless the change is to an experimental
type--shouldn't affect the status of this bug report.

Comment 18

20 years ago
Right. The bug can be marked fixed as soon as the type is registered, which will
probably be after the change is checked in. Who should do that? Me? Braden?
Dave? Anybody?

I've got the changes sitting here, but they're for vnd.moz.xul, and I've got to
update that to vnd.mozilla.xul. Once that's done, (and I rebuild and test), I'll
post the patch.

Comment 20

20 years ago
Well, there it is. It passes the pre-checkin tests in my tree. Once it is
checked in, someone should make an announcement on the newsgroups to let
everybody know to reconfigure their web servers.

Now we just need to get it registered.
Assignee

Comment 21

20 years ago
Could someone summarize why we need a different content type for cached XUL? Are
we really talking about different representations of the data?
Assignee

Comment 22

20 years ago
Folks, this document has just come to my attention:

  <URL:http://www.ietf.org/internet-drafts/draft-murata-xml-02.txt>

In light of section 6 in this document, I recommend "text/vnd.mozilla.xul-xml".
Assignee

Comment 23

20 years ago
Also of potential importance, from section 3 of the aforementioned document:

   Text/xml and application/xml behave differently when the charset
   parameter is not explicitly specified.  If the default charset
   (i.e., US-ASCII) for text/xml is inconvenient for some reason (e.g.,
   bad WWW servers), application/xml provides an alternative (see
   "Optional parameters" of "3.2 Application/xml Registration").  The
   same rules apply to the distinction between
   text/xml-external-parsed-entity and
   application/xml-external-parsed-entity.

Unless XUL has any need for UTF-16, UCS-4, or UTF-32 (which I am inclined to
doubt), this would appear to be the critical factor in the decision to use
"text" or "application" as the primary type.

Could some XUL authority (Dave?) comment on XUL's requirements in this regard?

Comment 25

20 years ago
Okay, if we want to use the "-xml" suffix, there's a patch for it. If you're 
applying this patch, be sure to do this one *instead* of the earlier patch, 
*not* in addition to it.

Also note that I left the cached xul type as "text/vnd.mozilla.cached-xul" 
since it should not be touched by general-purpose xml parsers. (It may not even 
be xml data if it's pre-parsed or something. I don't know.)

Also, don't worry about the cached xul type. It's only used by layout/xptoolkit 
to communicate within mozilla. The parser and necko don't even know anything 
about it, so if a web server sends "text/vnd.mozilla.cached-xul" mozilla will 
treat it just like any other "unknown" type. The only potential problem is a 
namespace conflict (if someone actually wanted to use that string for a real 
media type), which is not a problem now that it's in the vnd.mozilla subtree.
Assignee

Comment 26

20 years ago
My concern only concern with the "cached" identifier is that, since it is
entirely endemic to the application, it doesn't really fit what appears to be
the application space of the MIME content type namespace. As I mentioned to
Chris Waterson on the newsgroup, I am not sure how the registration authority
will respond to this.

If consistency with the MIME naming scheme must be maintained it *might* be
preferable to use a type in the experimental subtree for this.

Comment 27

20 years ago
For the record, many of the things discussed here are relevant also to
another quiet type, "text/xif" (for the XML Interchange Format that 
Mozilla uses internally).
Assignee

Comment 28

20 years ago
What is the scope of that type, exactly? I mean, what would happen if a server
sent content labeled as "text/xif" that was not the "xif" Mozilla is familiar
with?

If this is a non-issue because Mozilla would treat the content from the server
as it would any other unknown type, it is probably better to rename the xif
content type to something that won't impinge upon the MIME content type
namespace.

If, OTOH, this situation would pose a problem for Mozilla, then we need to see
about registering a type for xif, again probably in the vendor subtree.
Assignee

Comment 29

20 years ago
I have spoken with someone who has experience registering a type in the vendor
subtree, and it appears that no formal documentation is required. Basically we
just need to fill out this form:

  <URL:http://www.isi.edu/cgi-bin/iana/mediatypes.pl>

I can do this, but let me run down my proposed entries to make sure there's
consensus...

1. MIME Media Type Name: text

2. MIME subtype name: vnd.mozilla.xul-xml

3. Required parameters: n/a

4. Optional parameters: n/a

5. Encoding considerations:
     The encoding considerations for text/xml apply.

6. Security considerations:
     XUL shares security issues common to all XML content types. Furthermore,
     certain applications of XUL could potentially present the problem of
     "user interface spoofing", in which users might be presented with an
     interface requesting personal information and artificially designed to
     look like an application or system interface. The measures taken (if any)
     to minimize the possibility of such abuse are left to the implementation.

7. Interoperability considerations: n/a

8. Published specification: n/a

9. Applications which use this media type:
     the Mozilla internet application suite

10. Additional information
   * Magic numbers: n/a
   * File extensions: xul
   * Macintosh File Type Codes: [Can a Mac person comment on this?]
   * OIDs: n/a

11. Person to contact for further information:
   [I'll enter myself here if necessary, but it may be better to have someone
   who can speak as an authority on XUL. Dave?]

   * Intended usage: Common
   * Author/Change controller: mozilla.org

Comment 30

20 years ago
While I'm unsure as to whether or not XBL needs its own MIME type, it may be 
worthwhile to just register it anyway at the same time.  
Assignee

Comment 31

20 years ago
I don't see any harm in just crossing that bridge when we come to it; and
proactively reserving MIME types doesn't strike me as the Right Thing. But if
someone else feels otherwise, or when the need actually arises, a new bug can be
opened to track that registration.

Does the information I posted look accurate and acceptable? Should I list
myself, Hyatt, or someone else as the contact person?

Comment 32

20 years ago
You might want to check out http://www.imc.org/draft-murata-xml.  It looks like 
you've gotten the -xml suffix in place, if I'm reading Bugzilla correctly, but 
you probably want to use application/ rather than text/.  The IETF has been 
unhappy lately with text/ types that aren't really meant for (ordinary) human 
consumption, technically 'casual readers'.
-Simon St.Laurent (simonstl@simonstl.com)

Comment 33

20 years ago
Mass moving M18 bugs to M19
Target Milestone: M18 → M19
Assignee

Comment 34

20 years ago
Ack, sorry for leaving this one hanging.

Unless someone objects before Tuesday, 11 April, I will submit the MIME type
form as specified previously, with only one (important) change: the type I
intend to register is "application/vnd.mozilla.xul-xml", reflecting the
suggestion of Simon St. Laurent.
Keywords: helpwanted

Comment 35

20 years ago
Sounds good to me. You probably want to mention this on the newsgroup as well so
more people have a chance to object.

Also, if no one objects, I will post a patch for that same content type --
"application/vnd.mozilla.xul-xml" -- on the same date. It will only address the
former "text/xul" type; I'm not going to touch the "text/cached-xul" or other
"internal" types (yet). That's a different issue.

Comment 36

20 years ago
Sounds good to me. You probably want to mention this on the newsgroup as well so
more people have a chance to object.

Also, if no one objects, I will post a patch for that same content type --
"application/vnd.mozilla.xul-xml" -- on the same date. It will only address the
former "text/xul" type; I'm not going to touch the "text/cached-xul" or other
"internal" types (yet). That's a different issue.
Assignee

Comment 37

20 years ago
A little later than I'd said, but the application has been submitted. Here is a
copy of it:

Name : Braden McDaniel

E-mail : braden@endoframe.com

MIME media type name : Application

MIME subtype name : Vendor Tree - vnd.mozilla.xul-xml

Required parameters : 

Optional parameters : 


Encoding considerations : 
The encoding considerations for application/xml apply.

Security considerations : 
XUL shares security issues common to all XML content types. Furthermore,
certain
applications of XUL could potentially present the problem of "user interface
spoofing", in which users might be presented with an interface requesting
personal information and artificially designed to look like an application or
system interface. The measures taken (if any) to minimize the possibility of
such abuse are left to the implementation.


Interoperability considerations : 


Published specification : 


Applications which use this media : 
the Mozilla internet application suite

Additional information :

1. Magic number(s) : 
2. File extension(s) : xul
3. Macintosh file type code : ^@



Person to contact for further information :

1. Name : Dave Hyatt
2. E-mail : hyatt@netscape.com

Intended usage : Common 


Author/Change controller : mozilla.org 


Dave, I went ahead and listed you are the person to contact for further info, as
you seem to be the authority on XUL (as well as the owner of this bug). If that
turns out to be inappropriate, it presumably can be changed.

BTW, the message I got when submitting the application said "please allow at
least two weeks for processing."

Comment 39

19 years ago
Okay, that's it. This patch plus the registration that Braden just submitted
should do it.
Assignee

Comment 40

19 years ago
Okay, registration has not succeeded; I got a note indicating that there is a
problem with the application. Here is the pertinent fragment:

> > Optional parameters :
> 
> Since this is an XML-derived type, it needs to be clear whether or not
> XML's charset parameter can be used, and if it can't, how charset
> information is specified.

Hyatt, can you or someone else who can speak authoritatively about XUL comment
with regard to this?

Comment 41

19 years ago
mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-
Target Milestone: M19 → M21
Nominating nsbeta2+ 6/15. If we don't make that, should be nsbeta3 stopper. 
Here's why: defining the MIME type for XUL falls into the category of "things 
that must be gotten right by FCS, because it can't be changed after FCS 
and whatever we do for FCS we're stuck with for all eternity." It's not like a 
missing feature that can be pushed off to FUTURE, because system administrators 
all over the web will configure tens of thousands of servers to match whatever 
MIME type we use at FCS, and we'll be locked in to that MIME type forever. As 
documented in this bug report, the MIME type we currently use, text/xul, 
violates RFC2048. So this is a standards compliance bug, and I've already been 
getting questions on this (e.g. in my presentation at XTech 2000). Better to get 
it right the first time than to be hassled ever after.

Good news is that there is already a patch submitted to implement the needed 
change. Resetting to M17 though it may slip to nsbeta3.

cc:ing rickg as he mentioned that there would be a need to tweak the parser. 
Keith, does you patch take care of that issue as well? If not, would it be 
possible for you to take care off that as well per rick's instructions? We are 
stretched *very* thin right now and any further help you can offer would be 
greatly appreciated! Thanks to you and Braden for your help on this!
Keywords: nsbeta2, nsbeta3
Summary: MIME type for XUL invalid → MIME type for XUL invalid (not compliant with RFC2048)
Whiteboard: [HELP WANTED] → [HAVE FIX]
Target Milestone: M21 → M17
Assignee

Comment 43

19 years ago
As mentioned, this bug is awaiting comment from someone who is an authority on
XML. IMO, it doesn't make sense to apply any patches until we have a content
type registered for XML. Based on previous experience, that will take 2-3 weeks
from whenever the application is submitted--which I will gladly do again as soon
as the aforementioned issue is clarified.

Comment 44

19 years ago
Braden, in the previous comment you say "XML" but I suppose you meant "XUL".
I am not an authority on XUL, but if I may express my opinion, I think it would
be best if XUL simply follows XML's lead in the character encoding area. Perhaps
the XUL registration would then need to explicitly say that character encoding
is indicated in the same way as XML itself?
Assignee

Comment 45

19 years ago
Erik: Yes, I meant XUL. Sorry for the confusion.

I agree that XUL ought to behave per the norm for XML documents--that it should
use the character encoding parameter just as "raw XML" does. The aforementioned
Internet draft ("XML Media Types") says (4.2):

   Optional parameters: charset

      Although listed as an optional parameter, the use of the charset
      parameter is STRONGLY RECOMMENDED, since this information can be
      used by XML processors to determine authoritatively the charset
      of the XML MIME entity. The charset parameter can also be used to
      provide protocol-specific operations, such as charset-based
      content negotiation in HTTP.

      "utf-8" (see [RFC2279]) and "utf-16" ([RFC2781]) are the
      recommended values, representing the UTF-8 and UTF-16 charsets,
      respectively. These charsets are preferred since they are
      supported by all conforming processors of [XML].

      If an application/xml entity is received where the charset
      parameter is omitted, no information is being provided about the
      charset by the MIME Content-Type header. Conforming XML
      processors MUST follow the requirements in section 4.3.3 of [XML]
      that directly address this contingency. However, MIME processors
      that are not XML processors should not assume a default charset
      if the charset parameter is omitted from an application/xml
      entity.

      There are several reasons that the charset parameter is
      authoritative.  First, recent WWW servers have been improved so
      that users can specify the charset parameter.  Second, [RFC2130]
      specifies that the recommended specification scheme is the
      "charset" parameter.

      On the other hand, it has been argued that the charset parameter
      should be omitted and the mechanism described in appendix F of
      [XML] (which is non-normative) should be soley relied on.  This
      approach would allow users to avoid configuration of the charset
      parameter; an XML document stored in a file is likely to contain
      a correct encoding declaration or BOM (if necessary), since the
      operating system does not typically provide charset information
      for files.  If users would like to rely on the encoding
      declaration or BOM and to hide charset infromation from
      protocols, they may determine not to use the parameter parameter.

      Since the charset parameter is authoritative, the charset is not
      always declared within an XML encoding declaration. Thus, special
      care is needed when the recipient strips the MIME header and
      provides persistent storage of the received XML MIME entity
      (e.g., in a file system). Unless the charset is UTF-8 or UTF-16,
      the recipient SHOULD also persistently store information about
      the charset, perhaps by embedding a correct XML encoding
      declaration within the XML MIME entity.

A pertinent question at this point: Does the current XUL implementation conform
to this description?

Comment 46

19 years ago
I don't know. It would be good to get this tested. Any volunteers?

Comment 47

19 years ago
I'm not sure what sort of tweak would be necessary. My patch changes one line in
htmlparser/src/nsIParser.h. It doesn't touch any of the actual logic. However, I
have tested it and everything seems to work correctly. Perhaps the difference is
subtle and I'm not noticing. Could someone please elaborate on how the parser is
involved in this?

If additional work is needed, I'm more than willing to help out as long as I
have a clear understanding of what is required.

Comment 48

19 years ago
[nsbeta2-] won't hold NSBeta2 for this, but module owner could still apply this 
patch.
Whiteboard: [HAVE FIX] → [nsbeta2-] [HAVE FIX]

Comment 49

19 years ago
Status update, guys?  Are we ready to land?
Braden, Keith: FYI, here's the situation: The Netscape PDT has marked this 
[nsbeta2-], which means that Netscape resources won't be expended to check this 
in. *However*, this doesn't prevent you as independent contributors from 
checking it in yourselves if you're willing to take responsibility for that 
(making sure you don't break the tree, dealing with any side effects, etc.). To 
do that, here is the procedure to follow IIRC: (1) get the permission of the 
relevant module owner for the checkin, and (2) get the permission of 
brendan@mozilla.org, who acts as the gatekeeper for independent contributor 
checkins during stabilization in the same way that the PDT acts as the 
gatekeeper for Netscape staff.

I would strongly encourage you to follow this procedure and go through with the 
checkin. Thanks to your efforts, we're *this* close to fixing the bug and 
complying with the spec. If you can go just this bit of extra distance, we'll be 
all the way there. I hope you can drive this through and provide another great 
example of independent contributors improving Mozilla and increasing standards 
compliance! Thanks for all your help!
Assignee

Comment 51

19 years ago
I have eliminated [HAVE FIX] from the status whiteboard, as it is misleading.
None of the attached patches will fix this bug ON THEIR OWN. Until a MIME
content type is actually registered, the patches will make us no better off than
we are now.

And until someone can answer my questions about XUL's handling of the charset
parameter, the MIME type registration cannot proceed.
Whiteboard: [nsbeta2-] [HAVE FIX] → [nsbeta2-]

Comment 52

19 years ago
I'm adding jbetak@netscape.com to the Cc list. Juraj, I believe you own the
so-called charset handling issues. Is that right? Please have a look at this
bug report, which raises a number of questions regarding charsets in XUL and
even in XML itself. Thanks.

Comment 53

19 years ago
nsbeta3-.  not gonna do it.. wouldn't be prudent, not at this juncture...
Whiteboard: [nsbeta2-] → [nsbeta2-],[nsbeta3-]
Target Milestone: M17 → Future
Assignee

Comment 54

19 years ago
Do what? Answer a simple question about the current functionality Netscape's
provided Mozilla with? That's what's holding this up at the moment. Why is that
so difficult?

If there are bugs/missing functionality with regard to the charset stuff, those
issues need to be filed. We just need some information here.
Braden: as far as we can tell, 'charset' is ignored for text/xul and not for 
text/xml. We probably intend to do it right for text/xul eventually, but won't
for this release. For now, there is no way to change the charset, and it is 
always utf8.

Does that answer your question or is there something else you need to know?

Reassigning to Braden since he has voiced the intention of doing what remains
to be done. ;-)
Assignee: hyatt → braden
Status: ASSIGNED → NEW
I've mailed Braden about this bug, but he hasn't replied. Is there any way this 
is going to get fixed before FCS, as it's one of those "if it's not, we're stuck 
with it for life" things, and it'll make us a laughing stock with the standards 
people...

Gerv

Comment 57

19 years ago
like text/javascript?  cc'ing the Dr.

Comment 58

19 years ago
Braden: Trudelle's "not gonna do it" comments in re: nsbeta3- was a mass bug
change (you can find a bunch of others marked with the same comment on that
date). I'm assuming his comments about "although it's minused, the module owner
can still apply patches" still hold true.

I think the short answer is that XUL currently only supports UTF-8, not due to
any sort of design-based reasoning but because our XUL DOM and our XML DOMs are
currently separate. With regard to the XUL /language/, it is XML and
theoretically follows XML's rules about charsets. Of course, you have to be able
to write the XUL tags in whatever charset you happen to pick, but XUL doesn't
make any funny restrictions on what bytecodes it's looking for -- that's up to
the XML parser, just like in any other XML application.

In other words, XML's charset parameter /should/ be usable, and that's what you
or we should tell the registrar. Please let me or David know what the status of
registration is and we'll try to keep the ball rolling. I'll take this bug if
you don't want to keep it.

Re-setting component to "evangelism" since, if I'm not mistaken, that's reserved
for this purpose.
Component: Parser → Evangelism

Comment 59

19 years ago
Claiming that using a MIME type of "text/xul" will make us a "laughing stock" is 
overreacting a bit I think.  Let's not blow this out of proportion.  :) 
Assignee

Comment 60

19 years ago
Sorry for the delay in my response; I've been very busy lately with work.

Gervase: Mozilla already tacitly endorses the wholesale invasion of the IETF
namespace for URI schemes. The commercial interests involved don't appear very
interested in standards that aren't bolstered to sex-symbol status by the W3C,
and mozilla.org management appears to be content with that. Thus Mozilla's
commitment to standards support is already rather shakey, and I doubt that the
outcome of this particular battle will stem the tide of abuse.

Dan: Thanks for reminding me that there *are* folks at Netscape who give a damn
about this. I'll resubmit the content type application. Note that the Internet
draft "XML Media Types" has been updated, and the changes do impact the decision
here. The current "correct" candidate would appear to be
"application/vnd.mozilla.xul+xml". More importantly, the section I quoted before
(4.2) nolonger exists. I suspect that the Right Thing is to act like
application/xml in this regard; there are some examples in section 8 of the
updated version that clarify correct behavior in this regard.

I will follow up with a copy of the content type application.
Status: NEW → ASSIGNED
Assignee

Comment 61

19 years ago
Here is the promised copy of the application. Scream if anything looks wrong.
--

Name : Braden N. McDaniel

E-mail : braden@endoframe.com

MIME media type name : Application

MIME subtype name : Vendor Tree - vnd.mozilla.xul+xml

Required parameters : none

Optional parameters : 
charset

The qualifications regarding this parameter are the same as for application/xml.

Encoding considerations : 
The encoding considerations for application/xml apply.


Security considerations : 
XUL shares security issues common to all XML content types. Furthermore, certain
applications of XUL could potentially present the problem of "user interface
spoofing", in which users might be presented with an interface requesting
personal information and artificially designed to look like an application or
system interface. The measures taken (if any) to minimize the possibility of
such abuse are left to the implementation.


Interoperability considerations : 
XUL is not described by a DTD and applies only the well-formedness rules of XML.
It should thus only be parsed by a non-validating parser.

Published specification : 
n/a

Applications which use this media : 
the Mozilla Internet application suite

Additional information :

1. Magic number(s) : None.
2. File extension(s) : .xul
3. Macintosh file type code : "TEXT"



Person to contact for further information :

1. Name : Dan Rosen
2. E-mail : dr@netscape.com

Intended usage : Common 


Author/Change controller : mozilla.org 


Assignee

Comment 62

19 years ago
Dan: Do we need another bug filed to cover the handling of the charset parameter
for XUL?

Comment 63

19 years ago
Sure.  File that against me.

Comment 64

19 years ago
Braden: One of our wish-list items actually is to get a DTD for XUL written up.
We're generally trying to do the Right Thing and encourage authors (through
gentle force) to write valid XUL. Our roundabout way of doing this while
developing the language was to "deprecate" XUL elements no longer intended for
use by making them show up with a big offensive border around them using CSS.

Anyway, If I were you, I would leave out the part about XUL only needing to be
well-formed and not valid. That probably won't always be the case.

Comment 65

19 years ago
I doubt we can ever enforce any attribute restrictions on XUL (nor do I think 
we really should).  People find the ability to attach arbitrary attributes onto 
an element for state-saving purposes to be very convenient, and this pattern has 
made it into widespread use in our XUL.  I'd be reluctant to disable this 
capability, because it's so useful.

e.g.,
mailnews does stuff like this...

<treeitem mailtype="imapserver">

and you can then style the icon on the item from CSS

[mailtype="imapserver"] {
  list-style-image: url(imapfolder.gif);
}

The RDF -> XUL transformation that is done through XUL templates also relies 
heavily on RDF properties being expressible on the XUL elements as attributes.

Comment 66

19 years ago
Also, using XBL you can make up your own new XUL tags.  So in order to restrict 
the tag set, you would have to force any new tags to be placed into a namespace 
other than XUL.  

Right now people make up new tags using XBL and keep them in the XUL namespace, 
so even the tag set is variable.
Assignee

Comment 67

19 years ago
David: Since XUL has HTML-style class selectors, I don't think there's anything
you can do by adding attributes ad hoc that you couldn't do just by adding a
class. So disabling 

Dan: David and I spoke about this on IRC. I don't think a DTD will ever be
feasible for XUL. The main reason is that XML's evolution is slowly but steadily
nudging DTDs into the realm of legacy practice. As it stands, namespace usage
and DTDs are incompatible. The W3C's solution to the problem is schemas. I don't
yet know much about schema-based validation, though.

David mentioned the practice of adding attributes ad hoc to be used with
attribute selectors in CSS. This is obviously incompatible with DTD-based
validation, and I'd be surprised with schema-based validation accommodated it.
The point is that the window to make XUL a more rigorous language is probably
closing fast, if it hasn't already.

Until there is an XUL schema and tools to apply it for validity checking, an
interim solution might be a well-publicized "best practices" document, including
a list of dos and don'ts. As far as the language in the content type application
goes, we can submit an amendment any time. But I'm inclined to leave it as-is
until we're clear that we actually want the additional rigor that validity will
impose.
Braden - thanks for doing all this legwork. :-) Was the application successful?

Gerv
Assignee

Comment 69

19 years ago
I'm still waiting for a response.
Assignee

Comment 70

19 years ago
The application has succeeded. application/vnd.mozilla.xul+xml is now an
official MIME content type.

Next step, then, is to make the appropriate changes to the browser source.
Keith, are you still following this? And if so, are you interested in updating
your patch?

Comment 71

19 years ago
Hey Braden: could you do a favor and attach the "success" email you received to
this bug? It would be good to have that in a more permanent location for those
interested than your inbox :)

Also, I doubt this would be a candidate for something which could land in
Netscape RTM or Mozilla 0.9 (not sure about that one, but blah blah blah risk
and stuff :), but I have a strong feeling that it'll be very much desired for
Mozilla 1.0. Thanks very much for your legwork on this, Keith and Braden!
Assignee

Comment 74

19 years ago
Since Keith hasn't followed up, I've attached an appropriate patch.

I think this one's ready to go now. Changing milestone to mozilla 0.9.

Also, this is not an Evangelism issue; changing component back to Parser.
Component: Evangelism → Parser
Keywords: patch
Target Milestone: Future → mozilla0.9

Comment 75

19 years ago
At this point, I think it's too late to remove the old MIME type (since I know 
PDT wouldn't approve it) for NS6.  Given that NS6 is going to ship with the old 
MIME type, we're going to need to continue support of it.  So I'd prefer a 
patch that adds the new MIME type without removing the old one.
Assignee

Comment 76

19 years ago
That would defeat the entire purpose of this bug report. Mozilla has no business
arbitrarily invading the IETF namespace. Supporting "text/xul" *is part of the
bug*. It is not a solution.

Comment 77

19 years ago
We could run it up the flagpole I suppose, but there's no way PDT is going to
let this through.
Then if PDT doesn't accept this, they will be solely responsible for a future
version of Mozilla being incompatible.

Comment 79

19 years ago
No they won't.  If PDT doesn't accept it, Mozilla will support text/xul as well.
Assignee

Comment 80

19 years ago
David: *Netscape* is responsible for a large portion of the delay in getting
this bug fixed. *Netscape* decided this wasn't important enough to devote their
own resources to. *Netscape* decided to base a product release on a codebase
advertised as immature. And this bug is there in the first place because a
Netscape engineer didn't bother to follow the proper protocol when introducing a
MIME media type.

For Netscape to attempt to shove this bug down mozilla.org's throat just because
it's convenient for them is unreasonable and *extraordinarily* bad precedent.
If a distributor of Mozilla wishes to release software of pre-release quality
then that is their decision.  However, I don't think it is acceptable for the
Mozilla design to be compromised by these releases.  I believe it would be a bad
precedent.

If we don't even include an addition patch, is this going to jeopardise forward
compatibility because people will want to target N6 and hence use the old type? 
Or can we expect XUL files will target a specific version of NGLayout?

If the old type is not removed, I think it should at least be deprecated and
release noted as going away in a future version, and to use the new type
instead.
Pinging mitchell and brendan for input.  This is an important policy issue, I
believe.

Comment 83

19 years ago
The old MIME type can be deprecated but still supported.  We can encourage 
people to use the new MIME type, but we can't simply drop support for it if NS6 
ships supporting it.

Mozilla has been supporting text/xul for too long to drop that made-up type
without a length deprecation/obsolescence cycle.

I really have a hard time getting as worked up about this as others do, but I've
been studying talkback data and trying to fix crashers lately.

/be
s/length/lengthy/

/be
Assignee

Comment 86

19 years ago
Oh, come on, Brendan. How many servers can you name that currently send the
bogus type?

At least be honest about this: mozilla.org is ultimately subject to the whim and
requirements of Netscape even for what goes onto the trunk. And Netscape
developers in positions of power are free to delay and ignore until time
constraints "justify" Netscape getting its way by fiat.

Well, I've had enough. You can find some other fool to jump through hoops for
you.

Reassigning to dr since he voiced some interest a little while back. I nolonger
give a rat's ass.
Assignee: braden → dr
Status: ASSIGNED → NEW
Important policy issues don't just go away because there's a Netscape release
happening.

I guess it's OK for Mozilla to support it for a little while, but there has to a
guarantee that it won't just have an "in future" status forever.

If N6 doesn't support the new type, and the old type is not removed eventually,
then people are just going to use the old type forever as far as I can see,
because it works more often.

Kind of like how people follow WWW un-standards because they work whereas up
until Mozilla the W3C standards haven't.  You do remember that situation don't
you?  The one you were trying to fix?  And the one that has a lot of work ahead
to solve?  Why go backwards?

Is this going to be nominated?  It's essential we get the new type in at least.

We'll see whether Netscape really gets it.  You can cut features, you can leave
in performance problems, but once you start selling out the future by leaving in
bugs that prevent proper implementations in the future, you make enemies.  The
last thing that Netscape needs right now is enemies.  They need evangelists, and
they need web developers on their side.

This sort of thing is exactly the sort of thing that has led us into the current
mess, and I believe Netscape's future in part relies on it being a beacon of
light.  If you don't support a CSS1 feature, it can be added in a later version,
even if it is a broken promise.  This can't just be added later.

You may think this is a trivial issue.  Maybe it is.  But it is indicative of an
attitude that stinks.  An attitude that has got us into this mess.  An attitude
I had hoped had gone.  Has it PDT?
Well, let's find out. Nominating for RTM. Somebody needs to get review and
super-review for the patch -- the fix is so straight-forward that the reviews 
should take all of five minutes each.

PDT: This bug is more important than a crasher. Netscape 6 can be released with 
unfixed crasher bugs, without precluding the possibility of fixing them in the 
next point release. However, if Netscape 6.0 is released with this bug still 
open, that will effectively prevent the bug from being properly fixed (in Mozilla 
or Netscape) for *years*.

The fix is nothing more than the replacement of one string by another, in the 
various places it occurs in the Mozilla source code -- 26 lines in total.
Keywords: review, rtm

Comment 89

19 years ago
Comments on the patch:

I see a place where mailnews uses the MIME type as part of a contractID that 
looks like a GET request with name/value pairs.  That makes me think they may be 
using it like that... I'm wondering if the + character in the new MIME type will 
cause problems there.

Comments on your comments:

Feel free to bring the bug before the PDT.  If it can get into Netscape 6, then 
I'm happy to remove the old MIME type.  The only reason I say we have to support 
it is that if we ship Netscape 6 with it, then - at the very least - Netscape 
6.5 will have to support it.  I suppose we could fork every file that contains 
the MIME type just to make sure Netscape continued to support it while Mozilla 
didn't, but that's hardly practical.  

As a basic rule, once you ship with something, you usually need to support it.  
You can deprecate the old MIME type, but you can't just throw it out.  Sure, 
Mozilla could stand for principles and all and just throw out the MIME type, 
placing the burden on Netscape, but all that would mean is that people would 
write XUL pages for Netscape that Mozilla wouldn't be able to display.

That said, if PDT is willing to take the patch for NS6, then it's ok IMO to kill 
the old MIME type.

I'll give an a= once someone from mailnews (alecf or mscott) can verify that the 
+ in the contractid won't hose anything they do with their converters.
>Oh, come on, Brendan. How many servers can you name that currently send the
>bogus type?

I honestly don't know, and that is one reason not to break those servers'
clients (Zope comes to mind).  Why is the burden on me rather than on you to
find out who in the community might be affected for the worse by your patch? 
It's not my patch.

>At least be honest about this: mozilla.org is ultimately subject to the whim
>and requirements of Netscape even for what goes onto the trunk.

Be honest yourself.  If you want me personally to go land your patch in the
trunk, breaking who-knows-what part of the community that uses remote XUL, you
are looking for a free lunch.

"Netscape" is a big organization, and most of the people in it don't know or
care about this bug.  Stick to individuals if you want accountability.  I just
re-read this bug, and there is no "whim" here except for hyatt's original choice
of text/xul based on ignorance of the rules.  After that, I see nothing but slow
movement toward the current patch.

>And Netscape developers in positions of power are free to delay and ignore
>until time constraints "justify" Netscape getting its way by fiat.

Are you claiming that someone (erik? hyatt? dr? who?) delayed and ignored your
question about charset (which you could have answered for yourself with a little
code inspection)?  That those evil people did so intentionally so they could get
away with inflicting their whim on the world in Netscape 6?  That's rubbish!

I don't care about what the PDT does in Netscape 6, because mozilla.org is not
responsible for that product or its branch, but before anyone lands this patch
on the trunk, they had better ascertain how many people in the Mozilla community
depend on text/xul, and deprecate before obsoleting the old type.  At least ask
in all the relevant newsgroups, contact the Zope people, do some leg work!

I've been consistent in saying this, and it has nothing to do with Netscape or
their whim-conspiracies, so please give that a rest.

/be
cc'ing alecf and mscott per hyatt's last comment.

hyatt: it's not ok to dump the old type on the trunk without a well-publicized
warning followed by a decent interval before doing the deed, if not by a full
Mozilla milestone deprecation period.

/be

Comment 92

19 years ago
Brendan, understood.

Comment 93

19 years ago
Based on brendan's comments, I need a new patch that adds the new MIME type
without removing the old MIME type.  I'll review it when it gets attached.
Assignee

Comment 94

19 years ago
> I honestly don't know, and that is one reason not to break those servers'
> clients (Zope comes to mind).  Why is the burden on me rather than on you to
> find out who in the community might be affected for the worse by your patch? 
> It's not my patch.

I had a longer, more thorough response prepared; but you know, it all comes down
to this, so I just snipped it:

Which Mozilla APIs have been announced as frozen? Because I wasn't aware that
this patch tread on any that had. I thought I was still operating in the realm
of unreleased, in-flux software.
>Which Mozilla APIs have been announced as frozen? Because I wasn't aware that
>this patch tread on any that had. I thought I was still operating in the realm
>of unreleased, in-flux software.

Nothing is frozen, despite attempts to freeze a tiny set of APIs.  What does
that have to do with anything?

If you break Zope, mozilla.org will hear about it.  I'm trying to head off that
avoidable bit of trouble by holding you to the same standards you demand of
netscape.com people: announce first, discuss and get consensus, then make an
incompatible change ("then" means soon, or after a major deprecation release).

Believe it or not, there are other companies out there than netscape.com that
are shipping Mozilla code.  We were even compelled last year, by complaints from
sun.com and by the size of their user base, to "freeze" parts of the plugin API
because JRE1.3 went out with binary dependencies on that API.

(Lest someone change the subject to deflect attention from this bug, yes -- it
sucks that mozilla.org doesn't know exactly who is shipping product based on
versions from our respository.  We've reached out several ways to enquire about
who might be doing that, but if you have better ideas for how to find out, mail
me.  We've already tried the "Mozilla 1.0 is next year, please wait" line, but
it's a free world and people will use this year's Mozilla at their discretion.)

/be

Comment 96

19 years ago
de-nominating for rtm, and cleaning up other spurious keywords... this won't be
"fixed" to everybody's satisfaction until the deprecation period for text/xul
passes, at which time we can claim well-behavedness when we remove it for good.
the patch needs to be worked on to add support for both mimetypes, which i
suppose i'll do (since braden seems to have nominated me). i'll even try to get
my patch into rtm, although i don't believe any of us have a convincing argument
to that end (i'll do this in a different bug, and keep this one open until, as
braden asserted, the made-up mime type is no longer supported).

a couple comments, though... braden: for someone who "doesn't give a rat's ass,"
you're still fighting pretty hard. and don't get me wrong -- i have plenty of
respect for that -- but understand that there is precedent even within the
standards bodies of abusing other standards. the w3c themselves managed to pull
the "text/javascript" pseudo-mime-type out of their ass in the html4 spec, which
isn't even an appropriate type (it ought to be application/javascript). consider
also the example of xml namespace uris: they're not even regulated, and although
people are bouncing ideas around for how to do so, anybody at any point in time
could trounce anybody else's namespace. i'm sure you can find more examples of
this sort of thing if you look around...

regardless, i'd prefer not to get in on this brawl. i'll try to fix things to
the best of my ability -- that's the best i can promise.
Status: NEW → ASSIGNED
Keywords: helpwanted, patch, review, rtm
Target Milestone: mozilla0.9 → mozilla1.0
Assignee

Comment 97

19 years ago
> Nothing is frozen, despite attempts to freeze a tiny set of APIs.  What does
> that have to do with anything?

Well, gee, Brendan, what on earth *could* that have to do with *anything*? I
wonder why that might lead a contributor to believe that the product is in flux,
and persons using the code are using pre-release code *at their own risk*?

Maybe the fact that this isn't true should be more well-publicized by
mozilla.org.

And please keep my comments in context when responding to them. The response I
got to my patch was not, "No, we have too many potential *existing*
dependencies," it was, "No, because there's a major Netscape release coming up
and PDT won't approve this." For you to pretend that I'm just miffed because I'm
being asked to do what you perceive as due diligence is disingenuous.

> If you break Zope, mozilla.org will hear about it.  I'm trying to head off
> that avoidable bit of trouble by holding you to the same standards you demand
> of netscape.com people: announce first, discuss and get consensus, then make
> an incompatible change ("then" means soon, or after a major deprecation
> release).

Excuse me? I don't have any problem with netscape.com persons making
incompatible changes to unreleased code as long as it's clear that the changes
are improvements. Objections I might have raised in the past have been to things
which weren't necessarily clearly improvements, and that covers most any
significant architectural change. This is not an architectural change. And
unless I've been totally misled about mozilla.org's stance on standard
conformance, this is a clear improvement. I know how convenient it might be to
portray me as a hypocrite here, but it's not gonna wash.

> (Lest someone change the subject to deflect attention from this bug, yes -- it
> sucks that mozilla.org doesn't know exactly who is shipping product based on
> versions from our respository.  We've reached out several ways to enquire
> about who might be doing that, but if you have better ideas for how to find
> out, mail me.  We've already tried the "Mozilla 1.0 is next year, please wait"
> line, but it's a free world and people will use this year's Mozilla at their
> discretion.)

Indeed. "At *their* discretion". That phrase doesn't really convey to me that
*Mozilla contributors* are obligated to go on wild goose chases to hunt down
anyone who might be affected by a patch.

I'm not fundamentally against doing more legwork here. But, Brendan, the
rationale you've presented for requiring that legwork is woefully inadequate. I
don't see how you can acknowledge that clients are currently using unreleased,
unfrozen Mozilla code "at their discretion" and simultaneously claim that
Mozilla contributors are responsible for making sure those clients don't take
collateral damage from patches. It doesn't make sense.
Keywords: helpwanted, patch, review, rtm
Target Milestone: mozilla1.0 → mozilla0.9
Assignee

Comment 98

19 years ago
Sorry about overwriting your keyword changes, dr. The alternative was losing a
long comment, and I didn't want to do that. I think I've put things back as you
had them.
Keywords: helpwanted, patch, review, rtm
Target Milestone: mozilla0.9 → mozilla1.0
Assignee

Comment 99

19 years ago
dr: I guess I care in spite of myself. I don't care much about the content type
anymore, but this is a helluva lot bigger than that now.

Comment 100

19 years ago
braden: regarding your comments to brendan -- nobody has a hard and fast
obligation to make the mozilla platform users' lives easier. but you can't go
tearing the carpet out from under their feet all in the name of standards. the
moral obligation we have, regardless of opinion, is to strike a fair balance for
everybody's benefit. i am a firm supporter of open standards, but even the
standards bodies realize that they have to be pragmatic as a part of process.
that's where learning, refinement, and improvement happen.

anyway, that was a vaguely long-winded way of saying that we're doing the only
reasonable thing to do here. please take further discussion to email.
>Well, gee, Brendan, what on earth *could* that have to do with *anything*? I
>wonder why that might lead a contributor to believe that the product is in
>flux, and persons using the code are using pre-release code *at their own
>risk*?

You don't get it still?  I'll try again: module owners and patch owners should 
cooperate to make a change that breaks compatibility in this way public, gather 
feedback, and work out an agreeable way to land the change *before* checking in 
the change.  Clear?

>Maybe the fact that this isn't true should be more well-publicized by
>mozilla.org.

No, I think roadmap.html publicizes things well enough.  I'm not going to revise 
it to say "look out, someone may rip out text/xul or a similar protocol-born 
type without any notice".

>And please keep my comments in context when responding to them.

I wasn't responding to your comments to hyatt -- you and hyatt work out your 
differences without me, please.  I'm reminding you how to make incompatible 
changes in the Mozilla trunk, for the third time.

Why am I here anyway?  Do you really need me to help everyone cooperate?

>The response I
>got to my patch was not, "No, we have too many potential *existing*
>dependencies," it was, "No, because there's a major Netscape release coming up
>and PDT won't approve this."

Hyatt seems to have changed his mind, and was willing to "run this up the flag 
pole".  dr seems less optimistic.  But as I wrote, that's all netscape.com's 
business.

And (again, so you don't miss it) I'm not saying "No, never" -- I am not 
objecting to your patch going into the trunk simply because we have unknown 
(if not too many) dependencies on it.  If you and the owners of the dependencies 
can come to agreement fast, great.  To do that, you have to publicize the change 
in better ways that commenting in this bug.

>For you to pretend that I'm just miffed because I'm
>being asked to do what you perceive as due diligence is disingenuous.

I didn't pretend any such thing.  You attacked my comments asking for due 
diligence.

I did take you to task for your ludicrous complaint that "Netscape" was delaying 
on purpose to impose the "whim" of text/xul on the world, but maybe you got over 
that silliness.

I also didn't say you were a hypocrite.  And I never said one word against the 
patch; in fact I am in favor of it going into the trunk as soon as is agreeable 
to affected parties.

I'm sorry you think that it doesn't make sense to expect patch purveyors, 
owners, and users to satisfy or break _de facto_ standards and commitments in 
the Mozilla code by proposing an incompatible change outside of the confines of 
a bug like this *before* breaking the standards.  I don't think that requirement 
is at odds with Mozilla being in an unfrozen state.  You don't freeze a project 
this big all at once, and you don't break parts of it that have been checked in 
for a year or more, and on which others to whom you haven't spoken depend.

Another parochial _de facto_ standard example: Mozilla has a bunch of crucial 
code implementing the not-yet-standardized XBL, used by many in the community, 
and it is getting hard for hyatt to make incompatible changes at all, never mind 
make them without advice and consent.

I'm done here.

/be

Comment 102

19 years ago
This may sound silly, but can't we recognize both content types as xul:
text/xul
and
"appliation/vnd.mozilla.xul+xml"

At least in the interim. That way we would still properly recognize servers that
issue text/xul content as xul while also adding support for the more standards
friendly content type as well.

Comment 103

19 years ago
That's what I suggested, but braden and matty are objecting to this idea,
asserting that any support for the text/xul MIME type constitutes a violation of
the standard.

Comment 104

19 years ago
triaging for post-rtm
Target Milestone: mozilla1.0 → mozilla0.9
A better solution all round would be to use text/xml as the MIME type for XUL,
and fix our content sink / parser / network library to instantiate the document
object only after finding out what the namespace of the root element is or what
the DOCTYPE of the document is.
Dave, it would be in violation of the standard, but I said it would be OK IMO to
merely deprecate it for now if it's going to be removed eventually.  But this
won't be possible ever unless N6 supports the proper type.

Brendan, maybe you should think seriously about breaking released products if
you need to.  It might make others think twice about not being in contact with
mozilla.org.

Matthew, I agree, this is more serious than a crasher bug, at least the addition
part.
Braden mailed me about my being less than clear in commenting about how long a
deprecation period was required, before obsoleting text/xul.  My comments here
were my opinion, vaguely expressed at first using "lengthy" to mean no longer
than one Mozilla major milestone (three months, mozilla0.9). But I went on in
subsequent comments to write that with discussion, it might turn out that no one
was much put out by removing text/xul; or that people could cope more quickly
than my unspecified-till-now "lengthy" implied.

I was not laying down mozilla.org policy on deprecation and obsolescence of MIME
types or other protocol-born data on which distributed consumers of Mozilla may
have come to depend.  I don't believe mozilla.org can devise a general policy at
this time.  I was only giving my vaguely-worded opinion in my first comment,
when I should have been clearer and gotten on to the "discuss among yourselves
in a public newsgroup, I'm verklempt" state.  Sorry about that (and thanks for
pointing my moment of unclarity out to me, Braden).

/be
Assignee

Comment 108

19 years ago
Okay... I admit it... I care. I *really* wish I didn't, but I do.

Per Brendan's request, I've started a thread on the .xpfe newsgroup. I'll e-mail
Martijn Pieters about this thread. If any of you know of other folks who ought
to be alerted about this, please do so.

Comment 109

19 years ago
upon refactoring / rewriting of xml content sink, this bug will be fixed per
ianh's recommendation: text/xul will be deprecated in favor of text/xml, and the
application type will be determined by namespace rather than mime type.

after a release cycle or other suitable period of "warning" time, support for
text/xul will be removed.

targetting for moz1.0 (contingent on xml content sink work).
Summary: MIME type for XUL invalid (not compliant with RFC2048) → deprecate and remove non-compliant text/xul mimetype.
Target Milestone: mozilla0.9 → mozilla1.0
Assignee

Comment 110

19 years ago
Sounds reasonable. But you want "application/xml", not "text/xml".
The sooner we sort this, the less painful it will be...

Gerv
Keywords: mozilla1.0, nsbeta1

Comment 112

19 years ago
Totally. Once the nsXMLContentSink is reworked, we can use application/xml, and
use the XUL namespace on the root <window> element to detect XUL documents.
There may be an interim solution (read: ugly hack to nsXMLContentSink) but I'm
not sure...

Cc'ing jst -- Johnny, can you tell me what's going on with the content sink? Thanks.
Looking at the length of the discussion in this bug I won't go into any level of
detail about the XML content sink here. As far as I know there won't be any
dramatic changes to the content sink any time soon, there will probably be a
major rewrite of the XML/XUL/XSL sinks but I don't see that happening in time
for mozilla 1.0.

Currently the document is created before the sink and that makes it really
complicated to look at the namespace on the root node to determine of what type
the currently loading document should be, and I don't see that changing before
mozilla1.0 either.

Comment 114

19 years ago
->future, unfortunately.

jst: if you happen to have a bug on you for the content sink work, do me a favor
and make that block this. thanks.
Target Milestone: mozilla1.0 → Future
Dan, there's no bug on file for the content sink work yet, we're still just
talking about it...
So, in summary: We are currently using text/xul. We eventually want to replace 
that with application/xml and work out that it's XUL another way. However this 
will take a long time, because it depends on content sink refactoring.

So, in the mean time, do we want to do a search-and-replace to use the (legal) 
MIME type appliation/vnd.mozilla.xul+xml ? Or does that just make more trouble? 
I think we should avoid using text/xul a second longer than we have to...

Gerv

Comment 117

19 years ago
please leave this alone. Afaik we can not do the replace because no one checked 
in support for that type.
Keywords: nsbeta2, nsbeta3
Whiteboard: [nsbeta2-],[nsbeta3-]
Can we not "check in support for that type" then?

Surely the resolution is to replace all instances of text/xul in the entire 
Mozilla source with vnd/mozillablahblah ? How could it be more complicated than 
that?

Gerv
Timeless, I thought you'd be the last person I'd have to tell that mozilla.org 
has made precisely zero major releases of its software, it's pre-release, and 
interfaces, UI, APIs and everything else are subject to arbitrary change without 
warning.

I see no reason why potential future work, with a possible "better fix" for this 
problem should prevent us doing the right thing now - especially as the 
potential future work will not happen before our first major release.

As a side note, how does changing our internal MIME type for XUL affect anyone 
apart from us? No-one's serving XUL up from a webserver to be interpreted in 
the browser, are they? I would have thought Security would have something to say 
about that...

Gerv

[ Despite what the Bug Activity might say, I have been following this bug for 
the past six months or so. ]

Comment 120

19 years ago
> mozilla.org has made precisely zero major releases of its software,
Bugzilla is nearly at 2.12, and is planning a 3.0 for before i my sister 
graduates from college [4 years, at 16 web years should be plenty, please]
> it's pre-release, and interfaces, UI, APIs and everything else are subject to 
arbitrary change without warning.
This is wrong.  Roadmap and brendan will tell you that we do freeze [or try 
to freeze] portions of apis at specific milestones (I can tell you that UI 
_did_ freeze on me at specific milestones), and we do provide warning on 
www.mozilla.org and in the newsgroups.

> No-one's serving XUL up from a webserver to be interpreted in the browser,
> are they? 
they are.  people.netscape.com does, bugzilla.mozilla.org does, and at least a 
few other real groups, some day i might try to find a useful list of such 
sites, but i haven't figured out what to tell google when i ask.

I see no reason not to accept the patch that supports both, except i'm not sure 
it exists.  Offering a migration path is better than bickering and stikcing w/ 
a path that people don't like [although i don't mind the current path]
> Bugzilla is nearly at 2.12, and is planning a 3.0 for before i my sister 

OK, so I've been out-pedanted :-)

Currently, the number of people who are serving as text/xul who are not under 
our direct or indirect control is very small. If we release Mozilla 1.0 with 
text/xul, not only do we look fools in front of anyone who cares about 
standards, but then we have to support the wretched thing for another major 
revision, or however long it is.

If we don't change now, we have to live with this. Anyway, you and I arguing 
about it probably won't change much. I know Brendan is CCed on this bug, and 
he's the man to make the final decision. Brendan?

Gerv
I don't think we should release mozilla1.0 with text/xul polluting the text/
MIME type space.  We've been over this at some length, here and in mail/news
messages.  I'm expecting dr (or someone else motivated who'll take this bug) to
do the .xml with a namespace thing in time for 1.0.  Hence the milestone keyword
nomination.

Now, dr: why is this bug Futured?  Are you using that milestone to mean "not by
mozilla0.9"?  How about finding someone else to do it in the current milestone
(0.9), or sooner than at the last minute (during 1.0)?

/be

Comment 123

19 years ago
This is excessively irritating.

To detect that an XML file (application/xml) is XUL, the file needs to be at
least partially parsed, if not by an XML parser then by some other parser which
can "take a good guess" based on the presence of the XUL namespace in the
document. To do this correctly, the XML content sink needs to be refactored to
handle multiple strategies per-namespace. I am not willing to lean on jst to do
this right now, because the XML/DOM team has bigger fish to fry at the moment.

The other solution, simply replacing the incorrect uses of text/xul with the
obtuse "application/vnd.mozilla.xul-xml" would be technically correct. It is
also true that only a small number of authors or servers are serving content
with the type text/xul currently. But I think we agreed long ago that switching
content types for XUL without a "grace period" is inappropriate for many
reasons. Some of these reasons involve mozilla.org vs. Netscape politics, which
I think are well-understood by everybody here, and some of these reasons are
purely technical. One major reason I believe everybody here should agree on is
that the small core of people and organizations serving up XUL currently
represents the segment of mozilla's user base which is reasonably well-versed in
our technologies, and we don't want to piss them off. Regardless, the ground has
been well-covered.

I personally believe the right solution to be to improve or refactor the XML
content sink to deal with pluggable strategies per-namespace. I would be willing
to do that work, but it would both trample on the feet of that code's owners, be
irrelevant to XPToolkit's short-term goals, and take a long time since I'm not
at all familiar with the relevant code. I should also say that I personally
believe the *wrong* solution to be a lengthy session of bickering.

I'm reassigning this bug to nobody@mozilla.org at this point for the reasons I
described, in the hope that somebody will take this bug and do the right thing.
Perhaps this bug could be reassigned to the default owner of XML, or some
such... I'd be more than happy to accept this bug again if it is agreed that the
content sink work or some reasonable equivalent should be done. Otherwise I want
no part in it.
Assignee: dr → nobody
Status: ASSIGNED → NEW
Assignee

Comment 124

19 years ago
Is there a reason that a patch to support both "text/xul" and
"application/vnd.mozilla.xul+xml" could not be checked in ASAP, and then another
patch to remove support for "text/xul" checked in at some point prior to 1.0?

That should be pretty trivial to implement, and I think I could provide such
patches.
Braden: go for it.  It would be better, I think, to work on the namespace-based
strategy flexibility that dr describes, but we don't want text/xul in 1.0, so if
we can't have no mime type for XUL, we should have a proper one.

/be
Assignee

Comment 126

19 years ago
Okay. I've filed bug 69749 on the dual support issue.

I'll add that I agree that namespace-oriented pluggability is the Right
direction to go for a number of reasons. Unfortunately, it involves enough work
that it appears unlikely to provide a timely solution to this problem. And as
has already been pointed out, timing is important here.
Assignee: nobody → braden
Depends on: 69749
Summary: deprecate and remove non-compliant text/xul mimetype. → remove non-compliant text/xul mimetype.
Target Milestone: Future → mozilla1.0
Assignee

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
QA Contact: janc → bsharma

Comment 127

19 years ago
updated qa contact.
Hyatt and Ben Goodger have decided to make backwardly-incompatible changes to 
the XUL syntax before 1.0. Would this not be an ideal opportunity to change the 
MIME type while we were at it? After all, two incompatible formats with the same 
MIME type is bad, and we've been trying to ditch text/xul for ages now... Two 
birds with one stone?

Braden? Brendan?

Gerv
Assignee

Comment 129

19 years ago
Gerv: Are you suggesting skipping a deprecation period where both types would be
supported? Or are you just advising some coordination in the chronology of the
changes? The latter seems obviously Good; I've no opinion on the former.

FWIW, I'd planned on posting a patch to bug 69749 either tonight or tomorrow. It
touches a lot of files and should probably be reviewed by a fair number of people.
Braden: I'm suggesting skipping the deprecation period of text/xul because we 
don't want post-change Mozilla trying to read pre-change XUL anyway (because 
it'll barf.) This is a good (the ideal) way of making sure that doesn't happen.

Hyatt, Ben G: do you have a view on this? Because that would be reasonably 
conclusive ;-)

Gerv
Assignee

Comment 131

19 years ago
Okay; I'll wait for a conclusion on this before taking any action on bug 69749.

(Presumably, the namespace identifier for XUL will be changing as well?)
Braden: Hyatt said "OK" to me on IRC, for changing the MIME types (not the 
namespace) as detailed in this bug. 

Wahey!

But because the XUL changes have just landed, we should do this ASAP. Are you 
going to prepare the patches? <looks hopeful> If not, let me know, and I'll try 
(though I've never done anything this complex before.)

Gerv
OK - patch being attached. This changes text/xul to
application/vnd.mozilla.xul+xml. 

It also changes text/cached-xul to application/vnd.mozilla.cached-xul . The
reasoning behind this is that, even if we haven't registered it as an official
type yet, we are being less horrifically polluting of the MIME namespace this
way, and if we don't do it now, it'll never get done.

Looking for review and super-review.

Gerv
Assignee

Comment 135

19 years ago
Gerv: Do not add "application/vnd.mozilla.cached-xul" (or any other MIME type
outside of the experimental namespace) until you have registered it. Period. It
creates bigger problems than it solves. (Bugs like this one, for instance.)

I thought the conclusion was that "text/cached-xul" does not need to be changed
since it is completely internal to the application. If we do want to change it,
it should be either to something in the experimental namespace
("application/x.vnd.mozila.cached-xul") or, better, something in an
application-specific format that would not be mistaken for a MIME type.

Comment 136

19 years ago
Yeah, cached XUL is not a real exposed MIME type.  It's just a hacky thing we
use internally.  I don't really mind if it is changed though.

sr=hyatt

Braden: If it's for internal use only, then it doesn't matter. If it's external,
the new one is better than the old - because we don't have to change it _again_
if we later decide it needs registering. Do you think we _couldn't_ get it
registered if we bothered? Whereas we wouldn't have a prayer of getting the old one.

Gerv
Assignee

Comment 138

19 years ago
Gerv: You *might* be able to get a "cached-xul" registered, but you shouldn't.
It is not part of public interchange, therefore there is no reason to clutter
the media type namespace with it. For that reason,
"application/vnd.mozilla.cached-xul" is not significantly better than
"text/cached-xul". Whatever string is chosen for this, *it does not correspond
to a MIME type". If people get warm fuzzies from making it look like a MIME type
(though personally I think this just incites confusion), then either use a name
in the experimental namespace or use something that is more obviously
application-specific like "mozilla.application/cached-xul".

In any event, there is no good reason for "repairing" "text/cached-xul" to be
part of this bug. It does not depend on the string used for the public XUL MIME
type; and as an internal type it does not have the problem with external
dependencies (which has been the principal factor in delaying resolution to this
bug).
OK, you win. mozilla.application/cached-xul it is. 

Blake or Ben - still looking for an r=, and a swiftly-following check-in :-)

Gerv
Keywords: mozilla0.9, patch, review

Comment 141

19 years ago
Done and done.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago19 years ago
Resolution: --- → FIXED

Comment 142

19 years ago
I am adding support for text/xul back, so as not to break all those evil bad
naughty sites that actually serve it up. Like mine.

Comment 143

19 years ago
This caused bug 74502. Apparently, somebody in the ``real world'' is serving up
text/xul. 
waterson: anyone who is serving text/xul will be serving broken XUL anyway, 
surely?

What has happened here is that the change has uncovered bugs in Mozilla. Why is 
this different to any other time where this happens? We should fix the bugs, not 
back out the change.

We fully expected there to be a few sites serving up XUL. These people would 
have had to have known about this change because they would have had to know 
about Blake's other changes. The only reason I haven't made an announcement yet 
is that I was waiting for bug 74146, which people seem to be ignoring, to get 
fixed.

Gerv

[Putting this comment in two places]

Updated

18 years ago
QA Contact: bsharma → moied
You need to log in before you can comment on or make changes to this bug.