RE: On the subject of status codes for "does not support"

["Beach, Michael C" <michael.c.beach@boeing.com>]

Seems we have status codes to address the various potential situations
which addresses my initial concerns.

I don't see this as an issue, but I continued to be confused by Scott's
comment below about a requester not knowing where to send such a
request.  The comment suggests that each kind of SAML request/assertion
would be sent to a different endpoint (probably URL in my mind).
However, I was thinking of an alternative implementation where the SAML
responder was a single endpoint that handled all incoming SAML
requests/assertions.  Seems in that case, there may be a higher
probability that the responder might get a request/assertion that it
could not or would not handle.  That was my reasoning behind the
question about status codes.

Am I missing something here?

Mike

-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Thursday, August 05, 2004 9:42 PM
To: SAML
Cc: Beach, Michael C
Subject: On the subject of status codes for "does not support"

Following up further with Mike Beach's question about how a responder
might indicate that it doesn't support a particular SAML feature,
there's also a status code in the spec since prior to last call:

urn:oasis:names:tc:SAML:2.0:status:RequestUnsupported

Again, I don't know how a requester would even know where to send such a
request, but if it just fired one off to an endpoint it knew about that
supported some other profile, this would be one way of responding.

-- Scott