Support Barry and Sean's comments.

I had one comment you might want to consider:

In 1  Introduction

   This document
   describes two options to address the above limitation, depending on
   the need of the UA. The first option uses the Call-Info [RFC3261]
   header, and the second option defines a new value for the 'purpose'
   parameter in the 'service-uris' element in the SIP conferencing event
   package [RFC4575].

If I keep reading, I find out what the target audience is for both options, but the first clues I get are in 2.1 and 2.2, and both explanations are buried pretty deeply in those sections. Could you add something in the Introduction, or even in Section 2, that tells implementers which option they should look at first?

I agree  with the resolutions you've worked out with Barry on his Discuss and his Comments, so thank you for that, too.

Thanks for addressing all of my Comments

Version -07 addresses my comments.  Thanks.

Is there an intention to retain Appendix A following publication?   It seems unnecessary, although I am sure it was useful during the lifetime of the document as an internet draft.

It sounds like there was agreement to make this document Informational, but it is not reflected in the datatracker. Gonzalo: Please update.

2.1:

   The Call-Info header consists of two parts: a URI and a parameter.
   The purpose of the URI is to provide the XCON-URI of the conference
   focus, and the purpose of the parameter is to indicate that the
   conference focus supports CCMP.

Talking about "the purpose of the parameter", when the parameter *is* the "purpose parameter" is bound to be confusing. I suggest rewording to not use the word "purpose" here. How about just "The URI provides the XCOM-URI..., and the parameter indicates..."?

What Barry said.

And, don't you have to pick one as the MTI?