Re: Spec udpated

Hi Shivaram,

Good work. 

I noticed these two:

On Fri, Mar 18, 2005 at 03:35:37PM -0800, Shivaram Mysore wrote:
>    Issue 333-jk: Added Para [352a] 

Your text:

<quote>
When a client responds with a OPTIONAL element that is not supported by
the Server, then, use ResultMajor=Sender and ResultMinor could have values
like: OptionalElementNotSupported, Failure and MessageNotSupported
</quote>

I think that you forgot to add the OptionalElementNotSupported error
code to the [122] table. Part of the [352a] text should be in the
description too.

For the [352a] text, I would propose the following change, as we had
mention some kind of metadata file:

<quote>
When a client request includes an OPTIONAL element that is not supported by
the Server, the server may use the ResultMajor Sender code and the
ResultMinor OptionalElementNotSupported code. In some cases, depending
on the context, the server may use the Failure and MessageNotSupported 
ResultMinor codes. In any of these cases, the client should check the 
server's supported features, for example by reading a WSDL or metadata file. 
This resource discovery mechanism is out of scope of this specification. 
</quote>

>    Issue 334-jk: Added Para [277a] -I believe this needs a little bit more work 

Your text:

<quote>
Clients and Responders MAY useKeyNamefor HMAC validation. Alternatively,
they may use Identity or other information derived from security binding.
</quote>

Some changes and typo corrections:

<quote>
Clients and Responders MAY use dsig:KeyName for HMAC validation. Alternatively,
they may use other information derived from security binding, such as the
sender's IP address.
</quote>

Comments?

-jose