Re: AD Evaluation of draft-ietf-atompub-protocol-11
On Sunday, December 17, 2006, at 11:02PM, Bob Wyman [EMAIL PROTECTED] wrote: It is important to remember that not all processors of Atom data will know what to do with unexpected metadata in the envelope. Thus, unexpected envelope fields will often simply be stripped off and thrown to the bit bucket. If you want data to stay with your content, it is best to put it in the content/... Sometimes, it may be appropriate to extend the envelope, however, one should not do so without a really compelling case. I think the distinction to make is whether the information in question is necessary for whatever process the entries participate in. Processes should be able to work with the entries without having to dig into the actual content. Jan Envelope extensions typically require fetching time or database structure modifications in consuming applications if those extensions are to be supported. This is because many feed consumers have distinct fields in their databases or internal structures for each of the envelope elements and then just have a single field for content. Also, the code for manipulating envelope fields is usually distinctly different from the code used to manipulate and process content/. So, if you create a new envelope field, you require a great deal of code to be modified for that field to be supported. On the other hand, if something can be slipped into content/ you'll see it being stored immediately and have the opportunity for downstream consumers (display routines, etc.) to provide support for the additional data. (For instance, you might write a GreaseMonkey script to do interesting things with stuff encoded in content/ even though the backend of the application knows nothing about it.) My personal feeling is that many of the proposals (but not all) for envelope extensions are derived from what I consider to be unfortunate precedent set in the RSS world where all sorts of random stuff has been pushed into the envelope since in RSS the description/ field is so under-specified that it isn't really possible to think of it as something which can be structured. Fortunately, the field has moved forward since legacy RSS was defined and we've got better methods that can be used with Atom. There are undoubtedly still things that might go in the envelope, but not as many as some folk might think. bob wyman
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 17/12/06 1:13 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: * Lisa Dusseault [EMAIL PROTECTED] [2006-12-16 02:15]: Since clients post Atom entries and other clients retrieve them, it seemed reasonable to want to extend Atom client-to-client. If I used AtomFu client that was able to annotate my entries automatically with what music I was listening to (track name, album and artist in XML elements) while I wrote a blog posting, I thought AtomFu should just store that as XML markup in the entry. That is, IMO, a misconception about Atom one that is frequently seen. We just had a similar discussion tonight in #atom on the Freenode IRC network. The track name, album and artist are data; they should be part of the payload of an entry, not part of its envelope. In practice, that means you use either microformats or a more structured format than HTML. Extending the Atom envelope is a strategy of last resort. wha? What music Lisa is listening to when she wrote a blog posting is meta data, not content, unless of course she's writing a blog posting *about* that particular bit of music. The music is contextual meta data, along the same vein as geo location of circumstance, the atom:generator involved, and even the atom:published date/time. Since when are we calling atom entries envelopes? e.
Re: AD Evaluation of draft-ietf-atompub-protocol-11
Quite frankly it doesn't matter what we call anything right now. The server gets to determine what pieces of data it's willing to handle. Period. If you want anything more than that, use webdav. - James Eric Scheid wrote: On 17/12/06 1:13 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: * Lisa Dusseault [EMAIL PROTECTED] [2006-12-16 02:15]: Since clients post Atom entries and other clients retrieve them, it seemed reasonable to want to extend Atom client-to-client. If I used AtomFu client that was able to annotate my entries automatically with what music I was listening to (track name, album and artist in XML elements) while I wrote a blog posting, I thought AtomFu should just store that as XML markup in the entry. That is, IMO, a misconception about Atom one that is frequently seen. We just had a similar discussion tonight in #atom on the Freenode IRC network. The track name, album and artist are data; they should be part of the payload of an entry, not part of its envelope. In practice, that means you use either microformats or a more structured format than HTML. Extending the Atom envelope is a strategy of last resort. wha? What music Lisa is listening to when she wrote a blog posting is meta data, not content, unless of course she's writing a blog posting *about* that particular bit of music. The music is contextual meta data, along the same vein as geo location of circumstance, the atom:generator involved, and even the atom:published date/time. Since when are we calling atom entries envelopes? e.
Re: AD Evaluation of draft-ietf-atompub-protocol-11
James M Snell schrieb: Quite frankly it doesn't matter what we call anything right now. The server gets to determine what pieces of data it's willing to handle. Period. If you want anything more than that, use webdav. ... Again: WebDAV doesn't redefine PUT, so the situation is exactly the same. (Unless you were referring to PROPFIND/PROPPATCH). Best regards, Julian
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On Dec 17, 2006, at 10:13 AM, James M Snell wrote: Quite frankly it doesn't matter what we call anything right now. The server gets to determine what pieces of data it's willing to handle. Period. If you want anything more than that, use webdav. (Sorry if this has already been said or not on the point, but I cannot read through the thread right now). - The server is free to 'mess' with the PUTed data at will before doing the update; so it can strip out whatever it wants. - Clients should do a GET before doing a PUT so they get some chance to see what the sever actually handles Jan - James Eric Scheid wrote: On 17/12/06 1:13 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: * Lisa Dusseault [EMAIL PROTECTED] [2006-12-16 02:15]: Since clients post Atom entries and other clients retrieve them, it seemed reasonable to want to extend Atom client-to-client. If I used AtomFu client that was able to annotate my entries automatically with what music I was listening to (track name, album and artist in XML elements) while I wrote a blog posting, I thought AtomFu should just store that as XML markup in the entry. That is, IMO, a misconception about Atom one that is frequently seen. We just had a similar discussion tonight in #atom on the Freenode IRC network. The track name, album and artist are data; they should be part of the payload of an entry, not part of its envelope. In practice, that means you use either microformats or a more structured format than HTML. Extending the Atom envelope is a strategy of last resort. wha? What music Lisa is listening to when she wrote a blog posting is meta data, not content, unless of course she's writing a blog posting *about* that particular bit of music. The music is contextual meta data, along the same vein as geo location of circumstance, the atom:generator involved, and even the atom:published date/time. Since when are we calling atom entries envelopes? e.
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 12/16/06, A. Pagaltzis [EMAIL PROTECTED] wrote: Extending the Atom envelope is a strategy of last resort. +1 It is important to remember that not all processors of Atom data will know what to do with unexpected metadata in the envelope. Thus, unexpected envelope fields will often simply be stripped off and thrown to the bit bucket. If you want data to stay with your content, it is best to put it in the content/... Sometimes, it may be appropriate to extend the envelope, however, one should not do so without a really compelling case. Envelope extensions typically require fetching time or database structure modifications in consuming applications if those extensions are to be supported. This is because many feed consumers have distinct fields in their databases or internal structures for each of the envelope elements and then just have a single field for content. Also, the code for manipulating envelope fields is usually distinctly different from the code used to manipulate and process content/. So, if you create a new envelope field, you require a great deal of code to be modified for that field to be supported. On the other hand, if something can be slipped into content/ you'll see it being stored immediately and have the opportunity for downstream consumers (display routines, etc.) to provide support for the additional data. (For instance, you might write a GreaseMonkey script to do interesting things with stuff encoded in content/ even though the backend of the application knows nothing about it.) My personal feeling is that many of the proposals (but not all) for envelope extensions are derived from what I consider to be unfortunate precedent set in the RSS world where all sorts of random stuff has been pushed into the envelope since in RSS the description/ field is so under-specified that it isn't really possible to think of it as something which can be structured. Fortunately, the field has moved forward since legacy RSS was defined and we've got better methods that can be used with Atom. There are undoubtedly still things that might go in the envelope, but not as many as some folk might think. bob wyman
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On Dec 15, 2006, at 5:00 PM, Lisa Dusseault wrote: I guess I'm assuming that one would want clients to be able to extend Atom unilaterally. That doesn't seem to have been a design goal for the WG. To the extent that the issue never came up in the discussion. The choices that I highlighted as problematic make it harder for clients to reliably add extensions to Atom documents. You're being tactful with harder. I'd say impossible. Here's my take on the WG thinking: The set of software implementations which could reasonably act as APP servers is incredibly large and heterogeneous. A lot of them already exist. The requirement that they reliably round-trip arbitrary XML from clients is actually pretty onerous, since many (all?) of them will have internal data-storage models which will look very little like the Atom XML representation. We think that APP as specified allows very good interoperability for basic Web-centric publish/edit operations with low overhead, and low demands for complexity in the client and sever implementations. Adding the requirement for client-side extensibility would reduce the number of server implementations that would be able to advertise conformance with APP, even though they are perfectly capable of the highly-useful function possible under APP as of the current draft. (It remains easy for servers to add extensions to Atom feeds and entries using prescribed mechanisms like adding new elements in custom namespaces. ) Right. Phrased another way, the APP is highly extensible; but the current version requires co-operation from both client and server. This seems reasonable to me. It may be that I'm just having trouble accepting that the WG fully understands this and has still come to consensus that this is a great way to proceed. Is that the case? Sort of. Frankly, there seems to have been very little hunger for unilateral client-side extension, and a very strong aversion from the server-side people to accepting the round-trip-any-XML requirement. -Tim
Re: AD Evaluation of draft-ietf-atompub-protocol-11
Tim Bray wrote: [snip] We think that APP as specified allows very good interoperability for basic Web-centric publish/edit operations with low overhead, and low demands for complexity in the client and sever implementations. Adding the requirement for client-side extensibility would reduce the number of server implementations that would be able to advertise conformance with APP, even though they are perfectly capable of the highly-useful function possible under APP as of the current draft. +1 (It remains easy for servers to add extensions to Atom feeds and entries using prescribed mechanisms like adding new elements in custom namespaces. ) Right. Phrased another way, the APP is highly extensible; but the current version requires co-operation from both client and server. This seems reasonable to me. +1 It may be that I'm just having trouble accepting that the WG fully understands this and has still come to consensus that this is a great way to proceed. Is that the case? Sort of. Frankly, there seems to have been very little hunger for unilateral client-side extension, and a very strong aversion from the server-side people to accepting the round-trip-any-XML requirement. From this implementors point of view client-side extension simply is not a requirement. - James
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 12/15/06, Lisa Dusseault [EMAIL PROTECTED] wrote: I guess I'm assuming that one would want clients to be able to extend Atom unilaterally. The choices that I highlighted as problematic make it harder for clients to reliably add extensions to Atom documents. (It remains easy for servers to add extensions to Atom feeds and entries using prescribed mechanisms like adding new elements in custom namespaces. ) Since clients post Atom entries and other clients retrieve them, it seemed reasonable to want to extend Atom client-to-client. If I used AtomFu client that was able to annotate my entries automatically with what music I was listening to (track name, album and artist in XML elements) while I wrote a blog posting, I thought AtomFu should just store that as XML markup in the entry. Other users running AtomFu will see that information and nobody else needs to upgrade -- not servers, not other clients. Eventually if other clients see this as a useful feature they'll make the additional markup visible. Servers probably would never need to upgrade to use or touch that markup. A model where servers aren't required to keep such information won't, in practice, allow that kind of extension. If clients can't rely on their markup getting stored, then clients can't extend Atom unilaterally using XML markup. I do not see the ability of clients to unilaterally extend the APP using XML as a requirement. But implementors of client software are innovative, too. You can't stop them from putting cool information in entries -- they'll just put it in a place where the server decides it's just natural-language or some other component that it does allow the client to create unmodified. So maybe instead of seeing track name, album and artist in XML elements, we'll see them in square brackets or some other format in the blog entry text. You say that as if it's a bad thing. Personally I like microformats. And besides, just because *your* client stuffs a track name, album and artist into some XML does not automatically make it interoperable; every client can, and will, choose to encode that data differently. This will hurt interoperability to a certain extent, as there is no standard way of extending the machine-parsable information within the *text* of an entry. See microformats. It may be that I'm just having trouble accepting that the WG fully understands this and has still come to consensus that this is a great way to proceed. Like I stated previously, this has been discussed ad infinitum on the list and the consensus supports it. -joe -- Joe Gregoriohttp://bitworking.org
Re: AD Evaluation of draft-ietf-atompub-protocol-11
I'm not subscribed to the APP mailing list, so hopefully this isn't all redundant: On 12/15/06, Lisa Dusseault [EMAIL PROTECTED] wrote: A model where servers aren't required to keep such information won't, in practice, allow that kind of extension. If clients can't rely on their markup getting stored, then clients can't extend Atom unilaterally using XML markup. There are two different issues here, which I think has been mentioned, but which might bear being clearly stated: 1) Do servers have to keep all extension data? 2) Can a server accept an entry while discarding some or all extension data, or do they have to reject the entry and return an error code? I think the answer to the first question is clearly no--servers shouldn't be required to store all arbitrary data that is sent to them. So the questions are: 1) Which hurts more--data loss or rejected entries? 2) Is there any way to reduce that pain? The pain of data loss is obvious--the data is lost. The pain of rejected entries is having to fix and repost them or decide not to try again. In either case, it might be useful to be able to query the server somehow to find out what it will and won't preserve. If data is discarded, you can figure that out after the fact by loading the resulting entry and checking whether the data is all there, but one might prefer to know ahead of time if something is going to be lost in order to be able to decide whether to post it or not. If the entry is just going to be rejected, unless there's a way for the server to communicate exactly which data it had issues with, fixing the data to make it acceptable could be extremely difficult (Hmm, I'll leave this data out and try again...nope, still rejected. I'll put that back in and leave this out...nope. I'll take both out...nope. I'll put both back in and take yet another piece of data out...). So, how might a client query a server to see what it will preserve? A few possibilities: 1) Have some way to request some sort of description of what will and won't be preserved and what might be altered. I don't know how one would go about responding to such an inquiry except to basically send back a list of what will be preserved, including some way to say I'll preserve unknown attributes here, I'll preserve unknown child elements (and their children) here, I'll store up to 32767 bytes here, etc. If there is any known extension markup that a server wants to explicitly state that it won't preserve, there may need to be a way to do that too. 2) Have a way to do a test post, where one posts the data one is considering posting (or something structurally identical), but says don't store this--just tell me what you WOULD store. The response could include what would be returned if one were to load the data after it being stored, or it could be some sort of list of anything that would be discarded or altered. 3) (I get the impression this could be done without requiring changes--is this the sort of process that has already been selected?) Post the data as a draft, reload it to see if it's all still there. If so, or if what has been preserved is acceptable, change it's status to published or whatever it's called. If not delete it and give up or take whatever other action is appropriate. My impression is that data loss would be less painful and more easily dealt with than rejection of entries that won't be completely preserved. ...but I haven't followed the discussion, so what do I know.
Re: AD Evaluation of draft-ietf-atompub-protocol-11
The moral of the story is simple: clients need to know what they're getting into. 1. Servers can accept or reject whatever they want. 2. it's really nice if servers let client's know up front what they intend to accept or reject 3. at this point there's no need for any kind of handshake protocol to determine what a server will accept or reject. What's most likely to happen (and most likely to actually be used and work effectively) is that server's will put up websites [1] that document exactly how their endpoints work and what clients should expect. - James [1] http://code.google.com/apis/gdata/ Antone Roundy wrote: I'm not subscribed to the APP mailing list, so hopefully this isn't all redundant: On 12/15/06, Lisa Dusseault [EMAIL PROTECTED] wrote: A model where servers aren't required to keep such information won't, in practice, allow that kind of extension. If clients can't rely on their markup getting stored, then clients can't extend Atom unilaterally using XML markup. There are two different issues here, which I think has been mentioned, but which might bear being clearly stated: 1) Do servers have to keep all extension data? 2) Can a server accept an entry while discarding some or all extension data, or do they have to reject the entry and return an error code? I think the answer to the first question is clearly no--servers shouldn't be required to store all arbitrary data that is sent to them. So the questions are: 1) Which hurts more--data loss or rejected entries? 2) Is there any way to reduce that pain? The pain of data loss is obvious--the data is lost. The pain of rejected entries is having to fix and repost them or decide not to try again. In either case, it might be useful to be able to query the server somehow to find out what it will and won't preserve. If data is discarded, you can figure that out after the fact by loading the resulting entry and checking whether the data is all there, but one might prefer to know ahead of time if something is going to be lost in order to be able to decide whether to post it or not. If the entry is just going to be rejected, unless there's a way for the server to communicate exactly which data it had issues with, fixing the data to make it acceptable could be extremely difficult (Hmm, I'll leave this data out and try again...nope, still rejected. I'll put that back in and leave this out...nope. I'll take both out...nope. I'll put both back in and take yet another piece of data out...). So, how might a client query a server to see what it will preserve? A few possibilities: 1) Have some way to request some sort of description of what will and won't be preserved and what might be altered. I don't know how one would go about responding to such an inquiry except to basically send back a list of what will be preserved, including some way to say I'll preserve unknown attributes here, I'll preserve unknown child elements (and their children) here, I'll store up to 32767 bytes here, etc. If there is any known extension markup that a server wants to explicitly state that it won't preserve, there may need to be a way to do that too. 2) Have a way to do a test post, where one posts the data one is considering posting (or something structurally identical), but says don't store this--just tell me what you WOULD store. The response could include what would be returned if one were to load the data after it being stored, or it could be some sort of list of anything that would be discarded or altered. 3) (I get the impression this could be done without requiring changes--is this the sort of process that has already been selected?) Post the data as a draft, reload it to see if it's all still there. If so, or if what has been preserved is acceptable, change it's status to published or whatever it's called. If not delete it and give up or take whatever other action is appropriate. My impression is that data loss would be less painful and more easily dealt with than rejection of entries that won't be completely preserved. ...but I haven't followed the discussion, so what do I know.
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 17/12/06 2:20 AM, Tim Bray [EMAIL PROTECTED] wrote: I guess I'm assuming that one would want clients to be able to extend Atom unilaterally. That doesn't seem to have been a design goal for the WG. To the extent that the issue never came up in the discussion. Not sure exactly, but I did raise the possibility of a client passing in XML whose only purpose is for the benefit of other clients. Things like editorial comments and such. These would have been shepherded in the app:control element, and there was a great deal of discussion about the contents of app:control not being published (whatever that meant). It got hairy, and there wasn't much support for the idea. e.
Re: AD Evaluation of draft-ietf-atompub-protocol-11
* Lisa Dusseault [EMAIL PROTECTED] [2006-12-16 02:15]: Since clients post Atom entries and other clients retrieve them, it seemed reasonable to want to extend Atom client-to-client. If I used AtomFu client that was able to annotate my entries automatically with what music I was listening to (track name, album and artist in XML elements) while I wrote a blog posting, I thought AtomFu should just store that as XML markup in the entry. That is, IMO, a misconception about Atom – one that is frequently seen. We just had a similar discussion tonight in #atom on the Freenode IRC network. The track name, album and artist are data; they should be part of the payload of an entry, not part of its envelope. In practice, that means you use either microformats or a more structured format than HTML. Extending the Atom envelope is a strategy of last resort. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: AD Evaluation of draft-ietf-atompub-protocol-11
Joe Gregorio schrieb: ... This is the documented consensus of the WG. The next draft will have verbage that makes this position clearer. If some implementations find that too loose and want octet-for-octet storage they can use always WebDAV. [1] http://www.imc.org/atom-protocol/mail-archive/msg05415.html WebDAV doesn't make any promises about what servers do upon PUT. It just relies on RFC2616. Best regards, Julian
Re: AD Evaluation of draft-ietf-atompub-protocol-11
Joe Gregorio wrote: On 12/14/06, Sam Ruby [EMAIL PROTECTED] wrote: I believe I first saw this in a response made by Roy Fielding to an assertion that servers must treat HTTP PUT as a bit-for-bit copy, but I can't immediately find the reference. http://www.imc.org/atom-protocol/mail-archive/msg05425.html That's the one! - Sam Ruby
Re: AD Evaluation of draft-ietf-atompub-protocol-11
Lisa Dusseault wrote: Can a client modify an entry to contain a link relation element in the following cases: - To point to a resource on a different server entirely? There is no reason to believe that any of these resource are on the same machine to begin with. I could POST to media to machine A and have the MLE could be created on machine B and the editable media resource itself created on machine C. This requirement has to be stated explicitly, at least as a SHOULD. Hmm. One particular operation in the APP is defined as creating two resources; we specify how this is requested and the mechanism by which the server communicates the URIs that identify the newly-created resources. It would feel really weird to me to specify anything about what servers the resources might be on. That's not how URIs work or how the Web works. You can't tell by looking at a URI what server the resource is on, anyhow. The URI might not be an HTTP URI. Two URIs that look very much the same might reference data on different continents. That's the whole point of how URIs work. Having said that, Lisa has already pointed out shortcomings in the number and placement of examples concerning this particular case. I think it'd be a good idea to have the example showing the Media resource showing up at http://media.example.com and the MLE showing up at http://app.example.com. But I'd be very much against side-tripping the protocol definition into any discussion of servers. Can a server ever ignore part of an edit and successfully process the rest? Yes. Think of a client that throws in a slew of random link elements with relations my server implementation doesn't understand. Same with foreign markup. The server is in charge. I completely disagree with this. It is way too unpredictable for clients to deal with. Well, except there are several examples of APP clients that seem to do just fine. Example: After extensive discussion, the WG achieved consensus that APP servers are *not* required to retain foreign markup. Example: It is perfectly possible to imagine a server that morphs or prunes incoming entries for reasons of political censorship, security policies, markup standards, spelling-correction, automatic translation, or lots of other things we can't possibly imagine. Example: my Ape protocol exerciser posts entries with a separate content and summary fields. At least one of the servers I've tested against accepts posts but discards my summary and generates its own, algorithmically. The range of things a server can usefully choose to do currently exceeds our ability to specify or constrain. Fortunately, in HTTP, we have a protocol the semantics of whose state-changing verbs PUT and POST are remarkably well-matched for these interactions whereby a client says please take this and publish it and tell me what you did and the server says OK, here's what I made of it. The current WG consensus, way better than rough, is that this level of interoperation is useful. That consensus seems to be supported by implementation experience. Lisa, perhaps the problem is that I'm reacting to a fairly general statement of concern. Do you have some specific suggestions as to how server behavior could be limited or formally described? -Tim
Re: AD Evaluation of draft-ietf-atompub-protocol-11
I guess I'm assuming that one would want clients to be able to extend Atom unilaterally. The choices that I highlighted as problematic make it harder for clients to reliably add extensions to Atom documents. (It remains easy for servers to add extensions to Atom feeds and entries using prescribed mechanisms like adding new elements in custom namespaces. ) Since clients post Atom entries and other clients retrieve them, it seemed reasonable to want to extend Atom client-to-client. If I used AtomFu client that was able to annotate my entries automatically with what music I was listening to (track name, album and artist in XML elements) while I wrote a blog posting, I thought AtomFu should just store that as XML markup in the entry. Other users running AtomFu will see that information and nobody else needs to upgrade -- not servers, not other clients. Eventually if other clients see this as a useful feature they'll make the additional markup visible. Servers probably would never need to upgrade to use or touch that markup. A model where servers aren't required to keep such information won't, in practice, allow that kind of extension. If clients can't rely on their markup getting stored, then clients can't extend Atom unilaterally using XML markup. But implementors of client software are innovative, too. You can't stop them from putting cool information in entries -- they'll just put it in a place where the server decides it's just natural-language or some other component that it does allow the client to create unmodified. So maybe instead of seeing track name, album and artist in XML elements, we'll see them in square brackets or some other format in the blog entry text. This will hurt interoperability to a certain extent, as there is no standard way of extending the machine-parsable information within the *text* of an entry. We won't see this today -- with new protocols, servers typically lead adoption, implementing the protocol before many clients emerge. But in the long run, server deployments get old and yet as long as they're still running, admins avoid changing software or even upgrading. Yet people who've gotten used to the new functionality start expecting more from it and seek out clients that do cool new things and still interoperate with their servers. Bare bones clients are the first generation of a new technology, and innovative (whatever the barriers) clients come much later. It may be that I'm just having trouble accepting that the WG fully understands this and has still come to consensus that this is a great way to proceed. Is that the case? thx, Lisa On Dec 15, 2006, at 8:13 AM, Tim Bray wrote: The current WG consensus, way better than rough, is that this level of interoperation is useful. That consensus seems to be supported by implementation experience. Lisa, perhaps the problem is that I'm reacting to a fairly general statement of concern. Do you have some specific suggestions as to how server behavior could be limited or formally described?
Re: AD Evaluation of draft-ietf-atompub-protocol-11
Thanks for responding to my review. I look forward to seeing a revised draft. Below I've excerpted the stuff that is still giving me serious problems. On Dec 7, 2006, at 8:36 AM, Joe Gregorio wrote: Can a client modify an entry to contain a link relation element in the following cases: - To point to a resource on a different server entirely? There is no reason to believe that any of these resource are on the same machine to begin with. I could POST to media to machine A and have the MLE could be created on machine B and the editable media resource itself created on machine C. This requirement has to be stated explicitly, at least as a SHOULD. This is the kind of thing that clients come to completely rely on, and then you find some special-purpose server that decides this doesn't fit in its model. Well, the spec doesn't require me to accept link relations which point to other servers. Finger- pointing rather than interoperability. If that's completely unacceptable, the only alternative that would allow good interoperability is to have an error code or feature advertisement that allows the client to detect that the server won't allow this. A generic Forbidden error (or other choice that could be made by the server) is not enough to know what is disallowed and whether it is always disallowed. What did I do wrong? the client plaintively asks. Can a server ever ignore part of an edit and successfully process the rest? Yes. Think of a client that throws in a slew of random link elements with relations my server implementation doesn't understand. Same with foreign markup. The server is in charge. I completely disagree with this. It is way too unpredictable for clients to deal with. Clients are left with the illusion of flexibility -- it *seems* you can use Atom syntax extensions and do creative things that other extended clients can understand -- but in fact the server can alter this at will leaving the client without any control over what it's really publishing. In many cases, the client won't even want the server to store some stripped version of what it POSTed, because it can really change the meaning of some entry to have the server strip some of the content and markup. Imagine removing the start time and location when I'm trying to publish an event entry to what I believe ought to be a calendar feed. Some server changes to submitted documents is of course going to be allowable (edit dates, server-provided IDs, changes which are effectively XML canonicalization) but I believe these need to be limited. The general case, which is how servers deal with unrecognized elements, needs to be severely limited so that the server can either reject the whole request or store as provided. Lisa
Re: AD Evaluation of draft-ietf-atompub-protocol-11
Can a client modify an entry to contain a link relation element in the following cases: - To point to a resource on a different server entirely? There is no reason to believe that any of these resource are on the same machine to begin with. I could POST to media to machine A and have the MLE could be created on machine B and the editable media resource itself created on machine C. This requirement has to be stated explicitly, at least as a SHOULD. This is the kind of thing that clients come to completely rely on, and then you find some special-purpose server that decides this doesn't fit in its model. Well, the spec doesn't require me to accept link relations which point to other servers. Finger-pointing rather than interoperability. I didn't quite understand your statement here. You make things more complicated than what Joe actually said. If that's completely unacceptable, the only alternative that would allow good interoperability is to have an error code or feature advertisement that allows the client to detect that the server won't allow this. A generic Forbidden error (or other choice that could be made by the server) is not enough to know what is disallowed and whether it is always disallowed. What did I do wrong? the client plaintively asks. A generic error code would mean there was an error in the first place. Why is this the case? Can a server ever ignore part of an edit and successfully process the rest? Yes. Think of a client that throws in a slew of random link elements with relations my server implementation doesn't understand. Same with foreign markup. The server is in charge. I completely disagree with this. It is way too unpredictable for clients to deal with. Clients are left with the illusion of flexibility -- it *seems* you can use Atom syntax extensions and do creative things that other extended clients can understand -- but in fact the server can alter this at will leaving the client without any control over what it's really publishing. In many cases, the client won't even want the server to store some stripped version of what it POSTed, because it can really change the meaning of some entry to have the server strip some of the content and markup. Imagine removing the start time and location when I'm trying to publish an event entry to what I believe ought to be a calendar feed. Some server changes to submitted documents is of course going to be allowable (edit dates, server-provided IDs, changes which are effectively XML canonicalization) but I believe these need to be limited. The general case, which is how servers deal with unrecognized elements, needs to be severely limited so that the server can either reject the whole request or store as provided. This is a fundamental change to what has been said over and over on this mailing-list. Allowing the client to have more power than the current draft allows on the Atom member would mean we have to detail all those cases within the draft itself and would strongly limit its simplicity IMO. Besides, if you want to do fancy thing with a member, simply post a media resource which is an atom entry. This won't be modified by the server and will solely be treated a media resource. Then the client will have full control on it. The server must keep full control of the member resource. - Sylvain
Re: AD Evaluation of draft-ietf-atompub-protocol-11
Lisa Dusseault wrote: Can a server ever ignore part of an edit and successfully process the rest? Yes. Think of a client that throws in a slew of random link elements with relations my server implementation doesn't understand. Same with foreign markup. The server is in charge. I completely disagree with this. It is way too unpredictable for clients to deal with. Clients are left with the illusion of flexibility -- it *seems* you can use Atom syntax extensions and do creative things that other extended clients can understand -- but in fact the server can alter this at will leaving the client without any control over what it's really publishing. In many cases, the client won't even want the server to store some stripped version of what it POSTed, because it can really change the meaning of some entry to have the server strip some of the content and markup. Imagine removing the start time and location when I'm trying to publish an event entry to what I believe ought to be a calendar feed. Some server changes to submitted documents is of course going to be allowable (edit dates, server-provided IDs, changes which are effectively XML canonicalization) but I believe these need to be limited. The general case, which is how servers deal with unrecognized elements, needs to be severely limited so that the server can either reject the whole request or store as provided. I believe I first saw this in a response made by Roy Fielding to an assertion that servers must treat HTTP PUT as a bit-for-bit copy, but I can't immediately find the reference. In any case: clients must always consider the possibility that the server processes other requests (even internally generated ones) between the time the one the client issued and the next request the server choses to process. Such requests could partially or completely change the representation of the resource. - Sam Ruby
Re: AD Evaluation of draft-ietf-atompub-protocol-11
I believe I first saw this in a response made by Roy Fielding to an assertion that servers must treat HTTP PUT as a bit-for-bit copy, but I can't immediately find the reference. Could it be? http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0228.html - Sylvain
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 15/12/06 7:29 AM, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: Besides, if you want to do fancy thing with a member, simply post a media resource which is an atom entry. This won't be modified by the server and will solely be treated a media resource. promise? does the spec support this assertion? or is this another case of the server is in charge and can accept or change whatever it wants? e.
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 12/14/06, Sam Ruby [EMAIL PROTECTED] wrote: I believe I first saw this in a response made by Roy Fielding to an assertion that servers must treat HTTP PUT as a bit-for-bit copy, but I can't immediately find the reference. http://www.imc.org/atom-protocol/mail-archive/msg05425.html In any case: clients must always consider the possibility that the server processes other requests (even internally generated ones) between the time the one the client issued and the next request the server choses to process. Such requests could partially or completely change the representation of the resource. - Sam Ruby -- Joe Gregoriohttp://bitworking.org
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 12/14/06, Lisa Dusseault [EMAIL PROTECTED] wrote: This requirement has to be stated explicitly, at least as a SHOULD. This is the kind of thing that clients come to completely rely on, and then you find some special-purpose server that decides this doesn't fit in its model. Well, the spec doesn't require me to accept link relations which point to other servers. Finger-pointing rather than interoperability. Older versions of the spec had this wording: http://bitworking.org/projects/atom/draft-gregorio-09.html#rfc.section.4.3 This RFC does not specify the form of the URIs that are used. The URI space of each server is controlled, as defined by HTTP, by the server alone. What this RFC does specify are the formats of the files that are exchanged and the actions that can be performed on the URIs embedded in those files. Something along those lines could be added back in. Can a server ever ignore part of an edit and successfully process the rest? Yes. Think of a client that throws in a slew of random link elements with relations my server implementation doesn't understand. Same with foreign markup. The server is in charge. I completely disagree with this. It is way too unpredictable for clients to deal with. Clients are left with the illusion of flexibility -- it *seems* you can use Atom syntax extensions and do creative things that other extended clients can understand -- but in fact the server can alter this at will leaving the client without any control over what it's really publishing. This happens *all the time* in the real world. Many blog comment systems have 'Preview' buttons. Why? Because you never know how the server is going to handle your text. Yes, it might be nice, in the future, to add a way for a server to advertise its capabilities, but we do not have the real world experience with the protocol to know what that should look like. In many cases, the client won't even want the server to store some stripped version of what it POSTed, because it can really change the meaning of some entry to have the server strip some of the content and markup. Imagine removing the start time and location when I'm trying to publish an event entry to what I believe ought to be a calendar feed. Some server changes to submitted documents is of course going to be allowable (edit dates, server-provided IDs, changes which are effectively XML canonicalization) but I believe these need to be limited. The general case, which is how servers deal with unrecognized elements, needs to be severely limited so that the server can either reject the whole request or store as provided. I'm sorry but we've already argued this to death on the list and there is nothing in HTTP which supports that view [1]. We've even reviewed the scenario you are talking about and came to the opposite conclusion: http://www.imc.org/atom-protocol/mail-archive/msg05415.html This is the documented consensus of the WG. The next draft will have verbage that makes this position clearer. If some implementations find that too loose and want octet-for-octet storage they can use always WebDAV. [1] http://www.imc.org/atom-protocol/mail-archive/msg05415.html Thanks, -joe -- Joe Gregoriohttp://bitworking.org
Re: AD Evaluation of draft-ietf-atompub-protocol-11
Eric Scheid wrote: On 15/12/06 7:29 AM, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: Besides, if you want to do fancy thing with a member, simply post a media resource which is an atom entry. This won't be modified by the server and will solely be treated a media resource. promise? does the spec support this assertion? or is this another case of the server is in charge and can accept or change whatever it wants? e. No you are right, this is a gratuitous assertion here. However APP currently describes what a server is allowed to do on a member resource and not on the media resource. It could be interesting to see how extensions to APP could allow the server and the UA to agree on what level of modification each party is entitled to expect. - Sylvain
Re: AD Evaluation of draft-ietf-atompub-protocol-11
Lisa, Thanks for the very detailed review of this draft. More comments in-line. On 10/17/06, Lisa Dusseault [EMAIL PROTECTED] wrote: 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) There may be 'other' media resources, but if they don't have an associated Media Link Entry then they are not 'in' the collection. 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. That used to be in the spec: http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-06.html#entry-constraints It should go back in. - 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. Agreed. 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). A POST can create any number of resources. In the case of an entry collection it will be at least one. In the case of a media entries it will be at least two. Many other resources could be created but this spec should only concern itself with the ones of interest for the operation of the protocol, otherwise the protocol isn't of much use. For example, if we say that POSTing an entry MUST only create one resource then how does the associated weblog HTML page get created? 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; Yes, it is undefined. So is the effect of sending it a PROPPATCH, COPY, LOCK, PATCH or MEGAFOO. Agreed, a note to the effect that anything not defined in the spec is, well, un-defined. I.e. we aren't holding any other methods on the resources 'in reserve'. 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
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On Oct 18, 2006, at 1:04 AM, Sylvain Hellegouarch wrote: 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. 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. I was assuming the opposite of what James assumed, so under my personal world-view "create a media resource manually" meant to create a media resource without also creating the media link entry at the same time.To illustrate my disconnect more, I'll borrow James Snell's concrete example and show what I thought would obtain instead:On 2006/10/17, at 4:40 PM, James M Snell wrote:My assumption: The relationship between a media link entry and a mediaresource is always 1-to-1. If I want an entry to point to multiplemedia resources, then I would create one media link entry for each mediaresource, then create a separate entry that points to each of theindividually created media resources.e.g., entry1 -- pic1 entry2 -- pic2 entry3 -- pic3 entry4 -- pic1 -- pic2 -- pic3Entries 1, 2 and 3 will always point to their respective media resources(using atom:content/@src).My idea was that if I want to create an entry to point to multiple media resources, I might first create the entry as I edit text about my fabulous trip to Lisbon, entries: entry1Then when I add pictures to the entry I'm editing, my client would "manually" create the media resources by posting to the media collection, such that no media link entry was created for each of them. At the same time, the client would probably PUT to the entry each time to update and add the link to the pictures. entries: entry1 -- pic1 -- pic2 -- pic3 media resources: pic1 pic2 pic3Of course this can be done in fewer steps if the client is implemented to do editing offline and only upload the whole kaboodle when I'm done. In that scenario, entry2 with images pic4 and pic5 would be created with a minimum of POSTs and no PUTs, step 1 is POSTing the images: entries: entry1 -- pic1, pic2, pic3 media resources: pic1, pic2, pic3 NEW pic4 NEW pic5Step 2 is POSTing the entry with the links obtained from creating the images: entries: entry1 -- pic1, pic2, pic3 NEW entry2 -- pic4, pic5 media resources: pic1, pic2, pic3 pic4 pic5I may be wrong about this model and James is likely to be right as having followed the discussion more carefully, but I don't believe the draft clearly leads the reader to James' model. Lisa
Re: AD Evaluation of draft-ietf-atompub-protocol-11
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. 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. - 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. 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 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. I believe that any assumption that the subscription and collections feeds will always be different is incorrect and dangerous. *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). 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. 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.) I would say a server not sending a 405 or any other 40x is broken in that case. 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). 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). +1 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
Re: AD Evaluation of draft-ietf-atompub-protocol-11
James M Snell wrote: Lisa Dusseault wrote: 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). 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. 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
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 18 Oct 2006, at 01:40, James M Snell wrote: [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. 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
Re: AD Evaluation of draft-ietf-atompub-protocol-11
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: *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. 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. 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. [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 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. +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. 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. My assumption: There is no relationship. atom:updated should be treated as being entirely independent of Last-Modified. yes. It might be reasonable, however, to define a relationship between Last-Modified and app:edited. 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) - Is it clear whether the client MUST GET the entry after modifying it in order to have an accurate offline cache? (this was
Re: AD Evaluation of draft-ietf-atompub-protocol-11
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? 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
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 18 Oct 2006, at 16:10, John Panzer wrote: 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. 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. 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
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On 18 Oct 2006, at 16:34, James M Snell wrote: 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. 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] 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.
Re: AD Evaluation of draft-ietf-atompub-protocol-11
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: On 18 Oct 2006, at 16:34, James M Snell wrote: 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. 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] 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.
Re: AD Evaluation of draft-ietf-atompub-protocol-11
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. - 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. 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. - 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. 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* 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). 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
Re: AD Evaluation of draft-ietf-atompub-protocol-11
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, On 2006/10/17, at 4:40 PM, James M Snell wrote: 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. -- Mark Nottingham http://www.mnot.net/
Re: AD Evaluation of draft-ietf-atompub-protocol-11
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 ... idtag: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:titleMy 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 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, On 2006/10/17, at 4:40 PM, James M Snell wrote: 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. -- Mark Nottingham http://www.mnot.net/
