> On Nov 14, 2014, at 3:05 PM, Tom Haynes <[email protected]> wrote: > > Hi Elwyn, > > Here is my first set of responses - there are still some open items. > > Thanks, > Tom > >> On Nov 13, 2014, at 12:27 PM, Elwyn Davies <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi, Tom. >> >> Some comments inline - I have deleted the various things that are agreed. >> >> Regards, >> E;lwyn >> >> On 12/11/14 22:11, Tom Haynes wrote: >>> Hi Elwyn, >>> >>> Before I forget, thanks for the review. >> .. and your prompt response. :-) >>> >>> I have replied inline for the changes I have made or have a question on. >>> >>> Tom >>> >>>> On Nov 11, 2014, at 12:48 PM, Elwyn Davies <[email protected] >>>> <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>>> > > >>> >>>> >>>> s15.26.4/s15.26.5: What happens if the directory has been modified >>>> (entries added or deleted) between calls of READDIR intended to >>>> retrieve segments of the directory information? Related to this, >>>> presumably no ordering of entries is implied in the returned >>>> information - it would be desirable to state this. >>> >>> >>> This is where the cookieverf is supposed to come in. >>> >>> In most implementations, the cookie needs to be persistent, which indeed >>> means an ordering of the information. >> >> AFAICS the text doesn't tie the cookieverf to the change attribute of the >> directory. Presumably this is what is intended - it would certainly mean >> that changes would be picked up and READDIR would have to start from the >> beginning again. >>> > > Asking an expert…
From Trond: As far as I know, the cookieverf is about validating the cookies themselves. There is no requirement in any of the descriptions in RFC1813, RFC3530 or RFC5661 that states that the contents of the directory need to change when the cookieverf does or vice-versa. In theory, the server could throw out the cookies and regenerate them on reboot, for instance.
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
