Dean Willis wrote: > My personal preference would be to pack both drafts back into one > standards-track document that updates RFC 3261 but is not done using > the "essential corrections" process. I also think that the process > described for handling EKU is a MUST if EKU is present, so it is > something like "Implementations SHOULD be prepared to handle EKU, and > if they do so, they MUST do so according to the process in [9]."
I have not talked to Scott about this yet, but my thoughts mirror yours closely. Regarding Cullen's proposed change: > I propose we strike the last sentence and make the reference to I- > D.sip-eku informative. I think that will be the best path to allow > both the EKU and the domain-certs document get finished faster than if > we try to tie them together in this way. I was also wondering if a happy medium would be reached if we made the normative dependency on I-D.sip-eku a function of an EKU being present at all in the certificate. Text of the form you suggest above sounds eminently reasonable. Those implementations that want to go beyond the call of duty for services such as SIPConnect will be conscientious enough to then implement I-D.sip-eku. Regarding making the drafts essential corrections and whether or not to pack both drafts into one, I will defer to the WG. I certainly had not viewed the drafts as an essential correction, but did view them as work that updates rfc3261. However, and I believe I also speak for Scott here, our preference is to keep them standards track. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: [EMAIL PROTECTED],bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
