RE: optional stuff (was Re: URL-level trust (was: Re: XKMS))

My original attempt was to make everything mandatory. One of the
main reasons that we need XKMS is that it is not possible
to use many of the nice features of PKI interoperably because
it is not possible to depend upon deployment.

However this is not practical in certain cases.

The basic principle I was adopting is:

"A client should always be able to depend on a server to support
the features necessary to implement the trust model supported'.

So we exclude any negotiation mechanism from the start. We do not
start off with an ISAKMP style message saying 'here is what I might
like to propose that we might do, do you have concerns in the matter
that you might like to discuss, perhaps over dinner and a bottle or
two of claret?'. If you implement the ISAKMP protocol in its entirety
you can have up to 6 round trips just to select the producer and 
vintage[1].


The basic principle is that complexity in the client is bad, 
complexity in the server is not good but better than complexity 
in the client.

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227

[1]	See RFC 2535 Appendix H subsection 23b. See also [2]
[2]	'On the use of spurious citations in sarcastic comments and
	the gullability of those who look them up', H. Beloc,
	To be published.
> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
> Sent: Monday, December 03, 2001 6:13 AM
> To: www-xkms-ws@w3c.org
> Subject: optional stuff (was Re: URL-level trust (was: Re: XKMS))
> 
> 
> 
> Changing the subject line's becoming a habit, but I want to 
> separate threads. Mike's text (below) suggests defining an
> element that allows the client to identify itself to the 
> responder. Now, that's fine (and can be discussed on the
> other thread), but I can't see us insisting that that field 
> is always filled-in, - if we added it, it'd most likely 
> be "optional".
> 
> So, my question is about optional fields - what should our
> attitude be to these? IMO, the presence of optional fields
> in other specifications has caused problems (less interop, 
> more complex specification), but has also provided a way
> to reach concensus (or maybe just push things under a 
> carpet).
> 
> I'd love to have a rule of thumb, specific to our situation, 
> that we can apply as folks suggest their favorite feature be 
> added as optional (as we all will:-).
> 
> Anyone care to suggest such a "rule"?
> 
> Stephen.
>  
> > Such an identifier could arguably just be included in the URL, e.g.
> > 
> http://xkms.xmltrustcenter.org/us_gov_bridge_ca_confidential?n
ame=Mike_Just but it seems more
> reasonable to add a separate element (in case the name exceeds the length
of URL accepted by some
> servers).  Although I use a personal name in this example, this name might
be the name of an
> application (as Jeremy highlights above or the name of a role).

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com