Esko Dijk <[email protected]> wrote: > For example, proximity-registrar-pubk is defined as a new field that > can be used instead of proximity-registrar-cert, effectively specifying > an alternative format for identification of a registrar.
> We can do the same for date fields, e.g.
> "created-on" -> "created-on-epochtime"
> "expires-on" -> "expires-on-epochtime"
I don't mind doing this.
Does it establish some precedent that others may dislike?
> The nice thing is that a Registrar or a MASA can easily handle either
> format, while the Pledge can be code-optimized to handle only the
> numeric uint format. (And MASA knows what the Pledge can support so
> will use the proper encoding the Pledge can understand.)
Yes, I agree. It's really not a problem for the non-constrained systems.
> I suspect this can't be wrong, because we're doing the same for other
> fields (e.g. the proximity-registrar-cert as mentioned earlier.)
created-on is almost entirely for documentation/debugging purposes.
Both are mostly irrelevant to actual processing in voucher-requests.
It's on the pledge that I really prefer to avoid having time/date parsing
code present.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
