Change:
KeyPurposeId for general document signing purposes. In circumstances where code signing and S/MIME certificates are also <del> widely used for document signing, the technical or policy changes that are made to code signing and S/MIME certificates may cause unexpected behaviors or have an adverse impact such as decreased cryptographic agility on the document signing ecosystem and vice versa. </del> <ins> used for document signing, technical or policy changes made to the code signing and S/MIME ecosystem may cause unexpected behaviors or have an adverse impact such as decreased cryptographic agility on the document signing ecosystem and vice versa. </ins> There is no issue if the vendor-defined KeyPurposeIds are used in a <del> PKI (or a trust program) governed by the vendor.  However, if the KeyPurposeId is used outside of vendor governance, the usage can easily become out of control (e.g. - When the end user encounters vendor-defined KeyPurposeIds, they might want to ask that vendor about use of the certificate, however, the vendor may not know about the particular use. - If the issuance of the cert is not under the control of the KeyPurposeId owner, there is no way for the KeyPurposeId owner to know what the impact will be if any change is made to the KeyPurposeId in question, and it would restrict vendor's choice of OID management.  etc.). </del> <ins> PKI governed by the vendor or a set of specific group of vendors. However, if the KeyPurposeId is used outside of vendor governance, the usage can easily become out of control.  For instance, when the end user encounters certificates with vendor-defined KeyPurposeIds, they might want to ask that vendor about use of the certificate. However, if those certificates were not governed by the KeyPurposeIds owner but by another vendor, the vender who own the KeyPurposeIds may not able to control use, or even do not know about the use. - If the issuance of the cert is not under the control of the KeyPurposeIds owner, it is hard to estimate the impact of change to made on the KeyPurposeId.  Changes related to KeyPurposeIds possibly make negative impacts that some group of people do not tolerate, and it could become a migration agility issue. </ins> Therefore, it is not favorable to use a vendor-defined KeyPurposeId for signing a document that is not governed by the vendor. <del> This document defines a extended key purpose identifier for Document </del> <ins> This document defines an extended key purpose identifier for Document </ins> Signing. 2.

Discussion:
changes are followings We accepeted your comment We accepeted your comment we stop using term "trust program" and changed as following "KeyPurposeIds are used in a PKI governed by the vendor or a set of specific group of vendors." "Unless certificates are governed by a vendor(s) specific PKI, certificates that indicate usage for document signing.." We accepeted your comment >(e.g. - When the end user encounters... >Editorially, please split this large "(e.g.," text block into distinct sentences. we divided the sentence, and clarified the relationship between KeyPurposeIds owning vendor and another vendor. We accepeted your comment We accepeted your comment prescribed behavior for RFC8358. We accepeted your comment We accepeted your comment as follows We removed secound MAY, and numbering. We further clarified the " outside of scope" case where it is up to software. We clarified order of "Excluded KeyPurposeId procedure" and Permitted KeyPurposeId procedure. we accept your change and changed as follow. "TLS (id-kp-clientAuth) or S/MIME (id-kp-emailProtection) etc."