>> > Other server implementations should have the same issue, of course. >> >> So please explain me what a server currently does upon receiving an Atom >> feed on a POST to a collection that only (app:)accept (atom:)entry(ies)? >> >> Returning a 415 error code seems like the wrong option since the >> media-type is perfectly valid. So what should servers do? Should they >> pick-up randomly one of the entries part of the feed? How should UA deal >> with the returned message? > > AIUI, that's undefined, and will remain so no matter what is decided > here. I don't understand what that has to do with a new media type > breaking existing servers though.
It has everything to do within the APP context in fact. We have only one mime type for two distinct semantics (well you disagree on that statement so I can understand why we disagree with the rest). Having a new media-type (or at least the type parameter) would help APP server implementors. Therefore the way servers would handle requests. > > Of course, APP isn't finished yet, and so technically we shouldn't be > worrying about breaking implementations that "jumped the gun". But > given that an alternative exists which shouldn't break those servers, > why not use it when there's no apparent downside? We still disagree on this alternative you suggest I'm afraid. - Sylvain
