questions from a naïve implementer perspective: > 8.1.1 Title: Header
can the Title header include non-ASCII characters? perhaps a simple example could be provided to nudge naïve implementers in the right direction? > 8.3.1 Editing Media Resources did I miss something ... where does the spec explain that POSTing a binary to a collection creates a corresponding atom:entry with link[rel='edit'] and content[src] pointing to the resource? should 8.3 note that the atom:entry/atom:[EMAIL PROTECTED]'edit'] for media resources would point to the media resource, and not the atom:entry itself like it says in 8.2? > 11. Example ah, I see here an example of POSTing an image ... and while there is a [EMAIL PROTECTED]'edit'] for the image, how does one edit that atom:entry itself (eg. to update any metadata)? Is this section, being an example, normative? Is the HTTP 201 response body (ie. the atom:entry for that member resource) a normative requirement, or could a server simply spit back 201 Created and no atom:entry? Where did the <summary>Waves</summary> come from? Floating an idea here: can we define a custom HTTP header for reporting the location of the associated atom:entry? Thus a POST of an image would return a "Location: URI-of-image" and also a "X-Atom-Location: URI-of-entry"? I note that the blog posting atom:entry subsequently posted includes <updated>2005-09-02T10:30:00Z</updated>, but section 8.2.1 says atom:updated is server controlled ... perhaps section 8.2.1 needs to point out that this non-editing restriction applies to changing via PUT, not creation via POST? > 9. Collections > ... a pair of positive integer indices separated by a dash character ... > The index values are 0 based ... just a nitpick ... zero is not a positive integer :-P e.
