Subject: 54th IETF Meeting Information, and RFC2518 open issues

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 22 Apr 2002 09:36:03 -0700

If you're not on the IETF-Announce list, you might not have seen this
announcement about the upcoming meeting in Yokohama.

To bring our "agenda" up-to-date, here's what I think the largest and
hardest issues are for RFC2518 bis:
 - Whether/how to change the If header rules and syntax
 - Whether/how to change the source property definition

Although the If header has been shown to be interoperable in its simplest
form with locktokens, it hasn't been shown to be interoperable in its more
advanced forms or with ETags.  The source property has not had any
demonstrated interoperability to my knowledge.

I'd like to encourage anybody with ideas on what to do with either of these
two features to make concrete proposals to the list.  If your proposal is
"leave things the way they are", I'd like to see some discussion on how to
meet the requirements for going to proposed standard (how to demonstrate
interoperability, and how much interoperability is enough).

Another ACL draft is expected before the Yokohama cut-off, therefore ACLs
will probably also be discussed in Yokohama.  I'll be asking for a meeting
slot.

Lisa

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of [email-masked]
Sent: Thursday, April 18, 2002 8:42 AM
To: IETF-Announce:
Subject: 54th IETF Meeting Information

Registration for the 54th IETF is now open.
Information can be found on the IETF web site at:
http://www.ietf.org/meetings/IETF-54.html

MEETING SITE:
Pacifico Yokohama Convention Center
1-1-1 Minato Mirai, Nishi-ku, Yokohama 220-0012 Japan
Tel: + 81 (45) 221-2112
Fax: + 81 (45) 221-2136

HOTEL ACCOMMODATIONS:
Information is available on
http://www.e-side.co.jp/ietf54/accommodation.html.
Please be advised that ONLINE RESERVATIONS will be available after April
22nd.

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 22 Apr 2002 18:53:34 +0200

Am Montag den, 22. April 2002, um 18:36, schrieb Lisa Dusseault:

> [...]

If headers with ETags do not add any value to the protocol. For
GET rfc2616 already defines If-Match and friends. Since the ETag
only captures content changes (property changes have undefined
effect on ETags), IF headers for ETag lack a use case.

Having never encountered a client using them, I propose to
drop ETags in IF headers.

The remaining "more advanced" features of IF I can think of are:
- not
- use of URIs with locktokens

URIs with locktokens are in use by us (both server and client).

Does anyone have a use case for "Not"?

//Stefan

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 22 Apr 2002 11:01:42 -0700

> drop ETags in IF headers.

OK; if we drop ETags in If headers how are servers intended to handle
requests using the old syntax, or do you believe that is not an issue (if
so, why)?

lisa

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 23 Apr 2002 10:06:08 +0200

> requests using the old syntax, or do you believe that is not an 

We can handle this similar to the "keepalive" body for COPY requests.

Do we know a client using IF headers with ETags? If it is a feature
not used by anyone, it has not proven interoperability and we should
change/discard it.

If we discover that it is used, or if someone can explain the use
case and benefits, that is a completely different matter.

Our server is able to handle the current IF header syntax, so I
have no problem with the current specification. I just think that
cutting away unused features will increase interoperable
implementations.

//Stefan

---

From: Greg Stein <[email-masked]>
Date: Wed, 24 Apr 2002 23:39:45 -0700

On Mon, Apr 22, 2002 at 06:53:34PM +0200, Stefan Eissing wrote:
>...

An etag in an If: header can be used to assert that a file has been
unchanged since you last fetched it. Specifically, that you still have the
locktoken *or* (you lost it and) it is unchanged.

This is to cover the case where lock a file, fetch it, and then attempt to
PUT the file back. The PUT should succeed if you have the locktoken *or* if
you lost your lock but the etag matches what you GET'd (thus: nobody else
changed it).

Arguably, the semantic could be manufactured with other combinations, but
I'd suggest that is your use case.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---

From: Greg Stein <[email-masked]>
Date: Wed, 24 Apr 2002 23:41:51 -0700

> cutting away unused features will increase interoperable

Same here.

mod_dav handles the current If: header specification (entirely), so no skin
off my back to keep the current spec. However, it is some nasty code that
I'd just as soon remove.

Cheers,
-g

---

From: Yves Lafon <[email-masked]>
Date: Thu, 25 Apr 2002 09:20:29 +0200 (MET DST)

> locktoken *or* (you lost it and) it is unchanged.

You can also see the following note on this subject:
http://www.w3.org/1999/04/Editing/
Thanks,

-- 
Yves Lafon - W3C

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 25 Apr 2002 10:17:39 +0200

Yves, Greg, thanks for the link and the explanation.

So I change my mind and am in favour of keeping If: headers
functionality as they are described in 2518.

Regarding potential length of this header: would it be ok
to allow whitespace between tokens, so that the header can
be more easily split on several lines?

//Stefan