> Otherwise whichever non-NIL exists value is used. Oh garbage ;-). Typing while talking...
Otherwise the value of whichever non-NIL filter exists is used. Brian On 2008-11-25 09:17, Brian E Carpenter wrote: > Thanks Alexey. Just two re-comments below: > > On 2008-11-24 18:42, Alexey Melnikov wrote: >> Hi Brian, >> Thank you for your review. >> >> Brian E Carpenter wrote: >> >>> I have been selected as the General Area Review Team (Gen-ART) reviewer >>> for this draft (for background on Gen-ART, please see >>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>> Please resolve these comments along with any other Last Call comments >>> you may receive. >>> Document: draft-melnikov-imapext-filters-06.txt >>> Reviewer: Brian Carpenter >>> Review Date: 2008-11-24 >>> IETF LC End Date: 2008-12-01 >>> IESG Telechat date: (if known) >>> >>> Summary: Almost ready, clarifications requested >>> >>> Comments: >>> >>>> 3.2. Managing filters using SETMETADATA/GETMETADATA commands >>>> >>> ... >>> >>> >>>> A filter can be renamed by first creating a filter with the new name >>>> and then deleting filter with the old one. >>>> >>> This seems underspecified. How does the value get copied from the old >>> one to the new one? Is this the client's responsibility? >>> >>> >> Yes. > > OK, I think an extra sentence would help here. > >>>> If both "/private/filters/values/<filter_name>" and "/public/filters/ >>>> values/<filter_name>" server annotations exist, then the value of the >>>> "/private/filters/values/<filter_name>" is used when evaluating the >>>> corresponding FILTER SEARCH key (see Section 3.1). Otherwise the >>>> non-NIL value is used. >>>> >>> The last sentence is confusing or redundant. Is it saying: "If only >>> one of >>> them exists, it will be used."? That doesn't seem worth saying. >>> >> Yes. >> I've added "(existent)" after non-NIL, is this better? > > How about: > Otherwise whichever non-NIL exists value is used. > > Brian > >>> If it's >>> saying "Note that a NIL private filter does not override a non-NIL public >>> filter." that seems worth saying. >>> Annoying nit: "criteria" is frequently used as if it were a singular >>> noun. It's plural. One of them is a "criterion." >>> >>> >> Yes, good point. >> >>> The formal syntax definition >>> search-criteria = search-key *(SP search-key) >>> is just fine, because that is a plural usage. But I believe that >>> almost every occurrence of "criteria" in the text is wrong and should >>> be "criterion." >>> >>> idnits says: >>> >>> == It looks like you're using RFC 3978 boilerplate. You should update >>> this, as the boilerplate described in the IETF Trust License Policy >>> document (see http://trustee.ietf.org/license-info) is accepted >>> from 10 >>> November 2008, and will be required from 16 December 2008, 01:00 >>> UTC. Version 1.34 of xml2rfc can be used to produce documents with >>> boilerplate >>> according to the mentioned Trust License Policy document. >>> >>> >> I am awaiting for new xml2rfc on xml.resource.org ;-). >> >>> == Outdated reference: A later version (-16) exists of >>> draft-daboo-imap-annotatemore-14 >>> >> Fixed, thanks. >> >> > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
