Comments (dated 04 Apr 1998) from Ned Freed «Ned.Freed@innosoft.com», one of the developers of MIME, to Mark Needleman «mark.needleman@UCOP.EDU» concerning the proposed MIME type for BER
I'm not one of those who objected, but I do see this registration as more than a little problematic.
Media types typically suffice to determine both object syntax _and_ semantics, that is, with a media type (and parameters) in hand an application knows how to process the associated object.
This is not the case with application/ber-apdu. This media type doesn't even manage to cover syntax matters, let alone semantics. (It is an unfortunate fact that in practice multiple syntatic elements are sometimes encoded and stuffed into BER string elements. Sometimes the inner encoding is also BER and sometimes it is not. This makes it impossible to even do complete syntactic analysis of a BER stream without knowlege of its ASN.1 definition.) The simple fact of the matter is that given a generic application/ber-apdu object an application is pretty much in the dark as to what to do other than a limited syntax check.
Now, you can argue that the protocol-oid and protocol-string fields provide the missing information to application. But even leaving aside whether or not switching on parameter values is a good idea, I'm not convinced that this is true.
Since you give absolutely no rules for what to put in these parameters, any random user of this media type is free to put in whatever they please. For example, if I choose to send around X.400 P1 APDUs using this mechanism I could label them with any of the OIDs that happen to be on the various ASN.1 modules the X.400 standards specify. Or I could use a private OID of my own. I could use the string "X.400-P1" for the string label. Or I could use "X.400-1988-P1" to try and be specific about the version of X.400 I'm talking about. Or I could use "X.400 message" or something similar.
The net result is that people use this mechanism at all it is almost guaranteed that they will label the same thing in different ways, and will not interoperate.
Fixing this basically would require registering two new namespaces underneath application/ber-adpu. And this then begs the question of why not use the existing registration mechanism for media types instead.
I also don't like the fact that this mechanism usurps the functions of the top-level media type namespace. Many BER APDUs belong under top level types such as text, image, or audio or model, not application.
There are also some purely technical problems with what you propose in this area. For one thing, not all ASN.1-based PDU definitions have OIDs assigned to them. You would need to clarify what to do in such cases, since you say the OID label is required. And for another, OIDs of this sort are assigned to entire ASN.1 modules, which may in turn define a bunch of different PDUs. You would need to handle this issue as well. And yet another issue is that PDU definitions get revised without the ASN.1 module OID being updated.
You also say that both fields are required, but later talk about what happens if both are present. It doesn't seem to me like there's an if involved if you require both fields.
If this work is to move forward I would suggest that instead of registring a media type for BER APDUs that you write an informational document that explains how to register media types that happen to be BER APDUs. You could talk about how to name such types, how to include information about the ASN.1 definition of the type in the registration, and so on. I don't know if there really are enough common principles for registration of BER APDUs to make such a document worthwhile, but at least such a thing doesn't have the rather serious downside that appears to be present in the current proposal.
...As [Ned Freed] was one of the developers of MIME, his comments tend to carry a bit of weight - it seems unlikely that we will be able to get application/ber registered as a mime type. Ruth Moulton suggested I post these comments to the list and see how folks felt about asking for
as 2 mime types instead - we might be able to get those registered.