Byron,
On 30/11/09 9:45 AM, "Byron Ellacott" <[email protected]> wrote: [..] > >> lastly, the draft suggests "the server MUST NOT accept a client's request >> unless it has generated and sent a response to the client's previous >> request" - it appeard the _assumption_ made is that the client deals with >> the resources of only one entity. What if it deals with more? What if the >> ISP is representative of multiple organisations and wishes to do multiple >> updates in parallel? > > The terminology in section 1.1 defines a client as a unitary resource holder. I just re-read section 1.1 and I did not see the words you write above. I note that it does say the ISP assumes the role of the client, and the ISP is the subject of a resource certificate. I think that definition should be made clearer that it is singular relationship. (ie I would much rather your words above in the terminology) > If one ISP is representative of multiple entities it will take the part of > multiple clients. What I _think_ you mean is if one ISP is representative, but not necessarily the subject of, multiple resource certificates. I highlight this as while you moot that the CA which drives the https/CMS signing the client definition is bonded to the resource certificate - efficiencies of issuing https/cms certs can be made. > >> section 3.2: >> >> Please specify here the version of XML schema that this draft in its common >> message format uses (not just describes) and the section (section 4) that >> contains the xml schema. I think that it needs to be done prior to the >> introduction of the template and template values. > > The document notes in section 4 that this is a "RelaxNG compact form schema". > For future note, should it become necessary to provide a reference to this > schema, http://www.relaxng.org/compact-20021121.htmlis the syntax > specification document for RNG-C. I think you missed my initial point. I'm after a brief intro at sections 3.2 telling me there is a complete schema v1 at section 4, of which of which these templates are derived from. It seems disjointed to me to start introducing XML templates without letting me know that a full schema exists just 10 pages ahead. Additionally, since you provide a reference for RelaxNG, no such reference exists in the references section of the draft. Please correct. > >> http://www.apnic.net/specs/rescerts/up-down/ responds with a 404 (a pretty >> 404, but a 404 nevertheless) So the namespace is invalid. > > The relevant observation here is that in XML the "namespace name, to serve its > intended purpose, should have the characteristics of uniqueness and > persistence. It is not a goal that it be directly usable for retrieval of a > schema (if any exists)." [Section 3, "Declaring Namespaces", > http://www.w3.org/TR/xml-names/] ack.. although people expect it. ie no-one cares if you do, it's just irritating if you don't. (ie great, I can grab it from there with a wget and not have to cut-n-paste with clean-up from the ID) > >> I think I would like to see a summary table of all of the HTTP response >> codes used by this protocol. > > Its not clear how a reproduction of section 10 of RFC2616 would assist the > reader of this document. Are you saying that all the current implementations of server and client use all the HTTP error codes? including redirection? 206 partial content? (which would invalid in the CMS structure??) Why would the server generate a 502 bad gateway? Answer - it wouldn't / shouldn't act as a gateway.. So to eliminate all those silly possibilities you wouldn't need to reproduce the entire section 10. Just the ones that are actually used in earnest. The document mentions only one error code. "HTTP 400 Bad Data" .. Are you intentionally diverging from RFC2616's "400 Bad Request"? .. and in my mind by only seeing one http error code mentioned - it draws my mind to the "is that it?" question. (hence why I asked for a summary) My guess is that the response/error code list would be a small list and worth the effort. > >> Section 3.5.1 >> >> Looks like a wayward "]": >> >> ski="encoded hash of the subject public key]" /> > > Noted as a nit to be corrected in the next version. > Thanks Terry _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
