W3C home > Mailing lists > Public > www-xkms-ws@w3.org > December 2001

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

From: Stephen Farrell <stephen.farrell@baltimore.ie>
Date: Mon, 03 Dec 2001 11:13:28 +0000
Message-ID: <3C0B5E58.E6E4B868@baltimore.ie>
To: www-xkms-ws@w3c.org

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 

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"?

> Such an identifier could arguably just be included in the URL, e.g.
> http://xkms.xmltrustcenter.org/us_gov_bridge_ca_confidential?name=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
Received on Monday, 3 December 2001 06:13:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:21 UTC