Subject: Author element best practice

From: Sylvain Hellegouarch <[email-masked]>
Date: Wed, 22 Nov 2006 11:11:22 +0000

Hi folks,

Quick question regarding the atom:author element in a member resource.

Say I POST an atom:entry to a collection URI, this entry does not have
an atom:author (which could be considered as not valid but that's not
the question here), now say that my app server does not have any
information as to what value to set when adding the atom:author element
to the member, do you think it'd be better to put an empty atom:name or
to put a dummy value such as 'anonymous' or 'n/a'?

I'm asking because I try to make sure that whatever the input is the
member I create are respectful of section 4.1.2 of RFC 4287 and I can't
decide which way to go when some information are missing from the context.

Any best practices from you guys?

Thanks,
- Sylvain

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Wed, 22 Nov 2006 19:43:07 +0800

Section 4.2.1 of RFC 4287:

   If an atom:entry element does not contain atom:author elements, then
   the atom:author elements of the contained atom:source element are
   considered to apply.  In an Atom Feed Document, the atom:author
   elements of the containing atom:feed element are considered to apply
   to the entry if there are no atom:author elements in the locations
   described above.

In case there isn't any author, "anonymous" seems to be a good choice. Anyway, it is just what my thought.

Franklin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sylvain Hellegouarch
Sent: Wednesday, November 22, 2006 19:11
To: atom-protocol; atom-syntax
Subject: Author element best practice

Hi folks,

Thanks,
- Sylvain

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 22 Nov 2006 18:43:08 +0100

* Sylvain Hellegouarch <[email-masked]> [2006-11-22 12:25]:
> do you think it'd be better to put an empty atom:name or to put
> a dummy value such as 'anonymous' or 'n/a'?

Ugh. Dummy values are nasty, perverse and evil. Someone *will*
eventually suffer miserably if you pollute your data like that.

Don’t you have any identifying information about who is POSTing
the entry? That’s where I’d look to.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Tim Bray <[email-masked]>
Date: Wed, 22 Nov 2006 14:38:11 -0800

On Nov 22, 2006, at 3:11 AM, Sylvain Hellegouarch wrote:

> an atom:author

