Kent, Balazs, I don’t see a specific need for timestamps, so I can accept your arguments against it. Just add a sentence about it somewhere into the draft. It can be an appendix. OK with me. A timestamp could be added in the future if it is really important enough.
LastModified is drop-dead simple to do and achieves equivalency, no more justification is needed. The same rules apply: - ETag is a MUST, LastModified is a MAY - root-node is a MUST, inner-nodes is a MAY I'm perfectly fine with this. Since we are in agreement maybe I should just stop here. Since I noted that I haven't done a good job at explaining how the ETag mechanism works, let me take the example below and explain how this situation is avoided using ETags. I also realized that servers supporting Last-Modified in deeper levels than just the root can do the same thing as I explain for ETags below. f this isn't obvious, here's an example: 1. Client A sends an edit to the server If-Unmodified-Since t0. Successful. Receives a Last-Modified timestamp t1. 2. Client B sends a an edit to the server. Last-Modified timestamp on server is now t2. 3. Client A sends an edit to the server without If-Unmodified-Since. It just sets one tiny little leaf off in one corner. Successful. Received a Last-Modified timestamp t3. 4. Client A sends an edit to the server If-Unmodified-Since t3. Successful, but clobbers Client B's edit, leading to a misconfiguration, which opens a security hole. This is because the If-Unmodified-Since uses less than or equal in its test. The ETag mechanism is not susceptible to this issue, as it uses an equality test. I don't think this example is valid. Skipping past the obvious programming error, the equivalency you're trying to make applies to Etags too. 1. Client A sends an edit to the server If-Match e0. Successful. Receives a ETag e1. 2. Client B sends a an edit to the server. ETag on server is now e2. 3. Client A sends an edit to the server without If-Match. It just sets one tiny little leaf off in one corner. Successful. Received a ETag e3. 4. Client A sends an edit to the server If-Match e3. Successful, but clobbers Client B's edit, leading to a misconfiguration, which opens a security hole. Here's the same example again in some greater detail. 1. Client A edits server:/{eQ}ifs/{eR}interface[name="1/1/1"]{eZ}/... where {eX} means that the client asks the server to confirm the ETag value X sits at the path to the left before committing. Success. Server returns new ETag eB on / (the root), /ifs and interface 1/1/1. 2. Client B edits server:/acls[name="intf 1/1/1"]/... and server sets ETag eF on / and /acl intf 1/1/1. 3. Client A edits server:/users/user[name="joe"]/password without any ETag check. Server sets eY on / and /users. 4. Client A edits server:/{eY}acls[name="intf 1/1/1"]{eB}/... . Check eB fails (server has eF), edit aborted. Best Regards, /Jan
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod