All users were logged out of Bugzilla on October 13th, 2018
text/nsmessage isn't the proper format. See jag's comment in bug 55902. Looking for the rfc on this...
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
I believe text/nsmessage is only used for drag 'n drop. The rest of mail is using text/rfc822, which is a standard type. Drag 'n drop is a private API, and to the best of my knowledge does not expose mime types anywhere outside of mozilla itself... so this is not as critical as a typical "we're not following standards" issue. Someone please correct me if I'm wrong.
adding rhp and ducarroz to the CC since they are the MIME and Mail Compose owners.
I hope you mean "message/rfc822". Can DnD not use message/rfc822 like the rest of mail? Does it require a distinct type? If this is only used internally, registering a type in the public namespace is not the Right Thing. However, if Mozilla would choke if the type "text/nsmessage" were to be used on the Internet for some other purpose, it's not the Right Thing either. One option would be to use a type in the experimental namespace; for instance, "message/x.vnd.mozilla.dnd". Another would be to avoid relying on a MIME type altogether. I imagine the first of those options would be much easier to implement; the latter can always be implemented later if it's deemed necessary.
(yes, I meant message/rfc822) We can't use message/rfc822 because the data that is being dragged is NOT the whole message - i.e. the data is not in the message/rfc822 format. We're dragging just enough information to be able to get at the message when the drop happens. I'm not actually sure what format the message is in though. If it's just a URL or URI, then we should be using text/x-moz-url or whatever we're going to call it, and we probably don't need text/nsmessage. I have a feeling that there might be something else in the string that requires us to use a seperate flavor.
So, does anything need to be done here?
silence == no. reopen if so and explain in detail...
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
Sorry I'm late. *Something* needs to be done here; what, I'm not entirely sure. First, "nsmessage" is simply inappropriate for Mozilla. Second, it is inappropriate to use a media type name in the IETF namespace for private functionality. At least we should use something in the experimental namespace; ideally we shouldn't be using something that looks like a MIME media type at all. The first step, though, is to get some concrete answers to the questions alecf's comments pose.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Okay. Reassigning to you to get those answers.
Assignee: blakeross → braden
Status: REOPENED → NEW
Given that I'm not familiar with the mail-news code and it could be a while before I can spare the cycles to look at code decorated with ns*, I may not be the most appropriate assignee. I'd imagine that a mail-news developer could address this faster and more efficiently than I, but I can accept if necessary.
oh for goodness sake, this is getting absurd. No we're changing things just for the sake of changing things. 1) there's nothing wrong with nsmessage - we use "ns" all over the codebase. 2) there's nothing wrong with using an IETF mime type - it's private, that's the point. if our data format happens to match an IETF approved mime time, there's no reason not to use it.
ns* is a problem. I thought this bug aimed to be part of the solution. I may have been mistaken. The problem with using a name in the IETF namespace--really, the problem with using something that looks like an MIME content type where a MIME content type isn't called for--is that it creates confusion. The fact that this bug report exists is the proof of that. A sensible name would eliminate confusion.
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Heh. The string "text/nsmessage" seems no longer to appear in the codebase. WORKSFORME.
Status: NEW → RESOLVED
Last Resolved: 18 years ago → 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.