If I were implementing the server, in this scenario I'd reject the  
post with an error message.  It's hard for me to see a scenario where  
the author info isn't already known and not providing it is still  
OK.  (In fact, it's hard for me to imagine a scenario in which the  
author info isn't already known, period.)  -Tim

> (which could be considered as not valid but that's not

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Wed, 22 Nov 2006 22:50:14 +0000

Tim Bray wrote:
> If I were implementing the server, in this scenario I'd reject the post
> with an error message.  It's hard for me to see a scenario where the
> author info isn't already known and not providing it is still OK.  (In
> fact, it's hard for me to imagine a scenario in which the author info
> isn't already known, period.)  -Tim

Right.
If we stretch this idea a little then, how would people feel about
stating in the draft that the server MAY (SHOULD?) reject an Atom entry
which would be invalid as per RFC 4287 ?

I think at least a MAY would give some weigh to implementors who wish to
be really strict regarding the input the allow.

- Sylvain

---

From: John Panzer <[email-masked]>
Date: Wed, 22 Nov 2006 15:17:52 -0800

>> isn't already known, period.)  -Tim
Scenario:  I have an opaque token (an encrypted cookie set on a browser, 
say) which carries the currently authenticated user's name.  I'm 
Javascript code that's running without the ability to decrypt the 
cookie, but I'm able to POST an entry to the server and have it do the 
correct thing.  Even if I specified something in the Author field, the 
server is just going to override it with the more authoritative 
encrypted cookie value.

We have actually run into this type of problem (in other situations) and 
had to modify the server to set the user name in a plain text cookie 
purely so Javascript could see it and use it.  This may not be possible 
in all situations.

I think the spirit of RFC 4287 is that readers of feeds should be able 
to rely on a standard way to find author information.  I don't think 
that speaks to this case.  I do think it'd be perfectly reasonable to 
say that a server which gets an empty author, and which cannot infer 
enough to create a valid Atom entry, should reject the entry.
-John

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 23 Nov 2006 04:28:32 +0100

* Sylvain Hellegouarch <[email-masked]> [2006-11-23 00:00]:
> how would people feel about stating in the draft that the
> server MAY (SHOULD?) reject an Atom entry which would be
> invalid as per RFC 4287 ?

+0 to MAY. I'm not sure it needs to be stated explicitly. It
seems obviously implied by the APP axiom that the server is
ultimately in control.

But -1 to SHOULD. If the server thinks it has enough data to
flesh out an incomplete entry so that it is valid, it should be
free to do as it pleases.

Regards,

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 26 Nov 2006 03:08:02 +0100

On Wed, 22 Nov 2006 23:50:14 +0100, Sylvain Hellegouarch <[email-masked]>  
wrote:

> [...] how would people feel about stating in the draft that the server
> MAY (SHOULD?) reject an Atom entry which would be invalid as per
> RFC 4287 ?

+1 to "MAY", -1 to "SHOULD".

> be really strict regarding the input the allow.

The "be lenient in what you accept" rule should not apply for APP, imo. If  
APP implementations get too lenient, the output we get in the other end  
will be even more lenient. Crap in, crap out, basically. So +1.

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: James M Snell <[email-masked]>
Date: Sun, 26 Nov 2006 20:30:17 -0800

-1. The current spec is fine as is.  It currently does not say anything
about whether or not the post entry MUST be valid although that is,
indeed the spirit of the spec.  The spec does not say that servers MUST
reject entries that are not valid.  Servers are free to accept or reject
entries as they see fit.  No change is necessary.

- James

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Mon, 27 Nov 2006 07:39:41 +0000

> entries as they see fit.  No change is necessary.

Well of course if you go from a MAY to a MUST...
Anyway, I agree with most comments until now that it is not a mandatory
step to add to the spec.

Mind you considering that RFC 4287 is very clear on what makes an Atom
entry a valid one I imagine APP servers which don't have the necessary
context will decide to reject the request altogether.

- Sylvain

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 27 Nov 2006 20:42:57 +0100

> context will decide to reject the request altogether.

Am I the only one pondering and worrying about what the different server  
implementations will respond to invalid client requests (as, for example,  
an invalid Atom document)? How can the client implementors be  
interoperable and compatible with each other and every server  
implementation if the specification says absolutely nothing about what to  
expect when something goes wrong?

HTTP covers some of the possible errors one might encounter, but I believe  
there are several cases in APP where errors might occur that HTTP does not  
cover and that server implementors will treat very differently. In most  
server application frameworks, unhandled exceptions give the response "500  
Server Error". Is that the appropriate response to give on most errors?  
Which errors should yield which 4xx response? Is this not an issue? How  
can a client tell the user how to correct something if the client have no  
idea what response to expect from the server?

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 28 Nov 2006 02:31:51 +0100

* Asbjørn Ulsberg <[email-masked]> [2006-11-27 20:55]:
> Am I the only one pondering and worrying about what the
> different server implementations will respond to invalid client
> requests (as, for example, an invalid Atom document)? How can
> the client implementors be interoperable and compatible with
> each other and every server implementation if the specification
> says absolutely nothing about what to expect when something
> goes wrong?
> 
> HTTP covers some of the possible errors one might encounter,
> but I believe there are several cases in APP where errors might
> occur that HTTP does not cover and that server implementors
> will treat very differently. In most server application
> frameworks, unhandled exceptions give the response "500 Server
> Error". Is that the appropriate response to give on most
> errors? Which errors should yield which 4xx response? Is this
> not an issue? How can a client tell the user how to correct
> something if the client have no idea what response to expect
> from the server?

I get your concern and to some extent I share it, but I’m unsure
about how it could be addressed. If we assume that servers can
implement wildly different feature sets and special cases, then
there is a huge number of conditions which the server would need
to be able to somehow signal. I don’t know how we can allow for
that. A special error document XML vocabulary for those cases
where the HTTP status is not granular enough would be an option.
Some document making suggestions about what error status codes to
use in which circumstances could also help unify expectations.
But the scope of any such endeavour will be huge…

Regards,

---

From: James M Snell <[email-masked]>
Date: Mon, 27 Nov 2006 22:02:13 -0800

I personally just think it's way too early for us to really be able to
say much about it.  So far the APP implementations that have actually
been deployed seem to work rather consistently in that I can get a
single client (e.g. Abdera) to work with each with very little effort
and only minor variations (e.g. different auth schemes, some require
Content-Length on the post, others don't, some reject invalid entries,
others don't, etc).  Based on my experience thus far, I really don't
think it is going to be much of a problem.

- James

Asbjørn Ulsberg wrote:
> [snip]
> implementations will respond to invalid client requests (as, for
> example, an invalid Atom document)? How can the client implementors be
> implementation if the specification says absolutely nothing about what
> to expect when something goes wrong?
> [snip]

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Tue, 28 Nov 2006 09:51:13 +0000

Well I share the concern because while developing amplee I ran into
issues like that. My conclusion was to apply HTTP error handling where I
could and where it made sense and leave the rest to the application
developer using amplee.

For instance return one of the 4xx error code when I meeting the
condition for it (missing Content-Length or Content-Type, etc.)

Since I started this thread I thought about it and I realized that an
APP implementation could not foresee how it would be used and in which
context. Thus it cannot safely make a decision in every use case. What
amplee does is to provide callbacks to the developer who can then decide
how to proceed.

- Sylvain