id selector advertising reloaded

My current favorite value for the id selector advertising HTTP header "X-ID-Selector":

version='urn:osis:infocard:2008-04'; name='urn:osis:infocard:names:openinfocard'; capabilities='+nossl+javascript-issuerpolicy'

• version has a constant value until we change the spec for this HTTP header
• name is one from a OSIS defined list
• capabilities is a string of capabilities.
  • "+" indicated support for a capability.
  • "-" indicates missing support for a capability

These three capabilities are the first (and currently only) ones I think that matter to a relying party.
What needs to be defined is a list of capabilities that define the relationship between the RP and the id selector, and are relevant to the RP in regard of what response is generated to the HTTP request.

update: Mike Jones suggested to use the string ISIPv1 to denote capabilities of the id selector in regard to the features listed in the interop plan that can be downloaded from the User-Centric Identity Interop Google Group's page. I see this string "ISIPv1" as a placeholder for the "real" capabilities that need to be defined. So maybe ISIPv1 means "+nossl+issuerpolicy+javascript". As long as the list of relevant capabilites (for the relationship to the RP) is this short I don't see much sense in having the ISIPv1 string. The discussion arose from the fact that sending an additional HTTP header means more bytes to be send for each request the browser sends. I agree to this point. So "ISIPv1-issuerpolicy" makes sense. I would like the value of the header to be somewhat human readable. So maybe the following is a shorter alternative that we can live with:

v=1; name='openinfocard'; idv='0.9.9'; c='ISIPv1-issuerpolicy'

jshelper denoting a javascript helper object which interface needs to be defined. idv beeing the version of the id selector.
Someone suggested a "morehere" part of the HTTP header... The value of this would be the URL of the capabilties metadata e.g.: morehere='https://xmldap.org/capabilities?name=%n&idv=%idv' or morehere='http://axel.nennker.de/c?name=%n&idv=%idv'. I must say: I don't like this but if somebody conjures an example of the returned metadata and this is much longer or complicate than the capabilities part of the header value proposed here, than I might see sense in this capabilities by reference approach.

This image shows (a local install of ) the XMLDAP relying party displaying the value of the X-ID-Selector HTTP header: