Re: I-D ACTION:draft-iesg-media-type-00.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-iesg-media-type-00.txt



    Date:        Fri, 1 Jul 2005 12:57:15 +0100
    From:        Colin Perkins <csp at csperkins.org>
    Message-ID:  <D1DC9E64-B6C8-40DD-9CCC-F6C62DA89E54 at csperkins.org>

  | I do not find this argument persuasive, since the media types in  
  | question have been deliberately specified as framed types to avoid  
  | this issue.

I believe that you're both seeing, and missing the point, at the
same time there.

I'd expect that much of the problem is that media types should
depend upon the data that is carried, and how that is to be represented,
and should not depend in any way upon the mechanism used to carry them.

Some of the objections may have been from people who simply assumed that,
and could not believe that a parameter that is intended to specify the
format of data was instead (or additionally) being used to specify a
format for the transport protocol used to carry the data, or being linked
to such a thing.

It is simply the wrong parameter to be using for that purpose.

For example, if I receive an RTP stream carrying a text/whatever, and
store the content (unchanged, but removed from its RTP transport) into a
file, what media type do I use to identify the file?   If it remains
text/whatever (same value) then it will appear as that when I send it
via e-mail, or a web browser fetches it.   If it isn't to be text/whatever
then what on earth is it?   Something random and unidentified?  If there
is a media type for it, that is what should be being used by RTP.

kre


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf




Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.