Subject: Editorial comments on draft-atompub-protocol-00

From: Tim Bray <[email-masked]>
Date: Tue, 13 Jul 2004 15:26:51 -0700

[page 3/sect 1.1] busted sentence: 'the and "OPTIONAL"'

[page 5/sect 3.1.3.3] the description of code 400 is borked, see the 
sentence "A short description of the error..."

Same for 3.1.3.4.

[page 5/sect 3.2] the description reads like it's forbidden to do a PUT 
without doing a GET first.  Is this true?  If I know the URI and I know 
what I want to put there, can't I just blast it in?

[page 6/sect.3.2] there's nothing about return codes.  Perhaps you need 
a @to-do note?

[page 6/sect 3.3] Could the FeedURI and PostURI be the same URI?  I 
assume so, but it might be better to be explicit.

---

From: Ken MacLeod <[email-masked]>
Date: 13 Jul 2004 18:18:29 -0500

Tim Bray <[email-masked]> writes:

> [page 5/sect 3.2] the description reads like it's forbidden to do a
> PUT without doing a GET first.  Is this true?  If I know the URI and
> I know what I want to put there, can't I just blast it in?

+1 to that!

The publishing system would need to be capable of doing that, of
course, and there's nothing currently specced to indicate that
possibility to a client or provide a set of base-URIs.

PacePutToCreate was created to propose a way to communicate that
information, if the server supported that option.

  -- Ken

---

From: Joe Gregorio <[email-masked]>
Date: Tue, 13 Jul 2004 22:16:00 -0400

> [page 3/sect 1.1] busted sentence: 'the and "OPTIONAL"'

Done.

> sentence "A short description of the error..."

Done.

> Same for 3.1.3.4.

Done.

> what I want to put there, can't I just blast it in?

Good question. I will respond to this in a separate message.

> [page 6/sect.3.2] there's nothing about return codes.  Perhaps you need

Done. Return codes added.

> assume so, but it might be better to be explicit.

Done.

---

From: Joe Gregorio <[email-masked]>
Date: Tue, 13 Jul 2004 22:26:14 -0400

> what I want to put there, can't I just blast it in?

You could, but you might not want to. 

Consider the case of a Wiki. Most Wiki HTML editing forms have 
a nonce, either a hidden time or a hash value. This nonce is used
to protect against edits being lost in a race condition, i.e. user
A starts to edit a page, takes too long and later user B edits the
same page and commits before user A does.

If the client does a GET on the EditURI then the server has a chance
to place a nonce in the entry. The client should preserve
that nonce and submit it with the entry when the edit entry
is PUT back to the EditURI. 

For this scenario to work you need two things. The first 
is that the client does a GET before editing. The second
is that the client preserves all the information elements 
of the entry for submitting back on the PUT,
even for namespaces and elements that the client doesn't know about,
which is something I believe all clients should do.

    -joe

---

From: Tim Bray <[email-masked]>
Date: Tue, 13 Jul 2004 19:50:19 -0700

On Jul 13, 2004, at 7:26 PM, Joe Gregorio wrote:

>> PUT
> Consider the case of a Wiki.

... reasonable use-case elided.

The use-case granted, here's another: I'm a CMS blasting out deltas to 
a feed, where I know something's been updated and I own the data and 
the feed and I just want to damn well update it and not waste cycles 
doing a GET.

So all I'm saying is that the language which explains how you'd 
reasonably use PUT and GET, should also make it clear that PUT does 
what PUT does, and there's no compulsory preceding GET.  -Tim

---

From: Joe Gregorio <[email-masked]>
Date: Tue, 13 Jul 2004 23:05:14 -0400

> what PUT does, and there's no compulsory preceding GET.  -Tim

How about stating that the client SHOULD do a GET before 
editing?

    -joe

---

From: Tim Bray <[email-masked]>
Date: Tue, 13 Jul 2004 20:38:07 -0700

> How about stating that the client SHOULD do a GET before

I don't think so, because I think automatically generated and updated 
feeds with a single point of control will be a common use-case (perhaps 
the majority use-case).  I think we need a clear description of what 
GET does, what PUT does, and a note to describe the common-use case 
where you GET then PUT.  -Tim

---

From: Mark Baker <[email-masked]>
Date: Wed, 14 Jul 2004 00:49:14 -0400

On Tue, Jul 13, 2004 at 10:26:14PM -0400, Joe Gregorio wrote:
> For this scenario to work [...]

By "work", do you mean;

1. user A is notified of a problem when they try to PUT? ... or
2. user B is denied the ability to PUT because A is editing it?

If #1, I suggest that [1] would suffice to detect the conflict.
If #2, perhaps WebDAV LOCK should be considered.

But in both cases, a PUT without a preceding GET is not a problem.

 [1] http://www.w3.org/1999/04/Editing/

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 14 Jul 2004 08:05:23 -0400

On Wed, 14 Jul 2004 00:49:14 -0400, Mark Baker <[email-masked]> wrote:
> 
>  http://www.w3.org/1999/04/Editing/

I am embarrased to say that I'd forgotten that. Handling the Wiki
situation via ETags is much more appropriate.

   Thanks,
   -joe

---

From: Janne Jalkanen <[email-masked]>
Date: Thu, 15 Jul 2004 15:18:10 +0300

>How about stating that the client SHOULD do a GET before 
A wiki would naturally dismiss a PUT without the corresponding nonce as 
invalid, and thus no problem.  (There's still the question of how the 
nonce should be sent back to the client; there's no facility for it 
right now.)

Some other CMSs would not.

I think a SHOULD is in order, since nothing really breaks if it's not 
required; however a MUST would mean that it would be an inconvinience to 
many.

/Janne

---

From: Robert Sayre <[email-masked]>
Date: Thu, 15 Jul 2004 08:42:21 -0400

Janne Jalkanen wrote:

>
>
>> How about stating that the client SHOULD do a GET before editing?
>>  
>>
>
> required; however a MUST would mean that it would be an inconvinience 
> to many.

I don't understand why we need this. If the client PUTs something that 
conflicts with the state of  the resource, it's the server's 
responsibility to spot the conflict. All server code will have to assume 
that clients will be ignorantly PUTing things all over the place.

Robert Sayre

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 15 Jul 2004 08:56:22 -0400

>  [1] http://www.w3.org/1999/04/Editing/

This does lead to a question of documentation. Should 
detection of lost updates when using the Atom Publishing 
Protocol be written into the spec? I don't believe
that every Atom server MUST support it, just that
*if* they are going to support detecting lost updates
than this is how you do it interoperably.

For example, a new section on Detecting Lost Updates 
could be added that covered that material
in http://www.w3.org/1999/04/Editing/
specifically applied to the EditURI.

    Thanks,
    -joe

---

From: Janne Jalkanen <[email-masked]>
Date: Fri, 16 Jul 2004 13:54:43 +0300

> responsibility to spot the conflict. All server code will have to 
> assume that clients will be ignorantly PUTing things all over the place. 

Err... That's what I thought what I was saying :-).

Of course the server code needs to be checking for ignorant PUTs.  I 
mean, someone might write even a client which does not obey the Atom 
spec, and would break thus every server it touches :-).

I'm just saying that there should probably be a way for a server to 
return a nonce value to the client, so that when it does a PUT, a 
conflict will not occur.  ETags are probably the best way of doing this, 
says my intuition.  But perhaps this practice should be codified somehow.

/Janne

---

From: Mark Baker <[email-masked]>
Date: Fri, 16 Jul 2004 07:55:19 -0400

Sounds good!

By "covered" though, I don't think anything more than a blurb saying
"Atom enabled agents MAY support lost update detection.  Those doing
so SHOULD support the mechanism described in
http://www.w3.org/1999/04/Editing/"

Mark.

Mark.