move MIME Media type registration to rfc8366bis

[mcr]

move MIME Type registration to RFC8366.

[toerless]

Aaaaarrrggghhh ;-))

I thought that we just discussed in our weekly call to keep the registrartion in constrained-voucher ??

Aka: logic was that rfc8366bis just covers the payload, not the "session-layer" signaling, to which i would count the http or any other media-type signaling elements.

And i just said as much in the renewal request for the IANA allocation as well..

Cheers Toerless

On Tue, Apr 04, 2023 at 09:27:01AM -0700, Michael Richardson wrote:

move MIME Type registration to RFC8366. You can view, comment on, or merge this pull request online at:

https://github.com/anima-wg/constrained-voucher/pull/268

-- Commit Summary --

• move MIME Media type registration to rfc8366bis

-- File Changes --

M constrained-voucher.mkd (46)

-- Patch Links --

https://github.com/anima-wg/constrained-voucher/pull/268.patch https://github.com/anima-wg/constrained-voucher/pull/268.diff

-- Reply to this email directly or view it on GitHub: https://github.com/anima-wg/constrained-voucher/pull/268 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

--

@.***

[mcr]

Aaaaarrrggghhh ;-)) I thought that we just discussed in our weekly call to keep the registrartion in constrained-voucher ?? Aka: logic was that rfc8366bis just covers the payload, not the "session-layer" signaling, to which i would count the http or any other media-type signaling elements. And i just said as much in the renewal request for the IANA allocation as well.. Cheers Toerless …

ah, well I thought we discussed not waiting to tell IANA to renew until we did this, that we could always update IANA later. And also this is a PR subject to WG consensus.

[toerless]

On Tue, Apr 04, 2023 at 09:31:52AM -0700, Michael Richardson wrote:

Aaaaarrrggghhh ;-)) I thought that we just discussed in our weekly call to keep the registrartion in constrained-voucher ?? Aka: logic was that rfc8366bis just covers the payload, not the "session-layer" signaling, to which i would count the http or any other media-type signaling elements. And i just said as much in the renewal request for the IANA allocation as well.. Cheers Toerless …

ah, well I thought we discussed not waiting to tell IANA to renew until we did this, that we could always update IANA later.

First you said we wanted to move the allocation to rfc8366bis.

Then i said we do not need to bother IANA about change of reference in one go with renewal of allocation.

Then we discussed whether or why to do the move.

Then i thought we agreed there was more logic in keeping it where it is (constrained voucher), given how constrained voucher and not rfc8366bis defines all the aspects to which the allocation alludes.

Then i sent email to IANA actually reconfirming that reference will stay as it is (just because of that previous step).

If i am misinterpreting any of our conclusion, mea culpa.

And also this is a PR subject to WG consensus.

Maybe just write into the PR the reasoning, and why what i thought to remember from our discuss is not valid ?

I am fine with anything thats well justified and accordingly documented.

Cheers Toerless

[EskoDijk]

Agree with @toerless that unless a very good reasoning is given for this proposal, we don't do it. One way to get the reasons for/against clear is to open a Github issue and sees what comes - like this one ;-)

My reasoning against this proposal: RFC8366bis doesn't say anything about how to do the COSE signing that is a required part of the "application/voucher-cose+cbor". This is all in the Constrained BRSKI draft. So the media type needs to be there as well, logically.

(Ideally we want RFC8366bis to only include the CMS signing method, because that was also in RFC8366. There's no need to cram other signing methods all into RFC8366bis. That said, it could be an idea to split Constrained BRSKI into 2 RFCs, one for the new Voucher format definition (including COSE signing and media type etc) and one for the Constrained BRSKI protocol that uses this new format.)

[mcr]

Esko Dijk @.***> wrote:

Agree with @toerless that unless a very good reasoning is given for this proposal, we don't do it. One way to get the reasons for/against clear is to open a Github issue and sees what comes - like this one ;-)

Fair enough.