Re: WebDAV sync last call

--=-qmW/o3+REwmiv5hLQw+j
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-08-30 at 09:38 -0400, Cyrus Daboo wrote:
> Hi folks,
> The authors believe the WebDAv Sync document=20
> (<https://datatracker.ietf.org/doc/draft-daboo-webdav-sync/>) is ready to=
=20
> go to the IESG for consideration of publishing as an RFC. We'd like to ge=
t=20
> final reviews from this list along with a list of existing or planned=20
> implementations of this draft to include as supporting documentation for=
=20
> the IESG. Please review and provide feedback, thanks.

Hi Cyrus,

There are a couple of things that have come up for me recently in
relation to this draft.  I'll spell them out here, but I'm happy enough
with the draft as it stands, and I would rather see this approved than
for my issues (or maybe "wild ideas" might be a better term :-) to
disrupt the process.


(1) invalid sync token error

When I send a token which is invalid I receive an error response.  This
is not particularly useful to me in my client.  I (somehow) got an
invalid sync token - maybe it expired - but there's probably no useful
interaction with the user that I can take as a result.  I just have to
fall back to a full re-sync.  It seems to me that it would be more
useful to treat this case the same as if no sync token were supplied,
perhaps also supplying additional information that the sync token was
(expired|invalid|...) within the response.

DAViCal was in fact doing this (without error information) until I
recently corrected the error.


(2) long polling

When I make a sync request I would sometimes like to be able to indicate
to the server that it is acceptable for it to treat my request as a
"long poll", so that the server would hold my connection open until a
change occurred within the hierarchy of the request.

For a server to do this, I think that it would be advantageous for the
old sync token to be provided within the request headers, rather than
within the XML payload of the request.  I believe that doing this would
make server processing easier, since all necessary data for deciding
whether changes have occurred (URL, Depth, Token) would be in the
headers.

There's nothing I can see in the current spec which would actually
preclude implementation of the report as a long poll, but if one were to
actually do that it might be less than ideal for some clients.  On the
other hand if the possibility is available in a "soft" way as an
optional implementation then a client hoping for support could easily be
written to work just fine with an non-supporting installation.

For example if the client indicated a long poll response was acceptable
simply by including a "Sync-Token" header containing the old token, an
unknowing implementation would simply respond, as at present.  A knowing
implementation could hold responding until something changed.  The
client written to support this would want to know that this was a long
poll, so it could immediately re-request, so the server could also
indicate this by providing the sync token back as a header.

Cheers,
					Andrew.

--=20
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
        There is no snooze button on a cat who wants breakfast.
------------------------------------------------------------------------


--=-qmW/o3+REwmiv5hLQw+j
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAABCAAGBQJO6FBJAAoJEOr8/r+P646/qQcP+wbxM1Rme/lRrIX7RcpdNZaf
8x3XNaKNxYLtxvPov52yynfeFMuqF5kXokOX0Hc0kSQqR+Mf7ofUAG5soNF9Vgn3
cu0eFcLFTBe56w9b4oNKVQMFbtU7XHqNMUTOzXWB8UH7l48VmPNcSSLlusWk43yn
ZXOji91zrRNPWEgIREV9NMJ8+fj0toLZi/A05Huocs2cDLJBz8r3/v5Vi8N1Gchv
DyCuSXsmTcFWJQolF34uB7K3ubbCfYdM402GiY9uyB97JcEoQwtUNVUS+mR2f8Eo
vt7DyKzv1QNcf4kQ4Xyx9szthvUpa7wBDVA+f6g1i/IEHEVyLGWH1uV5BKKZ34MV
wnsro4mgovkNBHOUq7FYXXa0oHN7y+3wQmfVE74RdeVbk9pZQFbF6tdOQsUV6KWe
SF5p3ccAQOUj7MScbG7duGxJ8y3QnuWKHsyJDpQRtR7Dx4rtOgpLMwNeEtrzBvCX
pXakhiUqbgg3hDel2rLA9871KKf0cQUD8Q+0b4abjzkJjJxvv5jukY0EIWJlWN5N
vUEec9s1q0EiQIxK4/JUwgdIFcU7lXynvoLZeIM/sXsArVG3xxCLnvfv8LwPkAcV
dck7eUyzDFGd9hOZyBK9uxEUi8xEM/1Uar3iGR5dOi0ADmWAP7yyerI+rHoqj6U1
9irjfgR7bYLWgtgqp7OA
=5puB
-----END PGP SIGNATURE-----

--=-qmW/o3+REwmiv5hLQw+j--