Subject: AD Evaluation of draft-ietf-atompub-protocol-11

From: Lisa Dusseault <[email-masked]>
Date: Tue, 17 Oct 2006 15:07:44 -0700

Despite the length of these comments, I feel this specification is  
nearly there and I look forward to seeing its completion.  There are  
enough questions on this version, however, that it's worthwhile  
pointing them out so that the WG can discuss before the document goes  
out for wider review (IETF last call), to other people who haven't  
been immersed in the discussions thus far and thus don't share the  
same unstated assumptions.  If the unstated assumptions are turned  
into definitions or requirements in the document we'll get much  
better IETF and then IESG review.  Similarly, if undefined behaviors  
are explicitly flagged as "undefined", then everybody is warned about  
nasal demons <http://catb.org/jargon/html/N/nasal-demons.html> -- a  
spec that doesn't flag undefined behavior often leads to the reader  
of the spec filling in unconsciously with their own assumptions (I  
see that over and over and over again now that I'm reviewing so many  
documents and discussing reviews with others).

It would probably not be useful at this point for me to suggest a  
resolution to absolutely everything, especially if that involves  
specific wording.  It's much more likely the WG/editors would choose  
different wording and organization anyway.  But when I get back from  
vacation (1st day of November) and catch up on the mailing list  
traffic, I will see if there's any place where I can suggest wording  
to capture what I meant in a way that the WG can agree.  I understand  
there's often a balance between leaving options open for different  
implementations and extensions, and closing options down so that  
specific behavior can be depended on, and sometimes there are ways  
you can have a little of both.

High-level comments,  summarizing comments

  - The mechanism for creating a media resource and a media link  
entry in response to a single POST conflicts with at least one  
statement elsewhere in the draft, and has no example.  This is one of  
those cases where I personally had some assumptions (that not every  
media resource had its own media link entry if the media resource had  
been created manually) that weren't ever quite cleared up by the  
spec. If the client CAN create a media resource without also creating  
a media link entry, that should be a separate example.
  - Overall, the responsibility model needs to be slightly better  
defined.  E.g. we know the server is responsible for choosing a URL  
for new entries; it's not clear who's responsible for cleaning up  
linked entries if a user ever needs to clean up historical entries.   
Atom sometimes seems to split the responsibility, and those are the  
most complicated cases.  More examples below as it's probably more  
useful to discuss specifics.
  - To an outsider or newcomer -- including me even though I've been  
following discussions closely for a while -- there's a part of the  
Atom model that's subtle but important to understand.  Consumers of  
Atom feeds are supposed to look at the regular feed document, whereas  
publishers of Atom feeds are supposed to look at other, different  
resources to see how to edit or create posts.  Publishers effectively  
look at a different feed than users do, one with extra metadata (the  
rel="edit" links).  It's a different model than that of WebDAV or  
IMAP, because rather than have the client specify which metadata it's  
interested in, the server offers two choices with different  
addresses.  I believe it would be useful to cover that part of the  
model upfront in addition to the other useful stuff already there.

Creating resources

Explicit result of POST, section 4.

Are there zero, one or more resources created with a POST? There's a  
line at the top of section 4 which says that "POST is used to create  
a new, dynamically-named, resource".  However, that implies ONE,  
whereas with media entries, a POST could create TWO resources.  I  
believe a successful POST request as described here MUST either  
result in one or two resources, never zero, and never 3 or more (in  
the absence of extensions).

What is the expected behavior of seeing a POST to an entry URL  
(rather than a collection URL)?  I see that this is currently  
undefined; it may be worth stating that to warn clients.  (I'm pretty  
indifferent on this one, as in this case I can't see any obvious harm  
in different server behaviors existing,  if un-warned clients try it  
intentionally without knowing the results.  The only possible harm is  
if clients got confused, did a POST to an entry URL when a collection  
URL was intended, and the server does a success response which  
creates new resources or modifies existing resources in a way the  
client did not expect.  An error response would certainly be harmless  
for this undefined case but a success response could be real  
interesting.)

Creating entries with multiple media resources

It's never explained how a client would go about creating a feed  
entry with a number of media resources.  I imagine that it could be  
iterative; a client could create any of the resources at any time,  
and at any time after creating the feed entry, use PUT to update the  
feed entry to link to new media resources.  I assume -- though I  
didn't see it stated in the document -- that it's the client's  
responsibility in almost all cases to put links in the feed entry to  
point to the media resources, otherwise the media resources are  
unlinked (effectively hidden to readers).

The exception to this general process is if the client first uses  
POST to create both the media resource and the "Media Link Entry" in  
one go.  In this case, can the "Media Link Entry" (MLE) be  
transformed to a regular "Member Entry Resource" (MER)?  I thought it  
would be possible, but discussed just a bit with Tim today and he  
says no, so there you have two different readings of the spec.  I  
guess a related question is what would happen if a client does a PUT  
of media content to an entry resource, or entry content to a media  
resource.

It's not clear to me whether a linked media entry is always listed in  
the metadata or not.
  	- When one or more "edit-media" link relations appear, who has  
been responsible for putting them there?
	- When a media resource is deleted, who is responsible for removing  
the media resource link from the MLE?
	- Section 4 says that the MLE contains the metadata for a Media  
Resource, but that seems to only assume a single Media Resource.  In  
the case of multiple Media Resources which the user intends to link  
into a single post, it's unclear to me whether there's one MLE for  
every Media Resource, or one MER for all the Media Resources created,  
or some other situation.  Again, in quick discussion with Tim, he  
says there is one Media Link Entry per Media Resource.  I can see how  
that would work but that was not at all my understanding before the  
discussion!

This document would benefit greatly from further examples:
	1.  An example of creating a MLE and MR in a single POST; the  
request, response and the result (resource URLs) described.
	2.  An example of modifying a MER to contain a new image or other  
media resource link: the request(s), possibly the responses (if it's  
interesting, it may not be), and definitely the result.
	3.  An example of modifying a MER to change metadata (e.g. category  
or adding a new link relation element or both); possibly a failed  
request example would be even more interesting than a successful one.

Can a client modify an entry to contain a link relation element in  
the following cases:
	- To result in an "edit" or "edit-media" link relation, where the  
resource represented does not meet the requirements in section 11.1  
or 11.2?
	- To result in an "edit" link relation that actually points to a  
media resource, or a "edit-media" link relation that actually points  
to a MER?
	- To point to a resource on a different server entirely?
	- To point to a valid media resource or MER that happen to be in a  
different collection than the one normally used for this feed?
	- Will some servers forbid adding a link relation element entirely?   
Is it important for the client to know that that will always be  
forbidden for that server -- can it detect the "always forbidden"  
case separately from the "this particular edit is forbidden" case?
Which of these are errors, and if so how is the error handled?  Which  
of these MUST the server allow and handle?  I understand there may be  
some need for flexibility here.  Perhaps it's just standardized error  
messages required here.  For example, if there are some servers which  
allow a given link relation to point to another server, and some  
servers which do not allow, how would the servers which do not allow  
respond with a sufficiently specific error, so that the client can  
avoid trying the same thing again?
	
Multiple formats/langs for media resources

Multiple formats are not sufficiently defined -- e.g. JPG and PNG  
versions of an image resource.  Format negotiation is hard.  I found  
guidance for how to select among different "edit-media" link  
relations depending on format and language, but I found no guidance  
on how to create multiple versions.   If there's no guidance to  
clients or servers how to do it (would the client create multiple  
resources in different formats? could the server automatically do it  
as variants? could the server automatically do it as multiple  
resources, and would all formats be therefore listed?), it's probably  
worth considering whether there's possible interoperability harm  
here.  I can imagine clients creating alternate-format versions quite  
successfully because the operations would be explicit, but when I  
imagine how servers would go about it, I can easily see ways it could  
go wrong (e.g. creating new URLs for resources that are invisible to  
the media collection, having multiple URLs in locations where clients  
expect only one).

I think there may be a very basic confusion here -- in my head or in  
the document or both -- about what the "edit-media" link relation  
does and is for.  When I read the text it seems to offer the  
possibility for multiple formats for a single media resource, as  
suggested by the text: "If a client encounters multiple "edit-media"  
link relations in an entry then it SHOULD choose a link based on the  
client preferences for type and hreflang".  However, when I try to  
think about how a client would create a post with a totally  
independent set of JPG images (e.g. one of the Eiffel Tower, one of  
the Louvre and one of the Arche de Triomphe), the "edit-media" link  
relation also seems to have relevance. Which is it or both? (and as  
always, who is responsible for filling it in or removing it when new  
media resources are created or destroyed?)

Thomas Broyer said in email July 24 that  "Having the Content- 
Location value equal to the Location one tells the client that the  
response body is a representation of the newly created resource".    
This is a subtle reading of HTTP and, if it's true,  I want to make  
sure that implementors understand this without having to read the  
mailing list.  The spec reads " the response from the server SHOULD  
contain a Content-Location header that contains the same character-by- 
character value as the Location header."  If the response from the  
server does not contain both headers identical, what should the  
client conclude?  I think this is one of those SHOULD recommendations  
where the consequence of it not being a MUST need to be considered.   
Possibly the spec needs to say under what conditions the server would  
do otherwise; possibly the spec should say what the client knows, or  
does not know, or must do, if the server does otherwise.

Deleting Resources

In the case of an entry that points to multiple media resources, can  
the server delete all those media resources and their MLEs?  (I think  
not).  If a client issues a DELETE to a media resource, is its MLE  
deleted? (The spec covers the opposite case already when a client  
issues a DELETE to an MLE.)

Can collections be DELETEd?  It's fine for servers to allow or no,  
but if servers don't support, what error to use.

Editing resources

Overall, the process for editing a resource is not entirely clear.  I  
find the description of creating a resource (POST), and what the  
server can accept, ignore or reject, more clear than the description  
of editing a resource (PUT) .  For example, there's normative text in  
section 9.2.1 (an example) relative to creating resources and  
handling metadata, but that text isn't duplicated for editing  
resources or obviously apply to editing resources. Thus:
	- Can the client change the category?  (probably yes; MUST the  
server allow?)
	- Can the client change the atom:id?  (probably never)
	- Can the client change the "updated" value to be some time in the  
future? Some time long ago?  Or are there only two non-error changes  
-- "now" or "the previous value"?  MUST the server accept the value  
if it's the same as the previous value?  Or can there be servers that  
always ignore "updated" values from clients? (and if so, is it  
important for the client to know that the server does this)
	- Can the client change the set of link relations? (probably yes;  
but does that include "edit" and "edit-media" link relations only or  
also first/previous/next/last link relations?)
In general the possible edits need to be covered to consider whether  
the server MUST allow these kinds of edits, or MAY, and if refused,  
what error for what reason.

I already threw in a request for an example of modifying a resource  
above, because one of the cases for editing a resource is to add a  
media resource to it.

The spec says "The value of atom:updated is only changed when the  
change to a member resource is considered significant. "  The use of  
passive voice obscures who does what here.  When the client doesn't  
suggest a value for "atom:updated", does the server provide one, and  
if so, how does the server know what is "significant"?   I thought it  
would always be the client suggesting values, but Tim says that the  
server controls atom:updated which could imply that the client  
doesn't even need to suggest values.  See above about whether the  
server MUST accept certain values for "updated", or more likely, MUST  
NOT accept suggested values for "updated" when they're clearly wrong  
(e.g. this entry was last updated on October 16, 1906).

Can a server ever ignore part of an edit and successfully process the  
rest?  For example, the server receives a PUT request that tries to  
edit the text of a MER and includes a new category value, the server  
accepts the new text but silently ignores the category value.  I  
suggest the answer would be MUST NOT silently ignore suggested  
changes, particularly since there's no way in a PUT response to say  
"here's what the server actually stored".   It may be my opinion  
differs here from that of the WG.  I find silently ignoring input to  
be scary.

Synchronization

I predict that some AtomPub authoring clients will attempt to  
synchronize: to maintain an offline copy of the feed including all  
its MERs and media resources, and to keep that offline copy up-to- 
date.  Some will probably even allow offline authoring of new posts,  
and offer to synchronize when the client next goes online -- because  
of the possibility of multiple authors, this may mean at times that  
the client would download new entries created by other authors,  
upload new entries created offline, and reconcile its offline copy of  
feed documents.

Because authoring clients will attempt to do this based on Last- 
Modified and ETag -- after all, the functionality is all there in  
some form or another -- the spec needs a little more clarity on how  
the client can rely on this working.  Otherwise, some servers may  
omit features that these authoring clients require, or implement them  
oddly.  While I would never suggest repeating all the requirements  
from other specs (in this case HTTP), there are cases where clarity  
and interoperability are greatly improved by at least referencing  
explicitly requirements from HTTP.  It's also possible to add new  
requirements based on features in HTTP, that apply to Atom servers  
alone.

You can see that I lean more towards the "explain confusing things"  
side and "add more stringent requirements" than to the "it's already  
written elsewhere side" by peeking at section 8.2 of CalDAV <http:// 
www.ietf.org/internet-drafts/draft-dusseault-caldav-15.txt>.  A  
mostly-explanatory guidelines section helps clients quickly  
understand a clear path towards synchronization, and new requirements  
for supporting ETags make things easier for what is, after all, a  
more limited use case of HTTP (calendaring) than the general case.   
If HTTP synchronization in authoring cases were clearly defined and  
had not lead to years of arguments since the last HTTP update, I  
would probably feel differently about just silently relying on the  
mechanisms in HTTP.

In any case, I have very specific brief suggestions to cover  
synchronization so that it's implemented more successfully than not.
	- Consider adding a brief section offering clients non-normative  
guidelines on synchronization.  It doesn't have to limit server  
behavior so much as point out with green and red lights where the  
fairway is (mixing transportation and golfing metaphors in my head)
	- Make a few requirements of servers to avoid some of those HTTP  
ambiguities.  For example:
	"The ETag or Last-Modified values for a member resource MUST change  
when any metadata in the resource changes, as well as text/content,  
and this includes "next" and "last" link relation values.  The ETag  
or Last-Modified values of a member resource MUST NOT change solely  
because an associated other resource (e.g. the media resource being  
an associated resource to the media link entry resource) changed.  "

More open questions that might be related to synch or might have  
relevance even for clients that don't do full synch:
	- What is the relationship, if any, between the "atom:updated" value  
and the HTTP "Last-Modified" value.  Can the "atom:updated" value  
ever be later (greater) than the "Last-Modified" value?  I believe it  
can be the same or earlier, but the spec doesn't disallow the broken  
case.
	- Is it clear whether the client MUST GET the entry after modifying  
it in order to have an accurate offline cache?  (this was mentioned  
in a post by Broyer Jul 13, but not in the document).  I believe this  
is made clear already for the cases of getting the feed and also for  
POST/create, but not for PUT/modify.
	- Am I correct that the general assumption is that id's are there to  
see what entries are new, and URLs are there to see where to get  
them?  That may mean that URLs could change, for a given ID --  
Perhaps a feature to change the slug name of a image after attaching  
it.  Is that theoretically possible?

There are also efficiency considerations.
	- The spec could require that servers MUST return either the ETag,  
or the Last-Modified value, in any successful POST or PUT response.   
I personally favour this so that clients can rely on it, though  
obviously other opinions are valid here.
	- I really liked the idea of putting ETag in the author's feed, as  
discussed on the list but not appearing in the document, again for  
efficiency.
Certainly, the spec could ignore these considerations for now.   
However, I have noted that many client implementations choose a  
single way to implement their logic that can be relied upon if a  
reliable approach is available, rather than respond differently to  
different implementations.  Thus, I predict that if some servers  
implement more-efficient synchronization and others don't, clients  
will behave as if they're always talking to the less-efficient  
servers. The more-efficient servers will find it difficult to achieve  
better scalability through synch efficiency improvements because  
clients have already implemented reliable but inefficient  
synchronization and don't have reason to add a second logic path for  
the more-efficient servers.

Internationalization

How are categories compared? Case-sensitive, insensitive, according  
to which language? Would the categories "donné" and "donne" map to  
the same category as "Donne" and "DONNE"? I believe it's currently up  
to the server, which means unpredictable behavior from the point of  
view of clients. See http://www.ietf.org/internet-drafts/draft-newman- 
i18n-comparator-14.txt, which has passed IESG Evaluation except for  
some IANA actions.   This is a danger area for any draft going before  
the IESG which looks carefully at i18n these days.

How do lang tags inside the document relate to Content-Language  
information in headers? Does the most granular override the other  
possible values?  What about when client provides to server? Does the  
server ignore or handle?

Other

The requirements for the link relations "next", "previous", "first"  
and "last" aren't as rigorous as for "edit" and "edit-media" link  
relations.  Also they're defined quite separately -- I kind of  
thought that all the link relation types could be usefully defined in  
one section but if the editors prefer a different organization that's  
fine.  But; is it OK if the resource pointed to by one of these link  
relations is on another server, in another feed, is a different kind  
of resource than you might normally expect, etc... ?  I think the  
normal cases for these link relations are well-understood but not  
necessarily what a client should do if it encounters abnormal cases.

Discovering feed reading URL

A very minor feature request for the introspection document: it  
SHOULD contain the public or published read-only feed URL of the blog  
(Tim suggests using link rel="alternate" type="application/atom+xml",  
although I'm not sure that makes it sufficiently clear what it's  
for).   This so that my blog editing tool can show me not only all  
the entries and media resources (all discoverable from the  
introspection doc already) but also where the blog is published, so  
that I can copy that link to my friends when telling them about my blog.

Extensions

When the client puts extension elements in a MER, MUST the server  
store those unrecognized extension elements?  I think the answer to  
this is actually that servers often do not and should not be required  
to do so.  That makes it hard for clients to extend AtomPub's syntax  
in ways that other clients will understand but servers don't care  
about.  Consider the consequences: when some enterprising client  
developer decides to do something cool and useful and encounters  
servers that don't store their metadata in the obvious place, the  
client developer is going to quickly work around that by storing in  
some unobvious place.  For example in HTML comments in the atom entry  
content, or microformats, etc.  Is that all cool?

(Aside: an example of clients working around servers like this is  
that some WebDAV servers in the very early days didn't actually allow  
clients to PROPPATCH custom properties as the authors clearly  
intended.  Some client wanted to put extra structured information on  
a resource when it was locked.  Instead of putting it in properties,  
since that didn't work reliably, the client instead put it in the  
LOCK entry's "owner" element!  Of course that didn't reliably  
interoperate either because some servers overwrote the "owner"  
element with authoritative information -- the lock's actual owner as  
known by the server.  So the workaround solution was also harmful to  
interoperability, only it was discovered after the client had shipped.)

Workspaces

What are workspaces?  I would like to see a definition.  I believe I  
understand that basically, a workspace corresponds to a single  
published feed; that a workspace contains the collections with the  
content authored for that feed.  I know the WG discussed this so  
maybe I can suggest wording at some point or simply register my vote  
for saying what it *is*.

Besides the definition, I also wonder about workspace titles.  That  
seems redundant with the title of the entry collection and possibly  
also the title of the feed (inside the main feed document).  Is there  
any understanding of some of these values being identical, or any  
understanding of what different purpose they serve if they're not  
identical?

OPTIONS response

HTTP is unclear about where PUT and POST show up in Allow headers.   
WebDAV ran into this as an interoperability problem -- some clients  
assumed that if they didn't see PUT in the Allow header for a  
collection, they couldn't write to that collection (the client might  
be checking for permissions or policy, having already established  
that the server was a WebDAV server but not certain if PUT would be  
allowed to this particular place).  Some servers had PUT in the Allow  
header value for a collection, some servers didn't, based on the  
literal reading that you couldn't actually PUT straight to a  
collection URL.  Clients had to end up with the OPTIONS Allow: header  
response being useless in this case.  With somebody else's hindsight,  
Atom doesn't have to leave this ambiguous for the special kinds of  
resources it defines...

Cookie support, sessions, authentication

Is there an assumption that clients MUST support cookies?  without  
such a requirement explicitly stated, some clients won't, for  
reasonable security concerns.  Instead, is there an assumption that  
clients MUST repeat authentication headers with each request?  Or  
will servers effectively end up constantly "reminding" clients  
(through 401 errors) to authenticate?  This might seem obvious but it  
definitely differs from regular HTTP practice where clients  
authenticate once and then stop sending authentication information  
automatically and it just works because of cookies.  Also we'd  
experienced this as an interoperability problem in WebDAV  
interoperability tests where some server implementors insisted that  
certain WebDAV clients were completely broken in not supporting cookies.

Are there assumptions that sessions will be maintained through  
persistent connections?  I believe there should be none.  That is, if  
you're a client implementor thinking that the first request will  
contain authorization and subsequent requests on the same connection  
have no authorization, think again.

ANCHOR sections

It's not clear to me that the RFC Editor will know what to do with  
all the [[anchor... ]] sections.  Most difficult of all, "anchor37"  
says "incomplete section".  For the rest, sometimes the RFC Editor  
may need to know what to replace with what on publication.  I'm sure  
the doc editors know what they meant but I personally was left guessing.

Lisa

---

From: Eric Scheid <[email-masked]>
Date: Wed, 18 Oct 2006 09:31:37 +1000

On 18/10/06 8:07 AM, "Lisa Dusseault" <[email-masked]> wrote:

> Extensions
> 
> When the client puts extension elements in a MER, MUST the server store those
> unrecognized extension elements?  I think the answer to this is actually that
> servers often do not and should not be required to do so.  That makes it hard
> for clients to extend AtomPub's syntax in ways that other clients will
> understand but servers don't care about.  Consider the consequences: when some
> enterprising client developer decides to do something cool and useful and
> encounters servers that don't store their metadata in the obvious place, the
> client developer is going to quickly work around that by storing in some
> unobvious place.  For example in HTML comments in the atom entry content, or
> microformats, etc.  Is that all cool?  

