I am voting for "don't". (Is there a vote ?). I can't find in https://datatracker.ietf.org/doc/review-ietf-anima-voucher-05-genart-lc-housley-2017-10-03/ anything suggesting that we should also describe support for XML in the document. Just the need to complete the spec with the necessary signaling elements to support JSON. I think to remember we (authors) didn't only specify JSON to avoid documenting the necessary signaling for XML, but also in an attempt to KISS, because elements like registrars likely would need to implementations all options. I also think we concluded that someone who strongly demanded XML would be given the opportunity to do this in followup work, because that would also give more time and opportunity to discuss/explain the insufficiency of JSON for whatever folks want to use XML for in that followup work. Similar logic to why we outsourced the voucher-request from the voucher draft into BRSKI. Cheers Toerless On Tue, Feb 06, 2018 at 04:53:14PM +0000, Kent Watsen wrote: > Hi all, > > Russ's comment led to the creation of an eContentType OID called > id-ct-animaJSONVoucher. Given that YANG modeled data can be > encoded in XML or JSON, I think that we made a mistake in only > registering the JSON encoding. > > FWIW, we originally choose to standardize on just JSON because > we were trying to avoid the signaling complexity, exactly what > this eContentType value provides. It seems that, when we added > the OID, we should've reexamined that earlier decision. > > While I'd love to say that the fix is just a matter registering > another OID, that draft uses the word "JSON" throughout, so a > slightly more involved edit would be needed. > > Thoughts? Is it too late? > > Kent > > -- --- tte@xxxxxxxxx