Remove Application Profiles

[laurencelundblade]

Application Profiles seem like an unnecessary complexity to me in an area that (I think) we're trying to make simpler.

I look at this draft as a really useful rewording of some important stuff in section 4 and 5 of RFC 8949. Those sections of 8949 are a bit complicated for readers, so this draft should be simple.

So far the only proposed profile is dCBOR. I think dCBOR exists just fine without the notion of application profiles, just like CDE exists just fine on top of preferred serialization.

To justify the complexity application profiles add, I think we'd want to have three solid use cases for them.

Application profiles are only for variations of CDE. They are not for variations of preferred serialization or a general profile mechanism for all of CBOR. This makes them much much less useful.

[cabo]

Can you explain how giving the concept a name adds complexity?

[laurencelundblade]

Doesn't the burden of justification for something in a document lie with the proponent of the something?

A short answer to your question is that for us careful implementors every concept in a document must be read, digested, thought through and understood to be sure of correctness and completeness.

But, I don't think things should go in documents unless there is justification.

[cabo]

Of course. The most recent mail where I tried to explain the reason for them is Archived-At: https://mailarchive.ietf.org/arch/msg/cbor/7CAgHZxvj34Rf4rcXFGeFwBzv_M

To make a decision, it is necessary not only to understand the benefit, but also the cost of the feature. To me it seems it creates zero cost for those who do not implement it. If you think you do not need it, I would not implement it.

[laurencelundblade]

I don't see how the cost is zero. You have to understand it to know that you don't have to implement it.

There's a cost to protocol designers too. They have to understand it to know whether they should use it or not use it.

There's also some cost to the WG, the IESG and the RFC editor to review.

[cabo]

We could improve the text to make this easier to understand.

The cost of not having the feature is immense. People will notice that their application data model does not map one-to-one to CDE and will do exactly what dCBOR did in the outset -- reinvent a incompatible variant of CDE because their application data model isn't identical to the generic data model of CBOR.

So it is absolutely worth massive effort to have application profiles as a concept in place. I still believe the actual effort is minimal, and I would like to understand what text in CDE creates complexity for you, and how we could minimize the discovery cost for those whose actual cost is zero because they don't need it.

[laurencelundblade]

The justification I am looking for is the description of some more compelling use cases to sit along side dCBOR. I don't think any have been described.

I don't see immensity here. If there was immensity, then there would be at least a couple of examples of bad variants of CDE. So far we only have one variant of CDE which IMO isn't too bad (other opinions aside).

Also, can you say why application profiles are justified for CDE, but not preferred serialization or a general profile mechanism for all of CBOR?

[cabo]

PR #15 should address most of your concerns, without removing the concept of Application Profiles entirely.

[laurencelundblade]

While moving to an appendix is an improvement, I still would like to see application profiles removed. I was waiting for the meeting on Friday before completing the review.