Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Email-MIME-ContentType CPAN distribution.

Report information
The Basics
Id: 72207
Status: resolved
Priority: 0/
Queue: Email-MIME-ContentType

People
Owner: Nobody in particular
Requestors: crew [...] cs.stanford.edu
Cc:
AdminCc:

Bug Information
Severity: Unimportant
Broken in: 1.015
Fixed in: (no value)



Subject: keys really should be "type" and "subtype", not "discrete" and "composite"
I don't suppose anyone would want to add an option (or an alternative function or something) that would return a structure with the hash keys named properly, e.g., $data = { type => "text", subtype => "plain", attributes => { charset => "us-ascii", format => "flowed" } }; FYI, in RFC 2045 (section 5, roughly the 8th paragraph down) "discrete" and "composite" actually refer to the distinction between types that are opaque to MIME like "text" vs. types that have substructure that MIME cares about, like "multipart". I'll grant there is a bit of potential for confusion because they use the slash (/) to indicate disjunction in the syntax rules, so that while there is indeed a rule type := discrete-type / composite-type but that's a choice, not a literal slash, which would be indicated by double quotes ("/"), as in the rule a few lines further up: content := "Content-Type" ":" type "/" subtype I'll also grant that it's easy enough to work around, but, well, buh...
Subject: Re: [rt.cpan.org #72207] keys really should be "type" and "subtype", not "discrete" and "composite"
Date: Tue, 8 Nov 2011 20:08:32 -0500
To: Roger Crew via RT <bug-Email-MIME-ContentType [...] rt.cpan.org>
From: Ricardo Signes <rjbs [...] cpan.org>
* Roger Crew via RT <bug-Email-MIME-ContentType@rt.cpan.org> [2011-11-06T03:06:40] Show quoted text
> FYI, in RFC 2045 (section 5, roughly the 8th paragraph down) "discrete" > and "composite" actually refer to the distinction between types that are > opaque to MIME like "text" vs. types that have substructure that MIME > cares about, like "multipart".
Yup, isn't this dumb? We can probably do something about this. TBH, though, E-M-CT is ... not great in general. :( -- rjbs
Subject: Re: [rt.cpan.org #72207] keys really should be "type" and "subtype", not "discrete" and "composite"
Date: Wed, 9 Nov 2011 14:20:46 -0800
To: bug-Email-MIME-ContentType [...] rt.cpan.org
From: Roger Crew <crew [...] cs.stanford.edu>
Ricardo Signes via RT writes: Show quoted text
> We can probably do something about this. > TBH, though, E-M-CT is ... not great in general. :(
it was just at my threshold of "I *could* write this regexp myself, but there's a 2% chance I'd get something wrong, and I can't be the first person to be needing this, and I'm already expending too many braincells, and heywow CPAN comes through, again, yay, I'm done..." And, of course, now that I've looked at the specs again, I see that HTTP Content-Type -- which is what I'm actually trying to parse in the first place is, in fact, a DIFFERENT format from the email MIME header (the main difference being that HTTP does NOT allow RFC-822 comments whereas email/MIME does, even if this module doesn't implement that). Actually, that much *may* be worth warning about in the SYNOPSIS. Meanwhile, looking at _parse_attributes, I see other weirdness which may or may not be worth filing bugs on (up to you): 1. why does s/\s_+$// need to be done multiple times; shouldn't continuation lines have been folded in prior to calling parse_content_type(). Nor, in any case, is there EVER any requirement that there be one parameter per line. 2. why does $extract_quoted even pay attention to single quotes? NONE of the specs (822/1045/2045/2616) allows single-quoted (') strings as parameter values nor is there EVER any requirement to allow intermixed tokens and quoted stuff in values And, now that I've cannibalized a routine out of HTTP::Headers, I don't need to use this module anymore. Sigh. -- Roger Crew 206.940.5732 crew@cs.stanford.edu
I have finally addressed the embarrassing ancient discrete/composite mistake. Ugh. The rest of the parsing work will (maybe?) be sorted out in the future. This whole module needs to be better. -- rjbs