I think Terminology and Dependencies should also have a mention of HTTP / HTTPS, also RFC3339 (time format).
What I would like to get to eventually is some external document describing a particular style of JOSE /JSON / HTTP / TLS Web service that can simply be referenced by a Web Service spec. This means: * We don't keep having to write out the same thing * We don't have slightly different versions in different specs * This can be handled by code synthesizers and support libraries. I did a pass on this for the Mesh: https://tools.ietf.org/html/draft-hallambaker-json-web-service-01 So far it looks pretty similar to ACME except that I am introducing a new JOSE serialization format as I am looking at supporting future apps that can't tolerate the Base64url encoding of the payload (which will likely be in GB). In section 5, actual examples of the messages would be nice. 5.1 There is a mention of cross origin but no explanation of what is involved. This is worrying, what use is being made of HTTP state mechanisms in ACME? Why is cross origin relevant? So far I have not read anything that gives a rationale. I would prefer to decouple ACME from HTTP as far as possible. HTTP is far to complex to be analyzed at this point. Reinventing the wheel is precisely what to do when someone is offering you jet propelled roller skates. 5.2 I start to get lost at this point. The "resource" values look to me like protocol transaction requests. I think it is important to be clear on this because at some point we are going to want to add in request types that are expressly command like. Commands like "Hello". The reason I would like to have consistency across JSON/HTTP type services is that we are going to hit a requirement for 'service management' type functions at some point. Things like negotiating protocol version, features, declaring end of service, transfer to another, scheduled outages, that sort of thing. That is a module that I would hope we could define once and then incorporate by reference in many Web Services. The syntax of the request is currently: { "resource": "new-reg", "contact": [ "mailto:[email protected]";, ..] } Now that has all the information we want but there is no guarantee "resource" is going to be emitted first in the serialization. That could be a problem if you are dealing with abuse cases like very long messages. As a structural matter, I prefer to guarantee that the description of the object precedes the object. So I prefer to describe 'new-reg' object like so: { "new-reg" : { "contact": [ "mailto:[email protected]";, ..] } } Again, this is something that doesn't make a huge deal of difference for ACME message sizes but would be critical if you were sending a 1GB email. Where it does give a lot of leverage however is when you are using a protocol synthesizer like ProtoGen. The parser knows what type of object it is parsing when it starts on that object. That allows for a more efficient process than having to first scan for the 'resource' tag and then construct the object to emit. 5.6: We are going to do CFRG curves, right? _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
