Patrick, You will pleased to know that after attempting to write the new section describing the expected behavior for the state attribute, that I agree with you. How about the following text for the new State section 2.2?
The state attribute reflects the state of the object "before" or "after" the operation. The state is defined using the OPTIONAL "state" attribute of the <changePoll:changeData> element, with the possible values "before" or "after" and with a default value of "after". The server MAY support both the "before" state and the "after" state of the operation, by using one poll message for the "before" state and one poll message for the "after" state. The "before" state poll message MUST be inserted prior to the "after" state poll message. For operations in Section 2.1 that don't have an "after" state, the server MUST use the "before" state poll message. For example, for the "delete" operation with the "op" attribute set to "purge", or the "autoPurge" operation, the server includes the state of the object prior to being purged in the "before" state poll message. For operations in Section 2.1 that don't have a "before" state, the server MUST use the "after" state poll message. For example, for the "create" operation, the server includes the state of the object after creation in the "after" state poll message. — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 1/3/18, 7:06 PM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: On Wed, Jan 3, 2018, at 14:08, Gould, James wrote: > I can add a subsection in section 2 to describe the expected before for > both the create and the delete (purge) to ensure that the servers > implement it consistently and the clients know what to expect. Do you > agree? I think we will agree to remain in disagreement on the subject itself, as you put the protocol over the semantics and I do the opposite. However putting more text and explanations as you suggest would certainly help implementers to better understand things, so this will be welcome I am sure. -- Patrick Mevzek _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
