Subject: Q: Put request should return Atom entry?

From: Toru Marumoto <[email-masked]>
Date: Sat, 17 Jul 2004 00:04:48 +0900

I can't seem to find the answer in the Atom draft spec...

When a client sends a PUT request, what kind of a response should 
the client expects?

response code 301 and Atom entry?

Blooger returns "response code 301" AND an updated Atom entry, 
but some system return just "response code 200".

Toru Marumoto
     see you on the web!
________________________________

__________________________________________________
Do You Yahoo!?
http://bb.yahoo.co.jp/

---

From: Joe Gregorio <[email-masked]>
Date: Fri, 16 Jul 2004 14:03:16 -0400

> response code 301 and Atom entry?

I expect the response to a successful PUT should be 200
and no Atom entry returned. That needs to be added to the spec.

    Thanks,
    -joe

---

From: Mark Baker <[email-masked]>
Date: Fri, 16 Jul 2004 14:28:56 -0400

> and no Atom entry returned. That needs to be added to the spec.

Let's not be too restrictive!  I think the minimum that needs specifying
would be to say;

- servers MUST indicate successful PUT requests with a 2xx response
- servers MAY include additional information in the PUT response
- clients SHOULD NOT expect any additional information in a PUT
response

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: Fri, 16 Jul 2004 15:19:26 -0400

> - clients SHOULD NOT expect any additional information in a PUT

Works for me.

   Thanks,
   -joe

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 16 Jul 2004 21:26:43 +0100

> - clients SHOULD NOT expect any additional information in a PUT

+1

cheers
Bill

---

From: Toru Marumoto <[email-masked]>
Date: Sat, 17 Jul 2004 05:55:41 +0900

>> - clients SHOULD NOT expect any additional information in a PUT

same for me, as long as it(whatever) will be defined in the spec.

Thanks!

Toru Marumoto
     see you on the web!

--------------------------------

---

From: Tim Bray <[email-masked]>
Date: Fri, 16 Jul 2004 14:15:52 -0700

>>> - clients SHOULD NOT expect any additional information in a PUT

I see lots of +1's... quick Joe/Rob, grab it and put it in the spec.  
Thanks to whoever originally  asked this useful question. -Tim

---

From: Robert Sayre <[email-masked]>
Date: Fri, 16 Jul 2004 18:57:03 -0400

> Thanks to whoever originally  asked this useful question. -Tim

And so it was done. One question, though. Is the third sentence redundant?
Clients shouldn't expect anything in the response body because servers don't
have to send it. Couldn't hurt, I guess.

Robert Sayre

---

From: Joe Gregorio <[email-masked]>
Date: Fri, 16 Jul 2004 22:46:09 -0400

> have to send it. Couldn't hurt, I guess.

Actually, from RFC2119:

    Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability.

Given that I'd say the third sentence was
redundant and should be dropped.

	-joe

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 16 Jul 2004 20:27:40 -0700

>redundant and should be dropped.

Not quite. Because "servers MAY include", clients "MUST NOT expect". 
This is a direct interoperability interpretation. If I'm creating a 
client that expects additional info, it will not interoperate with 
some conformant servers.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Joe Gregorio <[email-masked]>
Date: Fri, 16 Jul 2004 23:51:08 -0400

Paul Hoffman / IMC wrote:

> client that expects additional info, it will not interoperate with some 
> conformant servers.

I think I'm missing something. Are you saying that

"servers MAY include" implies "clients MUST NOT expect"

and if so doesn't that mean that the second
part is redundant if added to the spec?

	-joe

P.S. I'm not going to argue about every instance
of MUST and MAY in the spec, but I am asking
a lot of questions in this instance to learn
the correct ways to apply RFC 2119.

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 17 Jul 2004 13:22:24 +0100

> part is redundant if added to the spec?

Joe,

I think Paul is right; do not drop 3.

The reason is that the implication you've just said *doesn't* 
logically follow so we need to spec it to stop people abducting to 
other possible conclusions. Imagine bizarro-hacker reading  1 and 2 
and concluding "clients MAY expect content" or even better "clients 
SHOULD expect content".

cheers
Bill

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 17 Jul 2004 08:26:51 -0700

