I merged. On Fri, Jan 5, 2018 at 4:43 PM, Daniel McCarney <[email protected]> wrote:
> Why not a MUST? If you don't implement preauthorization, there's no need >> for a value. I guess you could provide "null", but ... don't. > > > I have no objections to using MUST over SHOULD. Updated in 5fcaa6c on my > PR branch. > > - Daniel / cpu > > On Fri, Jan 5, 2018 at 4:24 PM, Richard Barnes <[email protected]> wrote: > >> Why not a MUST? If you don't implement preauthorization, there's no need >> for a value. I guess you could provide "null", but ... don't. >> >> On Fri, Jan 5, 2018 at 2:33 PM, Daniel McCarney <[email protected]> >> wrote: >> >>> Hi Ilari, >>> >>> >>>> This impiles that if pre-authorization is not supported, newAuthz >>>> better be absent (this is also useful for detecting pre-authorization >>>> support if the client can use it somehow). >>>> I think this should be at least a SHOULD. >>> >>> >>> You're right. My intention is to make the presence of that field an >>> indicator of pre-authorization support (or lack thereof). I'll update to a >>> SHOULD in my PR since I agree that maps better. >>> >>> Thanks! >>> >>> >>> >>> On Fri, Jan 5, 2018 at 2:27 PM, Ilari Liusvaara < >>> [email protected]> wrote: >>> >>>> On Fri, Jan 05, 2018 at 02:05:22PM -0500, Daniel McCarney wrote: >>>> > In Section 7.4.1 "Pre-Authorization" the spec says: >>>> > >>>> > If a CA wishes to allow pre-authorization within ACME, it can offer >>>> > > a "new authorization" resource in its directory by adding the field >>>> > > "newAuthz" with a URL for the new authorization resource. >>>> > >>>> > >>>> > That text indicates that the CA may wish to *not* support >>>> pre-authorization >>>> > in which case the "newAuthz" resource will not be present in the >>>> directory. >>>> > E.g. the Let's Encrypt ACME v2 directory[0] does not include this >>>> resource. >>>> > >>>> > I think this should be further emphasized in Section 7.1.1 "Directory" >>>> > since this is where a developer is likely to look first when trying to >>>> > determine what directory fields can be assumed present. >>>> > >>>> > I opened a PR to add a small note about this to Section 7.1.1: >>>> > https://github.com/ietf-wg-acme/acme/pull/384 >>>> > >>>> > This is perhaps a step past the line of being strictly editorial. I >>>> would >>>> > appreciate if anyone with objections raise them on-thread over the >>>> next few >>>> > days. >>>> >>>> Why MAY? If implementation does not support some functionality that an >>>> endpoint is exclusively for, it better omit that endpoint. This impiles >>>> that if pre-authorization is not supported, newAuthz better be absent >>>> (this is also useful for detecting pre-authorization support if the >>>> client can use it somehow). >>>> >>>> I think this should be at least a SHOULD. >>>> >>>> >>>> >>>> -Ilari >>>> >>> >>> >>> _______________________________________________ >>> Acme mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/acme >>> >>> >> >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
