I've found the arguments in favor of the type param to be more convincing than those in favor of the new media type...
...so +1 to what Bob said. - James Tim Bray wrote: > > Bob Wyman wrote: >> There is, I think, a compromise position here which will avoid >> breaking those existing implementations which follow the existing RFC's. > > <co-chair-mode>In case you haven't noticed, the WG is hopelessly split > between the new-media-type option and the media-type-parameter option. > If a few people were to put up their hands and say "yeah what Bob said" > your co-chairs would probably do a hasty consensus grab.</co-chair-mode> > > -Tim > >> >> 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get >> them defined, registered, and "ready to use.") >> 2) Leave RFC4287 unchanged. i.e. do NOT re-define "application/atom-xml" >> 3) New specifications MAY require that ;type=entry be used. (Note: >> Just because ;type=entry is used DOES NOT imply that ;type=feed must >> also be used....) >> >> Thus, APP would accept application/atom+xml when looking for a feed >> but might insist that entries be explicitly identified with a >> disambiguating type parameter. Thus, no code which currently uses >> "application/atom+xml" to designate a feed would be broken. >> Additionally, any code which is "properly" built and thus ignores >> unknown types will not be hurt when it sees >> "application/atom+xml;type=entry" since it will ignore the type >> parameter and dig around inside the data to figure out if it is feed >> or entry. The only code which will be hurt is some potential code that >> does not follow the existing RFCs for Atom or mime types. It is, I >> think, OK to occasionally break code that doesn't follow the specs. >> >> Whatever the technical arguments may be, I believe it is important >> from a "political" point of view that we do not change the definition >> of things defined in Atom. I am all for extending Atom, but not for >> changing Atom. We must not change the exiting specification unless >> there is some really serious harm being done. If we do, we risk losing >> the trust of at least some members of the community that we've built >> these last few years... Folk will remember that one of the >> "advantages" that is claimed for RSS is that it has been declared to >> be eternally free from modification. While I personally believe that >> that is silly, the proponents of RSS do have a point when they speak >> of the value of stable specs. If we allow the Atom spec to be >> *changed* so soon after it was accepted and we don't have a really, >> really good reason for doing it, we will simply have proven the often >> made claim that standards groups simply can't be trusted with >> important specifications. We will be encouraging more of the kind of >> "standards making" that resulted in the mess that is RSS... >> >> bob wyman >> >> PS: Since Kyle points out that GData, a Google product, is potentially >> impacted by the results of this discussion, I should state that I >> currently work for Google -- although I am not currently assigned to >> any product or project that has a direct interest in the definition of >> Atom, APP, etc... My participation in this discussion, at this time, >> is driven purely by personal interest. >> > >