At 11:51 PM -0400 7/16/04, Joe Gregorio wrote:
>>Not quite. Because "servers MAY include", clients "MUST NOT 
>>expect". This is a direct interoperability interpretation. If I'm 
>>creating a client that expects additional info, it will not 
>>interoperate with some conformant servers.
>

Yes.

>part is redundant if added to the spec?

Yes. But what you may be missing is that putting redundant things in 
the spec sometimes has value. Assume that we only included "servers 
MAY include" in the spec. A client writer is reading the spec to see 
what he/she needs to do to interoperate. They see nothing about 
clients in this section, so they assume it doesn't apply to them.

Seen another way, we could say only "clients MUST NOT expect" and 
force server writers to infer from it that "servers MAY include". I 
think most people here would chafe at that, even though it is 
equivalent.

That's why I am advocating for including both "servers MAY include" 
and "clients MUST NOT expect". One of them is redundant, but 
including both helps the two important parts of our readership. We 
don't need to do this in every place, just where we are talking to 
different audiences.

>the correct ways to apply RFC 2119.

Understood. It's not as easy as one would think. I have written specs 
that on round -04 someone has a question about the MUST/SHOULD that I 
should have seen in the -00. A general rule is to assume that 
implementers five years from now will know *much* less about the 
subject than the people writing the specs today, yet we want them to 
interoperate as well as we hope to when the spec is finished. The 
goal is to write a spec that helps them as much as it helps us.

--Paul Hoffman, Director

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 17 Jul 2004 16:47:02 +0100

Paul Hoffman / IMC wrote:

> Yes. But what you may be missing is that putting redundant things in the 
> spec sometimes has value. 

I don't think it's redundant in this case. "clients MAY expect 
content" doesn't seem to be disallowed by 1 and 2.

cheers
Bill

---

From: Mark Baker <[email-masked]>
Date: Mon, 19 Jul 2004 00:50:05 -0400

> client that expects additional info, it will not interoperate with 

Mostly, but there are different forms of interoperatation.  By using
"SHOULD NOT", I meant to support the case where private (but declared)
extensions between clients and servers were used, which provides a
degraded form of interop where agents not party to the extension can
at least determine that they don't understand the message and fail
gracefully.  For example, imagine an extension called
"ReturnBodyOnPut" which a client declares as mandatory in the PUT
message.

Discussion to date concerning Atom extensibility has suggested the need
for "must understand" support in the data format.  What I'm talking
about is doing the same thing for the protocol, at least where the
protocol supports it (e.g. SOAP).

The bigger question though, is whether or not the group is interested in
supporting private extensions.

Mark.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 19 Jul 2004 09:16:57 -0700

>supporting private extensions.

In a word: no. Public extensions are fine and will be fully and 
enthusiastically supported by Atom. In the case above, a public 
extension could say "this extension changes the 'MUST NOT expect' 
from the base spec to 'SHOULD expect' when this extension is 
present". But that is done explicitly in the particular extension 
spec, not in a private fashion.

--Paul Hoffman, Director

---

From: Mark Baker <[email-masked]>
Date: Mon, 19 Jul 2004 12:50:53 -0400

> spec, not in a private fashion.

Perhaps my use of the word "private" brings with it some unintended
semantics.  Let me explain another way ...

Atom - format and protocol - *will* be extended in ways which are not
publically specified; history shows us that this is inevitable.  What
explicit recognition for this buys us is graceful degradation when
extended agents bump up against unextended ones.

FWIW, incorporating support for mandatory extensions is fairly common
practice nowadays in protocol (and more commonly, data format) design.
SOAP has them[1], SMIL has them[2], Waka[3] will have them, and HTTP
wants them[4][5].  And as I mentioned, it seems that the Atom data
format will also support them.  I don't think it's too much to ask then,
that the Atom "API" at least consider them.

Cheers,

 [1] http://www.w3.org/TR/soap12-part1/#soapmu
 [2] http://www.w3.org/TR/smil20/smil-content.html#ContentControlNS-SkipContentAttribute
 [3] http://gbiv.com/protocols/waka/
 [4] http://www.w3.org/TR/WD-http-pep-971121
 [5] http://www.ietf.org/rfc/rfc2774.txt

Mark.

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 19 Jul 2004 18:51:43 +0100

> semantics.  Let me explain another way ...

No, I think it was the word 'support',  where support could imply 
enablement, encouragement or both.

cheers
Bill