Subject: RE: RFC 4612 - historic status

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 14 Aug 2006 12:57:27 +0200

Brian

The details of whether one branch of the MIME tree or another
is best suited for the application is definitely more suitable for the
RAI area.

The fact that this problem is not discussed in the RFC
and the historic designation is misleading,
is a good subject for this list.

I personally think something needs to be done,
such as publishing a bis version with informational
designation and an IESG note about the advisability
of using the audio MIME type.

Y(J)S

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Monday, August 14, 2006 11:23
To: Paul E. Jones
Cc: 'John C Klensin'; [email-masked]; 'Eliot Lear'; [email-masked]
Subject: Re: RFC 4612 - historic status

I suggest that instead of disturbing a couple of thousand people with
this discussion, it would be profitable to take it up with the RAI Area
Directors. They certainly know more about it than I do.

     Brian

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 14 Aug 2006 09:36:49 -0700

> From: Ned Freed [mailto:[email-masked]] 

> > 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.