This issue also has implications on what extensions are passed through to
the published feed ... a client might insert some extension metadata they
want published (eg. geo-coordinates), and a client might insert some
extension metadata they only want visible within the collection feed (eg.
editor workflow comments) ... with the understanding also that if the server
actually understands a particular extension it might result in extensions
being added/modified outside of the bucket (eg. <ext:include
trackbacks="yes" /> resulting in lots of <link/> elements being added)

We did at one time discuss providing a bucket container specifically for the
latter, with the assumption that extensions outside the bucket are data
elements meant for publication. Having a bucket container would make life
simpler for server implementations -- just store everything as an xml blob,
the same as they do for atom:content[@type=xhtml].

Lisa, would that help?

e.

---

From: James M Snell <[email-masked]>
Date: Tue, 17 Oct 2006 16:40:51 -0700

Some comments... largely written up in terms of what my working
assumptions have been. We'll see how things match up with what others on
the list are thinking.

- James

Lisa Dusseault wrote:
> [snip]
> *High-level comments,  summarizing comments*
> 
>  - The mechanism for creating a media resource and a media link entry in
> response to a single POST conflicts with at least one statement
> elsewhere in the draft, and has no example.  This is one of those cases
> where I personally had some assumptions (that not every media resource
> had its own media link entry if the media resource had been created
> manually) that weren't ever quite cleared up by the spec. If the client
> CAN create a media resource without also creating a media link entry,
> that should be a separate example.

My assumption: a client cannot create a media resource without also
creating a media link entry.  When I POST a media resource to a
collection, a media link entry is *always* created.

> defined.  E.g. we know the server is responsible for choosing a URL for
> new entries; it's not clear who's responsible for cleaning up linked
> entries if a user ever needs to clean up historical entries.  Atom
> sometimes seems to split the responsibility, and those are the most
> complicated cases.  More examples below as it's probably more useful to
> discuss specifics.

My assumption: the server is ultimately responsible for everything.  If
the server wishes to give me a mechanism for deleting old entries, then
it's the server's responsibility for ensuring that the results of that
operation are consistent and correct.

> following discussions closely for a while -- there's a part of the Atom
> model that's subtle but important to understand.  Consumers of Atom
> feeds are supposed to look at the regular feed document, whereas
> rel="edit" links).  It's a different model than that of WebDAV or IMAP,
> because rather than have the client specify which metadata it's
> interested in, the server offers two choices with different addresses. 
> I believe it would be useful to cover that part of the model upfront in
> addition to the other useful stuff already there.
> 

My assumption:  The separation between "subscription feeds" and
"collection feeds" is not always clear.  There are at least two deployed
implementations I am aware of that use the same feeds for both and I'm
currently working on a third.  In Google's new Blogger Beta, for
instance, the subscription feed is also the collection feed.

I believe that any assumption that the subscription and collections
feeds will always be different is incorrect and dangerous.

> *Creating resources*
> line at the top of section 4 which says that "POST is used to create a
> new, dynamically-named, resource".  However, that implies ONE, whereas
> with media entries, a POST could create TWO resources.  I believe a
> successful POST request as described here MUST either result in one or
> two resources, never zero, and never 3 or more (in the absence of
> extensions).

My assumption: A POST could actually create any number of resources.
For instance, when I POST an entry to my weblog, at least two resources
will be created (the editable entry and the HTML "permalink" page) and
several others will be modified (the collection feed, the blog index
page, archive pages, etc).  Similarly, when I POST a media resource, I
would expect that multiple resources could be created.  How many
resources are created/modified is up to the server implementation.  From
the client's point of view, there are only two resources that are of
immediate concern: the atom:entry and the collection feed.  At the very
least, A successful POST should result in the creation of the
atom:entry.  No other assumptions can be made beyond that.

> 
> What is the expected behavior of seeing a POST to an entry URL (rather
> than a collection URL)?  I see that this is currently undefined; it may
> be worth stating that to warn clients.  (I'm pretty indifferent on this
> one, as in this case I can't see any obvious harm in different server
> behaviors existing,  if un-warned clients try it intentionally without
> knowing the results.  The only possible harm is if clients got confused,
> did a POST to an entry URL when a collection URL was intended, and the
> server does a success response which creates new resources or modifies
> existing resources in a way the client did not expect.  An error
> response would certainly be harmless for this undefined case but a
> success response could be real interesting.)
> 

My assumption: This has always been left undefined.  There are at least
two different implementations that do different things with the POST
operation on an entry.  GData, for instance, supports using POST as a
way of working around PUT/DELETE blocking issues.  IBM's OpenActivities
uses POST, in part, to support a variety of extended operations such as
undelete.  Eventually, conventions for the use of POST on an Edit URI
may emerge.  For now, it's best to leave it undefined.

> It's never explained how a client would go about creating a feed entry
> with a number of media resources.  I imagine that it could be iterative;
> a client could create any of the resources at any time, and at any time
> after creating the feed entry, use PUT to update the feed entry to link
> to new media resources.  I assume -- though I didn't see it stated in
> the document -- that it's the client's responsibility in almost all
> cases to put links in the feed entry to point to the media resources,
> otherwise the media resources are unlinked (effectively hidden to
> readers).  
> 

My assumption: The relationship between a media link entry and a media
resource is always 1-to-1.  If I want an entry to point to multiple
media resources, then I would create one media link entry for each media
resource, then create a separate entry that points to each of the
individually created media resources.

e.g.,

   entry1 --> pic1
   entry2 --> pic2
   entry3 --> pic3
   entry4 --> pic1
          --> pic2
          --> pic3

Entries 1, 2 and 3 will always point to their respective media resources
(using atom:content/@src).

> The exception to this general process is if the client first uses POST
> to create both the media resource and the "Media Link Entry" in one go. 
> In this case, can the "Media Link Entry" (MLE) be transformed to a
> regular "Member Entry Resource" (MER)?  I thought it would be possible,
> but discussed just a bit with Tim today and he says no, so there you
> have two different readings of the spec.  I guess a related question is
> what would happen if a client does a PUT of media content to an entry
> resource, or entry content to a media resource.  
> 

My assumption: I had originally wanted the ability to change "MLE" into
a "MER" but the general consensus of the WG seemed to be leading in the
other direction.  Once a media link entry is created, it cannot be
changed into some other kind of thing.  I personally think that's bogus,
but...

Regarding what would happen if a client does attempt to change the type
of resource, that's undefined.  In my current implementation, the new
content would be silently discarded, which is bogus.  I'll likely change
the behavior so that the request is rejected.

> It's not clear to me whether a linked media entry is always listed in

My assumption: Yes

>   - When one or more "edit-media" link relations appear, who has been
> responsible for putting them there? 

My assumption: the Server

> - When a media resource is deleted, who is responsible for removing the
> media resource link from the MLE?

My assumption: the Server.  When the media resource is deleted, the
associated MLE SHOULD also be deleted.

> Resource, but that seems to only assume a single Media Resource.  In the
> case of multiple Media Resources which the user intends to link into a
> single post, it's unclear to me whether there's one MLE for every Media
> Resource, or one MER for all the Media Resources created, or some other
> situation.  Again, in quick discussion with Tim, he says there is one
> Media Link Entry per Media Resource.  I can see how that would work but
> that was not at all my understanding before the discussion!
> 

See above.

> 1.  An example of creating a MLE and MR in a single POST; the request,
> response and the result (resource URLs) described.

Section 9.6.2 already contains such an example.

> 2.  An example of modifying a MER to contain a new image or other media
> resource link: the request(s), possibly the responses (if it's

Agree. This would be helpful.

> 3.  An example of modifying a MER to change metadata (e.g. category or
> adding a new link relation element or both); possibly a failed request
> example would be even more interesting than a successful one.
> 

Agree.

> Can a client modify an entry to contain a link relation element in the
> following cases:
> resource represented does not meet the requirements in section 11.1 or 11.2?
> - To result in an "edit" link relation that actually points to a media
> resource, or a "edit-media" link relation that actually points to a MER? 

My assumption: the server is responsible for adding the edit and
edit-media links. Clients are not allowed to modify these values.

> - Will some servers forbid adding a link relation element entirely?  Is
> it important for the client to know that that will always be forbidden
> for that server -- can it detect the "always forbidden" case separately
> from the "this particular edit is forbidden" case?

My assumption: the decision is ultimately up to individual server
implementations, but in general clients should be allowed to add/edit
all link relations other than the edit and edit-media links.  It is
unlikely, however, that your typical blog implementation of APP would
allow a client to modify the alternate link relation.

> Which of these are errors, and if so how is the error handled?  Which of
> these MUST the server allow and handle?  I understand there may be some
> need for flexibility here.  Perhaps it's just standardized error
> allow a given link relation to point to another server, and some servers
> which do not allow, how would the servers which do not allow respond
> with a sufficiently specific error, so that the client can avoid trying
> the same thing again?
> 

My assumption: different servers are going to have different
requirements.  This needs to remain as flexible as possible.  A standard
way of reporting errors would be helpful, but trying to dictate too much
in this area will just lead to headaches.

> guidance for how to select among different "edit-media" link relations
> depending on format and language, but I found no guidance on how to
> create multiple versions.   If there's no guidance to clients or servers
> how to do it (would the client create multiple resources in different
> formats? 

Yes.

> could the server automatically do it as variants? 

Yes.

> could the server automatically do it as multiple resources, and would
all formats
> be therefore listed?),

Yes.

> it's probably worth considering whether there's
> possible interoperability harm here.  

The behavior is ultimately up to the server.  No normative behavior
should be specified (largely because we're not yet sure what all folks
will actually want to do).

> I can imagine clients creating
> alternate-format versions quite successfully because the operations
> would be explicit, but when I imagine how servers would go about it, I
> can easily see ways it could go wrong (e.g. creating new URLs for
> resources that are invisible to the media collection, having multiple
> URLs in locations where clients expect only one).
> 

Again, it's the individual server implementations responsibility to keep
all this straight.  Yes, there is a good possibility that some servers
will screw it up, but that's ok.

> I think there may be a very basic confusion here -- in my head or in the
> document or both -- about what the "edit-media" link relation does and
> is for.  When I read the text it seems to offer the possibility for
> multiple formats for a single media resource, as suggested by the text:
> "If a client encounters multiple "edit-media" link relations in an entry
> then it SHOULD choose a link based on the client preferences for type
> and hreflang".  However, when I try to think about how a client would
> create a post with a totally independent set of JPG images (e.g. one of
> the Eiffel Tower, one of the Louvre and one of the Arche de Triomphe),
> the "edit-media" link relation also seems to have relevance. Which is it
> or both? (and as always, who is responsible for filling it in or
> removing it when new media resources are created or destroyed?)
> 

My assumption: the edit-media link relation is primarily intended to
allow media resources to be edited independently of their associated
Media link entry.  The fact that multiple edit-media links may be
present is secondary and orthogonal to this main purpose.

> Thomas Broyer said in email July 24 that  "Having the Content-Location
> value equal to the Location one tells the client that the response body
> is a representation of the newly created resource".   This is a subtle
> reading of HTTP and, if it's true,  I want to make sure that
> implementors understand this without having to read the mailing list. 
> The spec reads " the response from the server SHOULD contain a
> Content-Location header that contains the same character-by-character
> value as the Location header."  If the response from the server does not
> contain both headers identical, what should the client conclude?  I
> think this is one of those SHOULD recommendations where the consequence
> of it not being a MUST need to be considered.  Possibly the spec needs
> to say under what conditions the server would do otherwise; possibly the
> spec should say what the client knows, or does not know, or must do, if
> the server does otherwise.
> 

My assumption: IMHO, this recommendation no longer unnecessary given
that our recent decision to require that the Location header always
point to the Edit URI of the resource created. I'd prefer that it be
removed.

> *Deleting Resources*
> 
> In the case of an entry that points to multiple media resources, can the
> server delete all those media resources and their MLEs?  (I think not). 
> If a client issues a DELETE to a media resource, is its MLE deleted?
> (The spec covers the opposite case already when a client issues a DELETE
> to an MLE.)  

My assumption: If a client DELETE's a MLE, it's associated media
resource SHOULD be deleted.  If the client DELETE's the media resource,
the MLE SHOULD be deleted.  If the client DELETE's an entry that links
to a media resource in any other way (e.g. there is some other kind of
link relation or an img tag in html content, etc) then the "correct"
behavior is up to the server.

> 
> Can collections be DELETEd?  It's fine for servers to allow or no, but
> if servers don't support, what error to use.
> 

My assumption: It's up to the server. 405 Method Not Allowed.

> *Editing resources*
> find the description of creating a resource (POST), and what the server
> can accept, ignore or reject, more clear than the description of editing
> a resource (PUT) .  For example, there's normative text in section 9.2.1
> (an example) relative to creating resources and handling metadata, but
> that text isn't duplicated for editing resources or obviously apply to
> editing resources. Thus: 
> - Can the client change the category?  (probably yes; MUST the server
> allow?)

Generally Yes. It's up to the server.

> - Can the client change the atom:id?  (probably never)

No.

> future? Some time long ago?  Or are there only two non-error changes --
> "now" or "the previous value"?  MUST the server accept the value if it's
> the same as the previous value?  Or can there be servers that always
> ignore "updated" values from clients? (and if so, is it important for
> the client to know that the server does this)

Generally No, but it's up to the server.  For the most part, servers
should and will manage the value of atom:updated themselves.

> - Can the client change the set of link relations? (probably yes; but
> does that include "edit" and "edit-media" link relations only or also
> first/previous/next/last link relations?)
> In general the possible edits need to be covered to consider whether the
> server MUST allow these kinds of edits, or MAY, and if refused, what
> error for what reason.

Generally Yes, with the exception of edit and edit-media and possibly
alternate, all of which the server will usually manage.

> [snip]
> The spec says "The value of atom:updated is only changed when the change
> to a member resource is considered significant. "  The use of passive
> voice obscures who does what here.  When the client doesn't suggest a
> value for "atom:updated", does the server provide one, and if so, how
> does the server know what is "significant"?   I thought it would always
> be the client suggesting values, but Tim says that the server controls
> atom:updated which could imply that the client doesn't even need to
> suggest values.  See above about whether the server MUST accept certain
> values for "updated", or more likely, MUST NOT accept suggested values
> for "updated" when they're clearly wrong (e.g. this entry was last
> updated on October 16, 1906).
> 

My assumption: Tim is correct.  The server controls atom:updated. While
the client is required to provide a valid atom:updated element, the
server can (and in most cases will) ignore that value.

