From: Ned Freed [mailto:ned(_dot_)freed(_at_)mrochek(_dot_)com]
If what I am reading is correct it sounds like the real
design mistake
here was putting semantics into content types in the first place.
No, the mistake is in reading more into the very limited
semantics of top level types than was ever intended. As
Harald says, the way SDP uses top level types is at odds with
their intent. And we have two choices: Fix that mistake or
continue to kludge around it.
Remember that I deal in an environment where there are no user errors, only
design errors and there are no mistakes unless we fail to identify an error and
repeat it.
It sounds like there is a design error in SDP. It may or may not be sensible to
fix it. But it sounds like being forced to rely on a historic RFC is a suitable
penalty to make for a design error.
Now, you could argue that media types should be assigned
numbers, not names, or even better a meaningless string of
characters. This would avoid the both the semantics
associated with names as well as any semantics attachment
issue. But it comes at the expense of readability, and at the
time the system was set up it was felt that having readable
type names had benefits well worth the costs.
Well on my machine those 'characters' are actually represented by numbers...
I think that readability is a plus. And binary schemes do not necessarily help.
The benefit of a text scheme is that the probability of accidental collision of
unregistered types is very small. The Windows 3 letter file types work
amazingly well considering that they are an unmanaged space and there are a lot
of points defined.
I currently have an issue with an ASN.1 OID. We want to start using it almost
immediately but we also want to encourage competitors to use the same OID so
getting it cut off the VRSN arc is not satisfactory.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf