Invalid Atom Entries - id, author and link

[Thomas Broyer]

There has been discussions or allusions to POSTing invalid Atom Entries, particularly entries without atom:id, atom:author or atom:link (atom:[EMAIL PROTECTED]"alternate"] ?). Let's consider each element in some more detail. 1. atom:id "tag" URIs are relatively easy to generate [1], provided that you have the "authority" part. This could eventually be guessed, but not always (Robert doesn't own www.blogger.com [2]). However, it's a really simple configuration parameter. The window below could be shown when the user first creates an entry and hasn't yet configured the "tag-uri authority". Extensions to the protocol might add an atom:id generator, an atom:id template, a sentinel atom:id given in the introspection document, or maybe a combination of atom:id template and sentinel atom:id (the template, when processed, gives you an UUID, and the server can eventually replace it with an UUID of its own; this works only if it is clear that this might be a violation of AtomFormat). 2. atom:author Who knows who is the author of an entry more than its author, so the AtomPP client? With a non-authenticated collection (e.g. comments collection), someone willing to stay anonymous could send an empty atom:author/atom:name, or <atom:author><atom:name>Anonymous</atom:name></atom:author>. Implementations might “extend” the protocol by replacing <atom:author><atom:name>[login of authenticated user]</atom:name></atom:author> with predefined information concerning that particular user (and eventually reject the entry if the atom:name is different than the username of the authenticated user). 3. atom:link I really don't see the problem here… [1] http://www.imc.org/atom-protocol/mail-archive/msg02691.html [2] http://www.imc.org/atom-protocol/mail-archive/msg02733.html -- Thomas Broyer