> rest?  For example, the server receives a PUT request that tries to edit
> the text of a MER and includes a new category value, the server accepts
> the new text but silently ignores the category value.  I suggest the
> answer would be MUST NOT silently ignore suggested changes, particularly
> since there's no way in a PUT response to say "here's what the server
> actually stored".   It may be my opinion differs here from that of the
> WG.  I find silently ignoring input to be scary.
> 

My assumption: Yes, it's up to the server.  In general, servers should
not make a habit of applying partial updates unless the client is aware
that data loss could happen.  Current implementations handle this
differently.

> *Synchronization*
> synchronize: to maintain an offline copy of the feed including all its
> MERs and media resources, and to keep that offline copy up-to-date. 
> Some will probably even allow offline authoring of new posts, and offer
> to synchronize when the client next goes online -- because of the
> possibility of multiple authors, this may mean at times that the client
> would download new entries created by other authors, upload new entries
> created offline, and reconcile its offline copy of feed documents.
> 
> Because authoring clients will attempt to do this based on Last-Modified
> and ETag -- after all, the functionality is all there in some form or
> another -- the spec needs a little more clarity on how the client can
> rely on this working.  Otherwise, some servers may omit features that
> these authoring clients require, or implement them oddly.  While I would
> never suggest repeating all the requirements from other specs (in this
> case HTTP), there are cases where clarity and interoperability are
> greatly improved by at least referencing explicitly requirements from
> HTTP.  It's also possible to add new requirements based on features in
> HTTP, that apply to Atom servers alone.  
> 

I would be very happy to see some discussion of this in the spec,
especially if it normatively required the use of ETags for offline
synchronization.

>[snip]
> of HTTP (calendaring) than the general case.  If HTTP synchronization in
> authoring cases were clearly defined and had not lead to years of
> arguments since the last HTTP update, I would probably feel differently
> about just silently relying on the mechanisms in HTTP.  
> 

+1

> guidelines on synchronization.  It doesn't have to limit server behavior
> so much as point out with green and red lights where the fairway is
> (mixing transportation and golfing metaphors in my head)
> "The ETag or Last-Modified values for a member resource MUST change when
> any metadata in the resource changes, as well as text/content, and this
> includes "next" and "last" link relation values.  The ETag or
> Last-Modified values of a member resource MUST NOT change solely because
> an associated other resource (e.g. the media resource being an
> associated resource to the media link entry resource) changed.  " 

+0.5. I would add that the ETag/Last-Modified values of a resource
SHOULD NOT change solely because of non-significant changes to the
infoset serialization of an entry (e.g. a different namespace prefix is
used, or whitespace is added or removed, etc).  I would also prefer that
the ETag for a MLE change when it's associated media resource is updated.

> - What is the relationship, if any, between the "atom:updated" value and
> the HTTP "Last-Modified" value.  Can the "atom:updated" value ever be
> later (greater) than the "Last-Modified" value?  I believe it can be the
> same or earlier, but the spec doesn't disallow the broken case.

My assumption: There is no relationship.  atom:updated should be treated
as being entirely independent of Last-Modified.  It might be reasonable,
however, to define a relationship between Last-Modified and app:edited.

> - Is it clear whether the client MUST GET the entry after modifying it
> in order to have an accurate offline cache?  (this was mentioned in a
> post by Broyer Jul 13, but not in the document).  I believe this is made
> clear already for the cases of getting the feed and also for

My assumption: Yes.

> - Am I correct that the general assumption is that id's are there to see
> what entries are new, and URLs are there to see where to get them?  That
> may mean that URLs could change, for a given ID -- Perhaps a feature to
> change the slug name of a image after attaching it.  Is that
> theoretically possible?

My assumption: Yes. ID's also help to detect changes so that old entries
are not flagged as new when insignificant updates are made.

> - The spec could require that servers MUST return either the ETag, or
> the Last-Modified value, in any successful POST or PUT response.  I
> personally favour this so that clients can rely on it, though obviously
> other opinions are valid here.

I'd prefer this.  My current implementation always returns the ETag on
the POST response.

> discussed on the list but not appearing in the document, again for

Are you referring to the app:etag element?

> [snip]
> *Internationalization*
> 
> How are categories compared? Case-sensitive, insensitive, according to
> which language? Would the categories "donné" and "donne" map to the same
> category as "Donne" and "DONNE"? I believe it's currently up to the
> server, which means unpredictable behavior from the point of view of
> clients.

This is a separate issue that impacts RFC4287 in general more than it
does APP specifically.  My assumption has always been that categories
are compared using case-sensitive, character-by-character analysis of
the scheme and the term, regardless of language.  Your four examples
would each evaluate to different categories.

> See http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-14.txt,
> which has passed IESG Evaluation except for some IANA actions.   This is
> a danger area for any draft going before the IESG which looks carefully
> at i18n these days.
> 

My assumption: yes, the most granular overrides. It's up to the server
to ignore or handle with the preference between towards handling.

> *Other*
> 
> The requirements for the link relations "next", "previous", "first" and
> "last" aren't as rigorous as for "edit" and "edit-media" link
> relations.  Also they're defined quite separately -- I kind of thought
> that all the link relation types could be usefully defined in one
> section but if the editors prefer a different organization that's fine. 
> But; is it OK if the resource pointed to by one of these link relations
> is on another server, in another feed, is a different kind of resource
> than you might normally expect, etc... ?  I think the normal cases for
> these link relations are well-understood but not necessarily what a
> client should do if it encounters abnormal cases.
> 

I've always been bugged by the underspecification of this section.
Given that there is a separate Feed Paging spec that is nearing
completion, I'd be very happy if paging were removed completely from the
APP spec.

> A very minor feature request for the introspection document: it SHOULD
> contain the public or published read-only feed URL of the blog (Tim
> suggests using link rel="alternate" type="application/atom+xml",
> although I'm not sure that makes it sufficiently clear what it's for).  
> This so that my blog editing tool can show me not only all the entries
> and media resources (all discoverable from the introspection doc
> already) but also where the blog is published, so that I can copy that
> link to my friends when telling them about my blog.
> 

Using alternate links for feed discovery is a sufficiently well-known
common practice.  It would likely be fine.

> Extensions
> 
> When the client puts extension elements in a MER, MUST the server store
> those unrecognized extension elements?  I think the answer to this is
> actually that servers often do not and should not be required to do so. 
> That makes it hard for clients to extend AtomPub's syntax in ways that
> other clients will understand but servers don't care about.  Consider
> the consequences: when some enterprising client developer decides to do
> something cool and useful and encounters servers that don't store their
> metadata in the obvious place, the client developer is going to quickly
> work around that by storing in some unobvious place.  For example in
> HTML comments in the atom entry content, or microformats, etc.  Is that
> all cool?  

It's up to the server.  Google's GData, for instance, will reject
entries that use unknown foreign markup.  IBM's OpenActivities will
silently dropped unknown markup.  The implementation I'm working on
currently will retain all unknown foreign markup. I'd prefer to leave
this open.

> [snip]
> understand that basically, a workspace corresponds to a single published
> feed; that a workspace contains the collections with the content
> authored for that feed.  I know the WG discussed this so maybe I can
> suggest wording at some point or simply register my vote for saying what
> it *is*.  
> 

