I agree that there needs to be some knowledge of how POSTing entries to a particular endpoint will behave. I don't think we should spec this though. For most cases it is just something to impart on users. If you have a POSTing endpoint labeled "New Entries" and one labeled "Import Entries" and some help text somewhere that explains the behavior, I think that is usually enough.
In special cases where machines need to understand what exactly will go on at a particular POST IRI (this or some other behavior that we cannot even imagine right now) extensions can be used. You make a good point that these expectations will be important to confirm at times, but I do not think this is core stuff. - Luke On 11/7/05, David Powell <[EMAIL PROTECTED]> wrote: > > >> Invalid Atom / atom:id handling > >> * http://www.intertwingly.net/wiki/pie/PaceMagicId (arno) > > > > Rejected. There is consensus that clients SHOULD submit valid Atom > > entries, and we do not specify any server behaviors with respect to > > handling of atom:id values. > > (see http://www.imc.org/atom-protocol/mail-archive/msg02739.html) > > (see http://www.imc.org/atom-protocol/mail-archive/msg02829.html) > > I understood "servers can choose to accept/reject whatever > they want" in those posts to mean that servers could accept/reject the > entry. <http://www.imc.org/atom-protocol/mail-archive/msg02852.html> > > This isn't the same as "not specify any server behaviours with respect > to handling of atom:id values" - which would allow servers to change > the id on the server side. > > James's rewrite of Luke's proposed consensus, quoted in the message at > <http://www.imc.org/atom-protocol/mail-archive/msg02829.html> seems to > back that up. > > > It seems unreasonable to ban servers from changing ids, but equally, > other applications rely on the id not changing. I'll try and write a > Pace on using collection metadata to indicate the semantics of POST. > > -- > Dave > >
