- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Tue, 08 Mar 2005 14:45:06 +0000
- To: jose.kahan@w3.org
- Cc: www-xkms@w3.org
Did a quick trawl of the issues list: 332-tl1: I'd be ok to change this is no implementer objects, i.e. if the proposed value doesn't break anyone's code 332-tl2: I'd have a bias towards only minimal PGP support unless we have demand from some client for more (I'm not aware of any). If such demand arose later, it could be added since there's enough flexibility in the specs (xkms and dsig) and dsig is as Tommy notes, a bit unclear about PGP. I'd be fine with clarifying that only key material packets are to be used for now. 332-tl3: I'd be wary of this. If no-one processes the minor result code then it'd be ok, but if someone branches on those values (and I know they're not supposed to) then this'd break their code. 332-tl4: As above, though I need the problem explained to me (or I need to re-read the spec:-) 332-tl5: I'd be against changing the schema. There could be cases where something like an RA might want to supply both. I've no problem saying a server remains compliant even if only able to process one. 332-tl6: I've no problem disallowing RespondWith in those messages. I wouldn't like to give RespondWith new semantics for CompoundRequest simply to save a few bytes. 333-jk: Discuss:-) My sympathis are with Vamsi on this one. I don't believe its a failing in XKMS, and view this as effectively a new hurdle for the WG. I also think we need to reword the implementation report section on this. 334-jk: I'm ok with saying that KeyName is a good way to indicate the key, but do not want to prevent a server e.g. indexing the key using the client IP address, so I don't want this to be a MUST, and perhaps not even a SHOULD. (Maybe a SHOULE BE ABLE TO if we can write it up correctly.) Stephen. Jose Kahan wrote: > (Sending this early so that people can react to it) > > Hi folks, > > Please don't forget we have a meeting next Tuesday. > > I propose two agenda items: > > - Interoperability open issues [1] > > Let's try to close them or decide which ones will remain open and > justify why so. > > - CR interoperability Report [2] > > Just an item in case that people want to ask for changes or add more > info there. > > Talk to you on Tuesday! > > -jose > > [1] http://www.w3.org/2001/XKMS/Drafts/cr-issues/issues.html > [2] http://www.w3.org/2001/XKMS/Drafts/test-suite/CR-XKMS-Summary.html
Received on Tuesday, 8 March 2005 14:43:47 UTC