[ietf-provreg] 3730bis Submitted

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

I just sent the -00 version of 3730bis to the I-D administrator for
publication.  Here's the list of changes copied from Appendix C:

1.  Minor reformatting as a result of converting I-D source format
    from nroff to XML.

2.  Removed the last paragraph from Section 2 that described an error
    in the XML specification.  This was corrected in a later edition.
    References in this specification have been updated to cite the
    most current version.  Preserved the last sentence by appending
    it to the end of the previous paragraph.

3.  Changed text in Section 2.9.2.3 from this:

    "Service messages MUST be created for all clients affected by an
    action on an object.  For example, <transfer> actions MUST be
    reported to both the client that requests an object transfer and
    the client that has the authority to approve or reject the
    transfer request."

    to this:

    "Service messages SHOULD be created for passive clients affected
    by an action on an object.  Service messages MAY also be created
    for active clients that request an action on an object, though
    such messages MUST NOT replace the normal protocol response to
    the request.  For example, <transfer> actions SHOULD be reported
    to the client that has the authority to approve or reject a
    transfer request.  Other methods of server-client action
    notification, such as offline reporting, are also possible and
    are beyond the scope of this specification."

4.  Changed text in Section 2.9.2.3 from this:

    "A <poll> acknowledgement response notes the number of messages
    remaining in the queue and the ID of the next message available
    for retrieval."

    to this:

    "A <poll> acknowledgement response notes the ID of the message
    that has been acknowledged and the number of messages remaining
    in the queue."

    Fixed the example to note the correct message ID.

5.  Changed text in Section 2.9.3.4 from this:

    "Once a transfer request has been received by the server, the
    server MUST notify the current sponsoring client of the requested
    transfer by queuing a service message for retrieval via the
    <poll> command."

    to this:

    "Once a transfer request has been received by the server, the
    server MUST notify the current sponsoring client of the requested
    transfer by either queuing a service message for retrieval via
    the <poll> command or by using an out-of-band mechanism to inform
    the client of the request."

6.  Updated XML references.

7.  Moved RFCs 2781 and 3375 (Informational RFCs) from the normative
    reference section to the informative reference section.

Other document updates are being worked on and will be submitted after
3730bis hits the archives.

-Scott-