2016-02-03 20:55 GMT+01:00 Phillip Hallam-Baker <[email protected]>:
> 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. > And hopefully there will never be such a restriction. The order shouldn't matter in any JSON representation. It does already matter in key authorization hashes. I think if it matters, no JSON should be used. > 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: > The description is just a protection. The server accepting the request should already know what to expect based on the URI and header values. > { > "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. > We don't have large payloads in ACME and having to care about order makes ACME harder to implement. > 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 >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
