- From: Stephen Farrell <stephen.farrell@baltimore.ie>
- Date: Mon, 03 Dec 2001 11:13:28 +0000
- 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 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?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