Re: AD Evaluation of draft-ietf-atompub-protocol-11
Eric Scheid wrote: > On 15/12/06 7:29 AM, "Sylvain Hellegouarch" <[EMAIL PROTECTED]> wrote: > >> Besides, if you want to do fancy thing with a member, simply post a >> media resource which is an atom entry. This won't be modified by the >> server and will solely be treated a media resource. > > promise? does the spec support this assertion? or is this another case of > "the server is in charge and can accept or change whatever it wants"? > > e. No you are right, this is a gratuitous assertion here. However APP currently describes what a server is allowed to do on a member resource and not on the media resource. It could be interesting to see how extensions to APP could allow the server and the UA to agree on what level of modification each party is entitled to expect. - Sylvain
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 12/14/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote: This requirement has to be stated explicitly, at least as a SHOULD. This is the kind of thing that clients come to completely rely on, and then you find some special-purpose server that decides this doesn't fit in its model. "Well, the spec doesn't require me to accept link relations which point to other servers." Finger-pointing rather than interoperability. Older versions of the spec had this wording: http://bitworking.org/projects/atom/draft-gregorio-09.html#rfc.section.4.3 "This RFC does not specify the form of the URIs that are used. The URI space of each server is controlled, as defined by HTTP, by the server alone. What this RFC does specify are the formats of the files that are exchanged and the actions that can be performed on the URIs embedded in those files." Something along those lines could be added back in. Can a server ever ignore part of an edit and successfully process the rest? Yes. Think of a client that throws in a slew of random link elements with relations my server implementation doesn't understand. Same with foreign markup. The server is in charge. I completely disagree with this. It is way too unpredictable for clients to deal with. Clients are left with the illusion of flexibility -- it *seems* you can use Atom syntax extensions and do creative things that other extended clients can understand -- but in fact the server can alter this at will leaving the client without any control over what it's really publishing. This happens *all the time* in the real world. Many blog comment systems have 'Preview' buttons. Why? Because you never know how the server is going to handle your text. Yes, it might be nice, in the future, to add a way for a server to advertise its capabilities, but we do not have the real world experience with the protocol to know what that should look like. In many cases, the client won't even want the server to store some stripped version of what it POSTed, because it can really change the meaning of some entry to have the server strip some of the content and markup. Imagine removing the start time and location when I'm trying to publish an event entry to what I believe ought to be a calendar feed. Some server changes to submitted documents is of course going to be allowable (edit dates, server-provided IDs, changes which are effectively XML canonicalization) but I believe these need to be limited. The general case, which is how servers deal with unrecognized elements, needs to be severely limited so that the server can either reject the whole request or store as provided. I'm sorry but we've already argued this to death on the list and there is nothing in HTTP which supports that view [1]. We've even reviewed the scenario you are talking about and came to the opposite conclusion: http://www.imc.org/atom-protocol/mail-archive/msg05415.html This is the documented consensus of the WG. The next draft will have verbage that makes this position clearer. If some implementations find that too loose and want octet-for-octet storage they can use always WebDAV. [1] http://www.imc.org/atom-protocol/mail-archive/msg05415.html Thanks, -joe -- Joe Gregoriohttp://bitworking.org
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 12/14/06, Sam Ruby <[EMAIL PROTECTED]> wrote: I believe I first saw this in a response made by Roy Fielding to an assertion that servers must treat HTTP PUT as a bit-for-bit copy, but I can't immediately find the reference. http://www.imc.org/atom-protocol/mail-archive/msg05425.html In any case: clients must always consider the possibility that the server processes other requests (even internally generated ones) between the time the one the client issued and the next request the server choses to process. Such requests could partially or completely change the representation of the resource. - Sam Ruby -- Joe Gregoriohttp://bitworking.org
Re: Atom Entry Documents
On Fri, 15 Dec 2006 01:40:01 +0100, James M Snell <[EMAIL PROTECTED]> wrote: Quite a few folks seemed to have a preference to a separate doc. What does "quite a few folks" mean wrt consensus? What reasons are there not to include this in the APP specification? -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Atom Entry docs
On Thu, 14 Dec 2006 18:00:17 +0100, Tim Bray <[EMAIL PROTECTED]> 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. 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. *Hands up* «What Bob said» -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Atom Entry Documents
Quite a few folks seemed to have a preference to a separate doc. - James Asbjørn Ulsberg wrote: > On Tue, 12 Dec 2006 08:39:25 +0100, James M Snell <[EMAIL PROTECTED]> > wrote: > >> Ideally, I would much rather this be a WG draft. I pinged Tim about it >> the other day and he suggested that I go ahead with a I-D for now and >> that we can explore whether or not to move forward with it as a WG draft >> later. > > Can't just the APP specification include language that specifies a new > MIME type for Atom Entries, since it's mostly APP implementations that > have a use for it? Or would that be totally out of place? > > --Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ > «He's a loathsome offensive brute, yet I can't look away» >
Re: Atom Entry Documents
On Tue, 12 Dec 2006 08:39:25 +0100, James M Snell <[EMAIL PROTECTED]> wrote: Ideally, I would much rather this be a WG draft. I pinged Tim about it the other day and he suggested that I go ahead with a I-D for now and that we can explore whether or not to move forward with it as a WG draft later. Can't just the APP specification include language that specifies a new MIME type for Atom Entries, since it's mostly APP implementations that have a use for it? Or would that be totally out of place? -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Atom Entry Documents
On Tue, 12 Dec 2006 23:25:44 +0100, Tim Bray <[EMAIL PROTECTED]> wrote: [...] So I see no downside in James doing an I-D. But is a separate I-D really necessary? If, like Kyle Marvin suggests, the new MIME type for Atom Entries actually becomes a type parameter of the existing Atom MIME type, can't the language that specifies this be included in the APP specification? By that, APP will only extend RFC 4287 and not deprecate anything. It might include wording like "SHOULD use the type parameter", but that still makes the old and bare MIME type valid. Thus, implementing RFC 4287 will not require you to use a type parameter, but implementing the APP specification will strongly encourage you to do so. Won't that solve it all? -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 15/12/06 7:29 AM, "Sylvain Hellegouarch" <[EMAIL PROTECTED]> wrote: > Besides, if you want to do fancy thing with a member, simply post a > media resource which is an atom entry. This won't be modified by the > server and will solely be treated a media resource. promise? does the spec support this assertion? or is this another case of "the server is in charge and can accept or change whatever it wants"? e.
Re: Atom Entry docs
On 14/12/06 3:23 PM, "Bob Wyman" <[EMAIL PROTECTED]> wrote: > 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) +1
Re: AD Evaluation of draft-ietf-atompub-protocol-11
> > I believe I first saw this in a response made by Roy Fielding to an > assertion that servers must treat HTTP PUT as a bit-for-bit copy, but I > can't immediately find the reference. > Could it be? http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0228.html - Sylvain
Re: AD Evaluation of draft-ietf-atompub-protocol-11
Lisa Dusseault wrote: Can a server ever ignore part of an edit and successfully process the rest? Yes. Think of a client that throws in a slew of random link elements with relations my server implementation doesn't understand. Same with foreign markup. The server is in charge. I completely disagree with this. It is way too unpredictable for clients to deal with. Clients are left with the illusion of flexibility -- it *seems* you can use Atom syntax extensions and do creative things that other extended clients can understand -- but in fact the server can alter this at will leaving the client without any control over what it's really publishing. In many cases, the client won't even want the server to store some stripped version of what it POSTed, because it can really change the meaning of some entry to have the server strip some of the content and markup. Imagine removing the start time and location when I'm trying to publish an event entry to what I believe ought to be a calendar feed. Some server changes to submitted documents is of course going to be allowable (edit dates, server-provided IDs, changes which are effectively XML canonicalization) but I believe these need to be limited. The general case, which is how servers deal with unrecognized elements, needs to be severely limited so that the server can either reject the whole request or store as provided. I believe I first saw this in a response made by Roy Fielding to an assertion that servers must treat HTTP PUT as a bit-for-bit copy, but I can't immediately find the reference. In any case: clients must always consider the possibility that the server processes other requests (even internally generated ones) between the time the one the client issued and the next request the server choses to process. Such requests could partially or completely change the representation of the resource. - Sam Ruby
Re: Atom Entry docs
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. 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. +1 to "what Bob said" - Sam Ruby
Re: AD Evaluation of draft-ietf-atompub-protocol-11
>>> Can a client modify an entry to contain a link relation element in the >>> following cases: >>> - To point to a resource on a different server entirely? >> >> There is no reason to believe that any of these resource are on >> the same machine to begin with. I could POST to media to machine A >> and have the MLE could be created on machine B and the editable media >> resource itself created on machine C. > > This requirement has to be stated explicitly, at least as a SHOULD. > This is the kind of thing that clients come to completely rely on, and > then you find some special-purpose server that decides this doesn't fit > in its model. "Well, the spec doesn't require me to accept link > relations which point to other servers." Finger-pointing rather than > interoperability. I didn't quite understand your statement here. You make things more complicated than what Joe actually said. > > If that's completely unacceptable, the only alternative that would allow > good interoperability is to have an error code or feature advertisement > that allows the client to detect that the server won't allow this. A > generic "Forbidden" error (or other choice that could be made by the > server) is not enough to know what is disallowed and whether it is > always disallowed. "What did I do wrong?" the client plaintively asks. A generic error code would mean there was an error in the first place. Why is this the case? > >>> >>> Can a server ever ignore part of an edit and successfully process the >>> rest? >>> >> >> Yes. Think of a client that throws in a slew of random link elements with >> relations my server implementation doesn't understand. Same with foreign >> markup. The server is in charge. > > I completely disagree with this. It is way too unpredictable for > clients to deal with. Clients are left with the illusion of flexibility > -- it *seems* you can use Atom syntax extensions and do creative things > that other extended clients can understand -- but in fact the server can > alter this at will leaving the client without any control over what it's > really publishing. In many cases, the client won't even want the server > to store some stripped version of what it POSTed, because it can really > change the meaning of some entry to have the server strip some of the > content and markup. Imagine removing the start time and location when > I'm trying to publish an event entry to what I believe ought to be a > calendar feed. > > Some server changes to submitted documents is of course going to be > allowable (edit dates, server-provided IDs, changes which are > effectively XML canonicalization) but I believe these need to be > limited. The general case, which is how servers deal with unrecognized > elements, needs to be severely limited so that the server can either > reject the whole request or store as provided. This is a fundamental change to what has been said over and over on this mailing-list. Allowing the client to have more power than the current draft allows on the Atom member would mean we have to detail all those cases within the draft itself and would strongly limit its simplicity IMO. Besides, if you want to do fancy thing with a member, simply post a media resource which is an atom entry. This won't be modified by the server and will solely be treated a media resource. Then the client will have full control on it. The server must keep full control of the member resource. - Sylvain
Re: AD Evaluation of draft-ietf-atompub-protocol-11
Thanks for responding to my review. I look forward to seeing a revised draft. Below I've excerpted the stuff that is still giving me serious problems. On Dec 7, 2006, at 8:36 AM, Joe Gregorio wrote: Can a client modify an entry to contain a link relation element in the following cases: - To point to a resource on a different server entirely? There is no reason to believe that any of these resource are on the same machine to begin with. I could POST to media to machine A and have the MLE could be created on machine B and the editable media resource itself created on machine C. This requirement has to be stated explicitly, at least as a SHOULD. This is the kind of thing that clients come to completely rely on, and then you find some special-purpose server that decides this doesn't fit in its model. "Well, the spec doesn't require me to accept link relations which point to other servers." Finger- pointing rather than interoperability. If that's completely unacceptable, the only alternative that would allow good interoperability is to have an error code or feature advertisement that allows the client to detect that the server won't allow this. A generic "Forbidden" error (or other choice that could be made by the server) is not enough to know what is disallowed and whether it is always disallowed. "What did I do wrong?" the client plaintively asks. Can a server ever ignore part of an edit and successfully process the rest? Yes. Think of a client that throws in a slew of random link elements with relations my server implementation doesn't understand. Same with foreign markup. The server is in charge. I completely disagree with this. It is way too unpredictable for clients to deal with. Clients are left with the illusion of flexibility -- it *seems* you can use Atom syntax extensions and do creative things that other extended clients can understand -- but in fact the server can alter this at will leaving the client without any control over what it's really publishing. In many cases, the client won't even want the server to store some stripped version of what it POSTed, because it can really change the meaning of some entry to have the server strip some of the content and markup. Imagine removing the start time and location when I'm trying to publish an event entry to what I believe ought to be a calendar feed. Some server changes to submitted documents is of course going to be allowable (edit dates, server-provided IDs, changes which are effectively XML canonicalization) but I believe these need to be limited. The general case, which is how servers deal with unrecognized elements, needs to be severely limited so that the server can either reject the whole request or store as provided. Lisa
Re: Atom Entry docs
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. 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.
Re: Atom Entry docs
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. 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. hand up...
Re: Atom Entry docs
2006/12/14, Tim Bray: Bob Wyman wrote: > There is, I think, a compromise position here which will avoid breaking > those existing implementations which follow the existing RFC's. 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. Just in case: "yeah what Bob said" ;-) -- Thomas Broyer
Re: Atom Entry docs
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. > > 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. > > -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. >> > >
Re: Atom Entry docs "what Bob said"
"yeah what Bob said" I'm not sure it is ideal, but it seems the closest to consensus we're ever going to get. +1 On Dec 14, 2006, at 7:08 AM, Rogers Cadenhead wrote: --- Bob Wyman <[EMAIL PROTECTED]> wrote: 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) +1 on this approach. RFC4287 is a powerful argument in Atom's favor. Chip away at that spec and we're going to start hearing from Mr. Safe again.
Re: Atom Entry docs
+1 to "yeah, what Bob said". We'll still have to manage the transition around clients that don't send "type=entry" to GData services, but if we can point at an APP spec where this param is required on POST/PUT, it's possible to push through this. -- Kyle On 12/14/06, Tim Bray <[EMAIL PROTECTED]> 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. 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. -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. >
Re: Atom Entry docs
> > Bob Wyman wrote: >> There is, I think, a compromise position here which will avoid breaking >> those existing implementations which follow the existing RFC's. > > 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. > Personally, I would say that if we find the proper way to notify implementors they can't dismiss the type parameter then I'll +1 that option over the new media type. However we know that implementations won't make the effort to take it into account then what's the point over the current status? - Sylvain
Re: Atom Entry docs
Bob Wyman wrote: There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. 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. -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.
Re: Atom Entry docs
On 12/14/06, Henri Sivonen <[EMAIL PROTECTED]> wrote: On Dec 13, 2006, at 17:51, Mark Baker wrote: > But > given that an alternative exists which shouldn't break those servers, > why not use it when there's no apparent downside? The downside is that implementations that (quite reasonably) assume that application/atom+xml == feed are also reasonable when they ignore unknown media type parameters. True, but I think it's quite reasonable to interpret that behaviour as a bug. Given the options of a new type or a new parameter, I am +1 on the new type. (Although in general, I don't like the proliferation of application/*+xml types, because apps need to do root sniffing for application/xml anyway.) Let's not go there 8-) See; http://www.w3.org/2001/tag/doc/mime-respect.html#embedded Mark.
Re: Atom Entry docs
--- Bob Wyman <[EMAIL PROTECTED]> wrote: > 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) +1 on this approach. RFC4287 is a powerful argument in Atom's favor. Chip away at that spec and we're going to start hearing from Mr. Safe again.
Re: Atom Entry docs
On Dec 13, 2006, at 17:51, Mark Baker wrote: But given that an alternative exists which shouldn't break those servers, why not use it when there's no apparent downside? The downside is that implementations that (quite reasonably) assume that application/atom+xml == feed are also reasonable when they ignore unknown media type parameters. Given the options of a new type or a new parameter, I am +1 on the new type. (Although in general, I don't like the proliferation of application/*+xml types, because apps need to do root sniffing for application/xml anyway.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Atom Entry docs
2006/12/14, Bob Wyman: There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. It was exactly the point behind my proposal for this 'type' parameter. -- Thomas Broyer
