Re: Question about section 9.3 of APP

[James M Snell <jasnell@xxxxxxxxx>]

Yaron Goland wrote:
> Section 9.3 of APP that states:
>    To avoid unintentional loss of data when editing Member Entries or
>    Media Link Entries, Atom Protocol clients SHOULD preserve all
>    metadata that has not been intentionally modified, including unknown
>    foreign markup as defined in Section 6 of [RFC4287].
> 
> My understanding of this text is that if a client encounters content it does 
> not understand in a GET then when the client updates the entry with a PUT the 
> client is expected to include in the PUT's content information that the client 
> did not understand.

This section is largely meant to deal with the fact that RFC4287 tells
implementations that it's perfectly fine to ignore unknown foreign
markup.  For some implementations, ignore means that the content is
silently dropped on the floor without the user ever actually knowing
about it.  If an APP client did that, then a user could end up editing
data they never knew existed with completely unintentional side effects.
 For instance, an entry that was once marked as a draft might
accidentally be changed to published.  Since the server has no way of
knowing specifically what the client intended to change, it must assume
that all differences between the current resource and what is being PUT
represent the changes that the client is wanting to make.

In other words, this is a recognition that the PUT operation really
isn't safe and that APP clients need to be written defensively against
unintentional modifications.

> [snip]
> A. APP must specify that PUT, with ATOM content types, is actually safe. 
> I have trouble believing that APP intends this as clearly PUT changes the 
> state of the identified entry and this is inherently unsafe.
> 
> B. APP requires that any and all foreign elements in an entry are required 
> by APP to have no side effects and to not change the state of the server so 
> that they are in effect, safe. In other words all foreign elements would have 
> to be essentially read only and when re-uploaded they would have to be ignored. 
> If this were not the case then when a client uploads a foreign element they would 
> be taking responsibility for the content and semantics of that foreign element even 
> though they don't understand the foreign element.

The answer is C. Foreign elements may very well have side effects.  All
we're saying in the spec is that a client should not touch what it does
not understand.  It's up to the server to protect itself beyond that.

> 
> An example may help in the case of point B. Imagine that there is a foreign 
> element <KillAllThePrisoners xmlns="http://foo.bar.com";>True</KillAllThePrisoners> 
> that comes down in an entry. Now imagine that the APP server is logging all requests. 
> If the client should re-upload the content, including the unrecognized KillAllThePrisoners 
> foreign element, then in effect the server has a record of the client explicitly agreeing 
> that KillAllThePrisoners is the client's desire. Obviously such an interpretation is 
> impossible in a 9.3 world but that also means that we can never, ever, hold any client 
> responsible for re-uploaded content because they can claim that they were just blindly 
> re-uploading content.

Flip the example.  Suppose the entry has <KillAllThePrisoners
xmlns="http://foo.bar.com";>false</KillAllThePrisoners> and that the
server is implemented such that it will kill the prisoners by default if
the KillAllThePrisoners element is not present.  The dumb client,
completely unaware of the extension, drops it silently on the floor and
PUTs it back to the server.  Suddenly all the prisoners end up dead.

Too far fetched?  Consider the case of app:draft instead.  By default,
all entries in Atompub are considered to be "published" unless app:draft
is "yes".  If app:draft is "yes", the server should not make it publicly
available.  If a dumb client does not understand drafts, it could
accidentally change the status of the entry to published.

> 
> This really goes to the core of 9.1.1 of RFC 2616, is PUT safe or not? If 
> it's unsafe then clients are responsible for everything they upload but 9.3 
> of APP seems to be essentially freeing clients from that responsibility. I 
> therefore can't square 9.3 of APP and 9.1.1 of RFC 2616.

Clients are responsible for their changes; 9.3 simply says that clients
need to be careful so as to not make any unintentional changes by silent
dropping data on the floor.  That squares perfectly well with my
understanding of RFC 2616 9.1.1.

- James