[lug] On standards conformance
Tom Christiansen
tchrist at perl.com
Mon Nov 30 20:29:42 MST 2009
In-Reply-To: Message from Sean Reifschneider <jafo at tummy.com>
of "Sun, 29 Nov 2009 22:05:46 MST."
<4B1352AA.7040606 at tummy.com>
+------------------------------------------------+
| CAVEAT LECTOR: Read this in a fixed-width font |
| *only*, lest it be scrambled. |
+------------------------------------------------+
PRESCRIPT:
I know no can be bothered to read this informative and
non-hostile. But you should, though; you really should.
» This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
» --===============0479143799==
» Content-Type: multipart/signed; micalg=pgp-sha1;
» protocol="application/pgp-signature";
» boundary="------------enigE6E8E319FFF98F4056CFF1C6"
» This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
» --------------enigE6E8E319FFF98F4056CFF1C6
» Content-Type: text/plain; charset=ISO-8859-1
» Content-Transfer-Encoding: quoted-printable
> On 11/29/2009 12:41 AM, I wrote:
>> I regret that your UMA is not set up to handle PDF. Have you ever=20
>> heard of MH? It has no difficulties with such things. You might
> Sorry, but we're not going to make the posting requirement be "MH
> configured with PDF".
I didn't say to do that, or even that everyone should. You were the
one with the problem, so I kindly pointed out that your mailer was
behind the times in certain regards, and offered one possible upgrade
path for you. You don't have to upgrade, of course, nor should anyone.
Agreed?
I never see the problems you guys do, and thought that if you didn't see
them anymore, it wouldn't bother you.
Even taken at its most charitable, that's what this "just use gmail" stuff
was all about. So why the double-standard, hm?
> Further, I'm quite sure that we don't want to make everyone on the list
> configure PDF for reading and responding to messages.
PDF is merely one particular MIME content-type out of infinitely many.
> I'm perfectly happy to disable signing posts to the list, if that annoys
> people. However, that has not been brought up as an issue.
Don't you find it ironic that the very people complaining about
"attachments" seem guilty of their own complaints?
You seem to want some sort gatekeeper about "attachments". Because you
have not defined what an "attachment" even *IS*, this can't be coded up.
Forget about coding; have you seen anyone profer a description that would
allow a reader to determine what they can or cannot, or should or should
not, be doing?
I have not.
I am not comfortable with any discussion of "attachments" until and unless
someone should tell us all precisely what an "attachment" is, and in what
RFC that definition appears. I say that because in search of an answer,
I have quite carefully read the following pertinent RFCs:
· RFC 1341: MIME: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
· RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
· RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
· RFC 2047: Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text
· RFC 2048: Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures
· RFC 2049: Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples
and I found a *most* curious thing...
_________________________________________________________________________
| IMPORTANT: |
| The word "attachment" never occurs in even one of ANY of those RFCs! |
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
The only mention of "attachment" that I could find occurs in the much later...
· RFC 2183: Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field
Which for your delectation reads:
disposition := "Content-Disposition" ":"
disposition-type
*(";" disposition-parm)
disposition-type := "inline"
/ "attachment"
/ extension-token
; values are not case-sensitive
disposition-parm := filename-parm
/ creation-date-parm
/ modification-date-parm
/ read-date-parm
/ size-parm
/ parameter
filename-parm := "filename" "=" value
creation-date-parm := "creation-date" "=" quoted-date-time
modification-date-parm := "modification-date" "=" quoted-date-time
read-date-parm := "read-date" "=" quoted-date-time
size-parm := "size" "=" 1*DIGIT
quoted-date-time := quoted-string
; contents MUST be an RFC 822 `date-time'
; numeric timezones (+HHMM or -HHMM) MUST be used
As you plainly see, that is *not* the way some of you have used the word
"attachment". I know this because I send non-attachments and people
improperly and incorrectly scream "attachment". Apparently there are
noncomformant user-mail-agents out there lying to some of you about this
whole "attachment" business. You really shouldn't shoot be shooting
messenger for reporting this bug to you, nor should you pretend he has
done something he has not.
I therefore do not quite know what an "attachment" is, because I am
using the word according to the spec but you are *not* using according to
the spec. I have suspicions as to why, but they probably do not accord
with yours.
Please make no attempt to claim that an "attachment" is whatever
this or that program happens to call an "attachment". That's no
definition at all! See above.
I most strongly suggest you compose your policy using the same language
that extant, relevant standards employ instead of making up your own
different definitions to standard terms that are already defined.
Another standard that you are going to want to (need to) read and
understand is
· RFC 3676: The Text/Plain Format and DelSp Parameters
Despite this standard dating from way back in 2004, many of you are
still using non-conformant user-mail-agents, which incurs hostility.
Here's its TOC:
§ 1. Introduction
§ 2. Conventions Used in this Document
§ 3. The Problem
3.1. Paragraph Text
3.2. Embarrassing Line Wrap
3.3. New Media Types
§ 4. The Format and DelSp Parameters
4.1. Interpreting Format=Flowed
4.2. Generating Format=Flowed
4.3. Usenet Signature Convention
4.4. Space-Stuffing
4.5. Quoting
4.6. Digital Signatures and Encryption
4.7. Examples
§ 5. Interoperability
§ 6. ABNF
§ 7. Failure Modes
7.1. Trailing White Space Corruption
§ 8. Security Considerations
§ 9. IANA Considerations
§ 10. Internationalization Considerations
§ 11. Acknowledgments
§ 12. Normative References
§ 13. Informative References
§ Appendix A: Changes from RFC 2646
Please pay special attention to section 3.2, "Embarrassing Line Wrap".
RFC 3676 notably states immediately after that particular section
that new
have suffered from a lack of backwards compatibility
and an often hostile user reaction at the receiving end.
Which is precisely what we see occurring here, isn't it?
Back to the witch-hunt for shooting down legal MIME types...
MIME exists to permit exchanging mail of arbitrary content instead of being
constrained 7-bit ASCII plaintext. Some mailing lists do restrict mail to
conforming to pre-1992 standards, but that's something like 11 Internet
generations behind the times, and not too far past punch-cards.
As I'd seen a rich assortment of MIME times go by on this list, and given
that *every* mail message is MIME-encapsulated by the list's distribution
mechanism, I surmised its denizens were using MIME-aware UMAs. This appears
to have been a naïve assumption, but it was never a disingenuous one.
Is either or both of these part of your plan?
· MIME-ALLOW: explicitly list which MIME types you permit; any MIME
¯¯¯¯¯¯¯¯¯¯ type not in your list is by its absence forbidden.
(ie: Assume evil whatever isn't good.)
· MIME-DENY: explicitly list which MIME types you forbid; any MIME
¯¯¯¯¯¯¯¯¯ type not in your list is by its absence permitted.
(ie: Assume good whatever isn't evil.)
Assuming you intend to permit and/or forbid a discrete subset of legal
CONTENT-TYPES and "X-" extensions to extant types, you'd best identify
which if any CHARSETS are permitted and/or forbidden, as well as which
CONTENT-TRANSFER-ENCODINGS are permitted and/or forbidden. I do wonder
how such Rule will be initially determined (one person? a committee?
consensus?) and even more so how it be maintained--which it *shall*
need to be.
I am not going to lobby for or against anything here because at day's end
you will do whatever you will do, and that's the only way you'll be happy.
All I'm advocating is clarity in terminology.
I *would* urge folks to lunge exceedingly carefully into a future that
involves rewinding their techno-clock back to yesteryear's ASCII-only
messages. I personally see little good reason to undo MIME. For one
thing, it seems a little late in the game for that. For another, I
cannot understand why a techo-group would deliberately reädopt old bugs
and limitations both long ago solved and surpassed, respectively.
Whether in the end you establish a prescriptivist subset of MIME, or whether
you outlaw it altogether, I wonder whether this won't cause more problems than
it solves. Setting tighter rules on information exchange in an environment
which was once open always unsettles my stomach.
And *that* is the ONLY wary note of caution which I shall sound for you.
I won't be lobbying, thus, whether I think it a good decision or a poor
one. Time will judge; I don't need to. So if that's what you want to do,
then that's what I'll dutifully obey--just as soon as I understand it.
I certainly have no idea what you're talking about now, though; that's
for jolly sure.
This may be a personal quirk of mine, because I can't quite voice in
clear terms why it makes me feel uncomfortably queasy. I just know
it feels uncomfortable. Maybe it's an instictive suspicion of censorship
coupled with a coëval expectation that information will naturally
autoroute itself around all such obstacles, just as it always has.
That's all.
BTW, those making their naughty-and-nice lists should pray consider:
+------------------------+
| Registered Media Types |
+------------------------+
§ http://www.iana.org/assignments/media-types/
multipart:
alternative appledouble byteranges digest encrypted example form-data
header-set mixed parallel related report signed voice-message
text:
calendar css csv directory dns ecmascript(obsolete) enriched example
html javascript(obsolete) parityfec plain RED rfc822-headers richtext
rtf rtp-enc-aescm128 rtx sgml t140 tab-separated-values troff ulpfec
uri-list xml xml-external-parsed-entity
message:
CPIM delivery-status disposition-notification example external-body
global global-delivery-status global-disposition-notification
global-headers http imdn+xml partial rfc822 s-http sip sipfrag
tracking-status
application:
3gpp-ims+xml activemessage andrew-inset applefile atomcat+xml atomicmail
atomsvc+xml atom+xml auth-policy+xml batch-SMTP beep+xml cals-1840 ccxml+xml
cea-2018+xml cellml+xml cnrp+xml commonground conference-info+xml cpl+xml
CSTAdata+xml csta+xml cybercash davmount+xml dca-rft dec-dx dialog-info+xml
dicom dns dssc+der dssc+xml dvcs ecmascript EDI-Consent EDIFACT EDI-X12
emma+xml epp+xml eshop example fits font-tdpfr H224 http hyperstudio
ibe-key-request+xml ibe-pkg-reply+xml ibe-pp-data iges im-iscomposing+xml
index iotp ipfix ipp isup javascript json kpml-request+xml kpml-response+xml
lost+xml mac-binhex40 macwriteii marc mathematica
mbms-associated-procedure-description+xml mbms-deregister+xml mbms-envelope+xml
mbms-msk-response+xml mbms-msk+xml mbms-protection-description+xml
mbms-reception-report+xml mbms-register-response+xml mbms-register+xml
mbms-user-service-description+xml mbox media_control+xml mediaservercontrol+xml
mikey mosskey-data mosskey-request moss-keys moss-signature mp21 mp4 mpeg4-generic
mpeg4-iod mpeg4-iod-xmt msword mxf nasdata nss ocsp-request ocsp-response
octet-stream oda oebps-package+xml ogg parityfec patch-ops-error+xml pdf
pgp-encrypted pgp-keys pgp-signature pidf-diff+xml pidf+xml pkcs10 pkix-cert
pkixcmp pkix-crl pkix-pkipath pls+xml poc-settings+xml postscript qsig rdf+xml
reginfo+xml relax-ng-compact-syntax remote-printing resource-lists-diff+xml
resource-lists+xml riscos rlmi+xml rls-services+xml rtf rtx samlassertion+xml
samlmetadata+xml sbml+xml scvp-cv-request scvp-cv-response scvp-vp-request
scvp-vp-response sdp set-payment set-payment-initiation set-registration
set-registration-initiation sgml sgml-open-catalog shf+xml sieve simple-filter+xml
simple-message-summary simpleSymbolContainer slate smil+xml soap+xml sparql-query
sparql-results+xml spirits-event+xml srgs srgs+xml ssml+xml timestamp-query
timestamp-reply tve-trigger ulpfec vemmi voicexml+xml watcherinfo+xml
whoispp-query whoispp-response wita wsdl+xml wspolicy+xml x400-bp xcap-att+xml
xcap-caps+xml xcap-el+xml xcap-error+xml xcap-ns+xml xenc+xml xhtml+xml xml
xml-dtd xml-external-parsed-entity xmpp+xml xop+xml xslt+xml xv+xml zip
audio: [...]
example: [...]
image: [...]
model: [...]
video: [...]
+--------------------+
| +----------------+ |
| | The "X-" files | |
| +----------------+ |
+--------------------+
§ http://www.webmaster-toolkit.com/mime-types.shtml
§ http://reference.sitepoint.com/html/mime-types-full
multipart:
x-gzip x-ustar x-zip
text:
x-asm x-audiosoft-intra x-c x-component x-fortran x-h x-java-source
x-la-asf x-m x-pascal x-script x-script.csh x-script.elisp
x-script.guile x-script.ksh x-script.lisp x-script.perl
x-script.perl-module x-script.phyton x-script.rexx x-script.scheme
x-script.sh x-script.tcl x-script.tcsh x-script.zsh x-server-parsed-html
x-setext x-sgml x-speech x-uil x-uuencode x-vcalendar
application:
x-123 x-aim x-authorware-bin x-authorware-map x-authorware-seg
x-bcpio x-binary x-binhex40 x-bsh x-bytecode.elisp (compiled elisp)
x-bytecode.python x-bzip x-bzip2 x-cdf x-cdlink x-chat x-chess-pgn
x-cmu-raster x-cocoa x-compactpro x-compress x-compressed x-conference
x-cpio x-cpt x-csh x-deepv x-director x-dvi x-elc x-envoy x-esrehber
x-excel x-frame x-freelance x-futuresplash x-gsp x-gss x-gtar x-gzip
x-hdf x-helpfile x-httpd-imap x-ima x-internett-signup x-inventor
x-ip2 x-java-class x-java-commerce x-java-jnlp-file x-javascript
x-koan x-ksh x-latex x-lha x-lisp x-livescreen x-lotus x-lotusscreencam
x-lzh x-lzx x-macbinary x-mac-binhex40 x-magic-cap-package-1.0
x-mathcad x-meme x-midi x-mif x-mix-transfer x-mplayer2 x-msexcel
x-mspowerpoint x-navi-animation x-navidoc x-navimap x-navistyle
x-netcdf x-newton-compatible-pkg x-nokia-9000-communicator-add-on-software
x-omc x-omcdatamaker x-omcregerator x-pagemaker x-pcl x-pixclscript
x-pkcs10 x-pkcs12 x-pkcs7-certificates x-pkcs7-certreqresp x-pkcs7-mime
x-pkcs7-signature x-pointplus x-portable-anymap x-project x-qpro
x-rtf x-sdp x-sea x-seelogo x-sh x-shar x-shockwave-flash x-sit
x-sprite x-stuffit x-sv4cpio x-sv4crc x-tar x-tbook x-tcl x-tex
x-texinfo x-troff x-troff-man x-troff-me x-troff-ms x-troff-msvideo
x-ustar x-visio x-vnd.audioexplosion.mzz x-vnd.ls-xpix x-vrml
x-wais-source x-winhelp x-wintalk x-world x-wpwin x-wri x-x509-ca-cert
x-x509-user-cert x-zip-compressed
--tom
\ /
*==============================*
=> OB-related Perl content <=
*==============================*
/ \
§ http://search.cpan.org/search?query=mime&mode=module
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
--
+-------------------------------------+
/| O what's the rhyme to porringer? |\
/ | Ken ye the rhyme to porringer? | \
\¯| The king he had a daughter fair |¯/
\| And gave the Prince of Orange her. |/
+-------------------------------------+
|
+------------------------------------------------------+
| There was a merry passenger, |
| a messenger, a mariner: | ()messenger<-shot
| he built a gilded gondola |
| to wander in and had in her |
| a load of yellow oranges |
| and porridge for his provender; |
| he perfumed her with marjoram, |
| and cardamom and lavender. |
+------------------------------------------------------+
More information about the LUG
mailing list