Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



    Date:        Tue, 12 Apr 2005 19:03:03 +0100
    From:        Colin Perkins <csp@xxxxxxxxxxxxx>
    Message-ID:  <667fe4ae08cb65eb9696922ca74ceb18@xxxxxxxxxxxxx>

  | Sure, but if the display agent is unaware of the restrictions, it won't 
  | ever be able to receive the media data. The example I have in mind in 
  | "text/t140" which is UTF-8 text framed within RTP packets [RFC 2793]. 
  | The media type is defined only for use with RTP,

I'm not sure I believe that works.   What prevents this message from
containing an alternative to the text/plain that is (currently) its
only body type, with a Content-Type: text/t140 field (and correctly
formatted for that, as much as it can be in a e-mailbody)  ?

Or what prevents a HTTP response with Content-Type: text/t140?

Sure, the rules for use of that content-type may have been violated,
but what is your MUA (or browser) supposed to do when it receives the message?
All it is likely to know is that it has received yet another odd text/unknown
content type.   And if it is to be displayed, treating it just like all
other text/weird types as the fallback (better than nothing) option ?

I think Ned's point (though he can certainly speak for himself) is that
if rfc3555 is allowing registrations like that, then rfc3555 needs to
be fixed, and any bogus registrations that have been made, need to be
corrected.

kre


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]