RE: [dss] Profile Identifiers

[Trevor Perrin <trevp@trevp.net>]

At 11:56 AM 2/13/2004 +0000, you wrote:

>Trevor,
>
>I generally agree.  Each implementable concrete profile should have a URI.
>
>However, in the case where there are two concrete profiles specified in a
>document as described below.  An implementation need only implement one.
>So, for example, I could implement the <dss:TimeStamp/XMLTimeStampToken>
>profile without implementing <dss:Timestamp>.

I was thinking a <dss:TimeStamp/XMLTimeStampToken> profile would further 
profile the <dss:Timestamp> profile.  So if you implement the first, you 
implement the second.


>I like the idea of making this profile identifier part of the main structure
>rather than an optional input.

Me too.


>  In fact, I would prefer to make it a
>mandatory element of the protocol which is always included by the client so
>that implementations can easily ensure that it is handling the expected type
>of request from a client and so make implementations more robust.  Can
>anyone think of a scenario when a profile would not be identified?

I can imagine a lightweight client that doesn't send policy identifiers, 
but which can be pointed at various servers, with zero configuration, and 
will either work (the server returns the right type of signature) or not.

If we require the identifier, we require client configuration.  In most 
cases, I agree that the "type-checking" offered by the identifier is 
good.  But I think it should be the client's option.


>Thinking about this raised a related question.  Do we need an optional
>version number for a profile so that servers can manage change between
>profile versions.

I think a new profile version could just define a new identifier.  The 
server could continue to support the old version as well, if a client 
requests it.


Trevor