No, a workspace is a purely organizational construct that will vary
depending on context.  For instance, services like GData could offer a
service document with one workspace per service (e.g. Blogger, Calendar,
Base, etc) or, an implementation could offer a service document with
different workspaces segmented along other lines (e.g. "Private
Collections" "Shared Collections", "Team Collections", etc). The
intention is purely to provide a means of grouping related collections
in a logical way.  There is no correlation between a workspace and the
number of available feeds.

> seems redundant with the title of the entry collection and possibly also
> the title of the feed (inside the main feed document).  Is there any
> understanding of some of these values being identical, or any
> understanding of what different purpose they serve if they're not identical?
> 

Again, there is no correlation between a "Workspace" and a feed.  A
workspace title may be something like "James' Private Collections",
which may consist of twenty six individual feeds each titled with a
letter of the english alphabet.

> collection, they couldn't write to that collection (the client might be
> checking for permissions or policy, having already established that the
> server was a WebDAV server but not certain if PUT would be allowed to
> this particular place).  Some servers had PUT in the Allow header value
> for a collection, some servers didn't, based on the literal reading that
> you couldn't actually PUT straight to a collection URL.  Clients had to
> end up with the OPTIONS Allow: header response being useless in this
> case.  With somebody else's hindsight, Atom doesn't have to leave this
> ambiguous for the special kinds of resources it defines...
> 

In my impl, the server will always report all of the operations that can
be applied to a resource, regardless of whether the current user is
allowed to use those methods.  A collection, for instance, will always
specify (at a minimum) the GET and POST methods.  An Edit URI will
always specify (at a minimum) the GET, PUT and DELETE methods.

> Is there an assumption that clients MUST support cookies?  without such
> a requirement explicitly stated, some clients won't, for reasonable
> security concerns.  Instead, is there an assumption that clients MUST
> repeat authentication headers with each request?  Or will servers
> effectively end up constantly "reminding" clients (through 401 errors)
> to authenticate?  This might seem obvious but it definitely differs from
> regular HTTP practice where clients authenticate once and then stop
> sending authentication information automatically and it just works
> because of cookies.  Also we'd experienced this as an interoperability
> problem in WebDAV interoperability tests where some server implementors
> insisted that certain WebDAV clients were completely broken in not
> supporting cookies.

My assumption: the client should generally assume that auth headers
should be sent with each request and that cookies are likely not
supported.  However, this is another case where the behavior is
completely up to the server.

> you're a client implementor thinking that the first request will contain
> authorization and subsequent requests on the same connection have no
> authorization, think again.
> 

My asssumption: client's should not assume that connections will be
persistent or that sessions will be maintained (or that a session even
exists).  Each request is independent of all others.

Excellent feedback.  Thanks for taking the time.

- James

---

From: James M Snell <[email-masked]>
Date: Tue, 17 Oct 2006 16:55:59 -0700

That "bucket" already exists in the form of the app:control element.

 <entry>
   ...
   <x:foo />
   ...
   <app:control>
     ...
     <x:bar />
     ...
   </app:control>
 </entry>

- James

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 17 Oct 2006 17:16:44 -0700

Yes, absolutely, a way to distinguish extensions-to-the-entry from  
extensions-for-the-feed would be great, even if there's a possibility  
that the server would reject one or both.  I hadn't even considered  
that, must have missed that discussion.  Client-to-client extensions  
(metadata or markup that the server can safely ignore and pass  
through from author to feed consumer) seem very likely and useful in  
Atom, even more so than in other applications I've compared to  
(calendaring, file sharing, email).

I guess I can turn the flexibility argument around: imagine if Web  
servers in 1995 rejected, just refused to store, anything that wasn't  
defined in HTML 3.0; the Web never would have been as flexible as it  
is today.  Of course we can't require Web servers or Atom servers to  
absolutely accept all content, but we can make it clear what the  
expectation is and perhaps even offer safe ways of violating the  
expectation.

Lisa

On Oct 17, 2006, at 4:31 PM, Eric Scheid wrote:

>> store those

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 Oct 2006 17:18:11 -0700

I also noticed the split that Lisa mentions when reviewing the draft.

I agree that they're not always separate, but it should be pointed  
out that they can be separate. I didn't see any mechanism to discover  
what the URI of the "normal" feed is, beyond a link/@rel=alternate in  
the collection feed; did I miss something?

If that's the way to do it, it would be good to call it out (it might  
be preferable to have a separate link relation, as the semantic isn't  
just "alternate", but "public", etc.). It might also be good to have  
something that allows distinguishing between the two (without forcing  
it) in the service document.

Cheers,

--
Mark Nottingham     http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Tue, 17 Oct 2006 17:26:13 -0700

Given that folks are already accustomed to using alternate links to
discover subscription feeds, I think it would be reasonable for us to
include some statement that within a collection feed, an alternate link
with a type of "application/atom+xml" SHOULD be used to point to the
public representation of a feed.

e.g.,

<feed>
  ...
  <id>tag:example.org,2006:foo</id>
  <link type="application/atom+xml"
        href="http://example.org/feed.xml" />
  <link type="application/atom+xml"
        rel="self"
        href="http://edit.example.org/app/foo" />
  ...
</feed>

This would go nicely with the use of the alternate link in member
entries to point to the public representation of the entry.

As Tim suggested, using the alternate link in the service doc would be
appropriate.

<service>
  <workspace>
    <atom:title>My Workspace</atom:title>
    <collection href="http://edit.example.org/app/foo">
      ...
      <atom:link type="application/atom+xml"
                 href="http://example.org/feed.xml" />
      ...
    </collection>
  </workspace>
</service>

I'd suspect that a lot of existing feed auto-discovery code could be
adapted to support this without much difficulty.

- James

Mark Nottingham wrote:
> I agree that they're not always separate, but it should be pointed out
> that they can be separate. I didn't see any mechanism to discover what
> the URI of the "normal" feed is, beyond a link/@rel=alternate in the
> collection feed; did I miss something?
> 
> If that's the way to do it, it would be good to call it out (it might be
> preferable to have a separate link relation, as the semantic isn't just
> "alternate", but "public", etc.). It might also be good to have

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Wed, 18 Oct 2006 09:04:40 +0100

> collection, a media link entry is *always* created.

Same here. Lisa what do you mean by creating a media resource manually?
If you do not use an APP service to create a media resource then it does
not fall into APP to tell how this resource will be accessible. To me
it's like it's not even part of the collection.

> instance, the subscription feed is also the collection feed.

I would rather have distinct feed for both always but ultimately it's
still just an atom feed. Atom rules apply the same way in both cases.
I fail to find a case where it can be a real issue to use the same feed.

>> two resources, never zero, and never 3 or more (in the absence of

Section 9.5 says:

   A client can POST a media type other than application/atom+xml to a
   Collection.  Such a request creates two new resources - one that
   corresponds to the entity sent in the request, called the Media
   Resource, and an associated Member Entry, called the Media Link
   Entry.

I find that quite clear at least regarding media resource.

>> success response could be real interesting.)

I would say a server not sending a 405 or any other 40x is broken in
that case.

+1

> the behavior so that the request is rejected.

I think we had that discussion a few weeks ago and it had been agreed
that a PUT could change the type of the MLE.

I do hope the WG will draw a clear line on that matter because I won't
have the possibility to chit-chat with Tim myself to know about it...

>> It's not clear to me whether a linked media entry is always listed in

Same here.

> My assumption: the Server

APP should maybe rule out that if a 'edita-media' appears there can only
be one.

> associated MLE SHOULD also be deleted.

Agreed however... it would be nice if section 9.4 could explain it that
way. Currently it only mentions the deletion of the MLE itself resulting
in the deletion of the media resource.

> edit-media links. Clients are not allowed to modify these values.

Agreed. Servers should silently disregard modification to those links.

> allow a client to modify the alternate link relation.

Agreed.

> will actually want to do).

Much agreed with James again.

> point to the Edit URI of the resource created. I'd prefer that it be

Agreed with James.

> behavior is up to the server.

Agreed.

> My assumption: It's up to the server. 405 Method Not Allowed.

Indeed. After all APP is based on HTTP so let's use HTTP error codes.

> Generally Yes. It's up to the server.

I would say yes as well. I think there are only a very limited set  of
elements client MUST NOT be allowed to edit: id, edit and edit-media
links, content, published, update, edited. IMO the rest should be safe
for modification.

> always specify (at a minimum) the GET, PUT and DELETE methods.

Same in my implementation

- Sylvain

---

From: Andreas Sewe <[email-masked]>
Date: Wed, 18 Oct 2006 13:58:47 +0200

> atom:entry.  No other assumptions can be made beyond that.

Even the assumption that a successful POST results in the creation of an 
atom:entry may be false; consider the case of a moderated collection 
responding with a "202 Accepted". Hence a successful ("2xx" response 
code) POST can very well end up creating no resources whatsoever.

That being said, a successful POST might, on the other hand, create more 
than two resources as well. As server could, e.g., automatically convert 
image/gif media resource to image/png, making both available.

At least that's the way I see these things.

Regards,

Andreas Sewe

---

From: Henry Story <[email-masked]>
Date: Wed, 18 Oct 2006 15:56:34 +0200

On 18 Oct 2006, at 01:40, James M Snell wrote:

>> change

Completely disagree.
If the server controls atom:updated then what was the point of the  
whole discussion of app:edited?
the client controls app:edited. It is the client who decides what if  
there was a significant change.
The server controls app:edited. Any edit, changes app:edited.

If you have it your way, then atom:updated will end up meaning  
app:edited, which Tim Bray specifically mentioned he did not want in  
his wiki example.

Henry

---

From: Henry Story <[email-masked]>
Date: Wed, 18 Oct 2006 16:28:43 +0200

Many thanks to Lisa for the lengthy and detailed comments. I am just  
replying to those comments relating to the parts of the spec I  
understand best.

On 18 Oct 2006, at 01:40, James M Snell wrote:

>> its
>> Modified

I think synchronisation would be best dealt with by adding  
functionality to sort the collection in different ways.
Currently the sort order is a SHOULD on atom:updated. That does not  
allow clients to find the most recent edits. If there were a way to  
sort the entries by app:edited one could find the most recent edits  
quite quickly. Doing a HEAD on all the entries to find out which  
changed by comparing etags is not really an option. For large blogs  
such as Tim Bray's ongoing this would use up way to many resources  
and take way too long.

>> behavior
> as being entirely independent of Last-Modified.

yes.

> It might be reasonable,

No. In discussions on the topic of synchronisation it became obvious  
that people wanted to have servers add properties to entries, such as  
changing the number of comments for an entry, without this changing  
app:edited.

A new app:modified would be the closest to something that could have  
a 1-1 relation to Last-Modified. But there was a lot of push back  
against app:modified as being too britle - ie. changing too often  
(xml formating changes could cause app:modified to change)

> are not flagged as new when insignificant updates are made.

yes. Id's are there also to be able to find multiple versions of a  
same document.

> I'd prefer this.  My current implementation always returns the ETag on

I think it is a good idea to return Etags in the header. Well written  
clients should keep track of them.

> Are you referring to the app:etag element?

This is no longer necessary, with app:edited. The client can keep  
track of etags by keeping the http header info. There is no need to  
place this in the entry itself.

Henry

---

From: James M Snell <[email-masked]>
Date: Wed, 18 Oct 2006 07:34:15 -0700

No, it means only that it's the server's responsibility to determine
when atom:updated should be updated and when it shouldn't.  If the
server wishes to delegate that responsibility to the client, then that's
fine.

- James

Henry Story wrote:
> [snip]
> Completely disagree.
> If the server controls atom:updated then what was the point of the whole
> discussion of app:edited?
> app:edited, which Tim Bray specifically mentioned he did not want in his
> wiki example.
> 
> Henry
>

---

From: Henry Story <[email-masked]>
Date: Wed, 18 Oct 2006 16:35:25 +0200

On 18 Oct 2006, at 16:10, John Panzer wrote:
	
>> If the server controls atom:updated then what was the point of  
>> the  whole discussion of app:edited?
>> the client controls app:edited. It is the client who decides what  
>> if  there was a significant change.
> I think you have a typo somewhere in the above.

Duh. You are right. I wish there were unit tests for typing docs. Why  
is it one always has to test everything in life?

I meant:

If the server controls atom:updated then what was the point of the   
whole discussion of app:edited?
The client controls atom:updated. It is the client who decides what a  
significant change is.

The server controls app:edited. Any edit changes app:edited.

Henry

---

From: Henry Story <[email-masked]>
Date: Wed, 18 Oct 2006 16:46:29 +0200

> server wishes to delegate that responsibility to the client, then  

Is this not splitting hairs a little? In the end it is always the  
server who is going to decide if it wants to accept anything at all.  
The server could also change the content if it wished (though I would  
not use such a service, having lived through the greed of the .com,  
we can be assured that servers will want to add their adds to your  
content). If we use the word responsibility this way then it's not  
going to help us distinguish anything interesting.

When it comes down to it, my feeling was that the client decides  
whether or not it wants to check that box "significant update" or  
not. The client does not have any say in what the value of app:edited  
is.

But special cases can be made. It's just that those would be  
understood to be deviations from the norm.

> - James
>
> Henry Story meant to write:
>> [snip]
>> The client controls atom:updated. It is the client who decides  
>> what a significant change is.
>>

---

From: James M Snell <[email-masked]>
Date: Wed, 18 Oct 2006 11:45:32 -0700

I think it is important in order to make the distinction between whether
the server MUST, SHOULD or MAY accept the atom:updated value provided by
the client.  I would argue that it needs to be a MAY with a clear
statement that allowing the client to set the value is quite likely
going to be very useful.

The bottom line for me is that I do not yet believe we have enough of an
understanding how folks are going to be using the protocol.  Stir in too
many MUSTs and SHOULDs and you end up needlessly restricting what folks
can do.  If a best practice emerges later and it becomes clear that
allowing the client to set the atom:update value is an Absolute Good,
then I'll be all for coming with the a BCP documenting that fact.

- James

Henry Story wrote:
> Is this not splitting hairs a little? In the end it is always the server
> who is going to decide if it wants to accept anything at all. The server
> could also change the content if it wished (though I would not use such
> a service, having lived through the greed of the .com, we can be assured
> that servers will want to add their adds to your content). If we use the
> word responsibility this way then it's not going to help us distinguish
> anything interesting.
> 
> When it comes down to it, my feeling was that the client decides whether
> or not it wants to check that box "significant update" or not. The
> client does not have any say in what the value of app:edited is.
> 
> But special cases can be made. It's just that those would be understood
> to be deviations from the norm.
> 
>> - James
>>