> From: Ned Freed [mailto:ned.freed@xxxxxxxxxxx] > > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf