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.
