Re: Does anyone use message/external-body?
At 9:46 PM -0800 11/14/02, Dan Kohn wrote: And so I'd ask, should this Content-Type: Message/External-body; Be replaced with: URL Eudora converts message/external-body to the appropriate URL on display. I find this handy.
Re: Does anyone use message/external-body?
At 1:17 PM -0600 11/15/02, Eric A. Hall wrote: There are just as many known problems with rendering long URLs as there are with message/external-body entities (eg, your example folded and became unusable in Mozilla). If people would only enclose URLs in angle-brackets, these problems could be avoided. - Why do so few people use angle-brackets? - Why do so few browsers permit you to paste URLs enclosed in angle-brackets?
Re: Does anyone use message/external-body?
From: Randall Gellens [EMAIL PROTECTED] ... If people would only enclose URLs in angle-brackets, these problems could be avoided. - Why do so few people use angle-brackets? - Why do so few browsers permit you to paste URLs enclosed in angle-brackets? The second question answers the first for some of us. If you want to write text containing URLs that will be useful to as many people as possible, you follow the spirit of standards even if that requires ignoring their letter. Vernon Schryver[EMAIL PROTECTED]
Re: Does anyone use message/external-body?
For the last several years, all I-Ds and RFCs publication announcements have included message/external-body attachments to provide for automated retrieval of the associated document. This causes very little distraction for those of us who prefer to use http or mailto URIs, while providing useful functionality for those using the external-body MIME type. However, this raises a question: does *anyone* use external-body in association with I-D announcements? External-body was specified in RFC 1341 in 1992, 2.5 years before URIs were first specified in RFC 1738. I suspect that the use of external-body has been almost wholly, if not completely, supplanted. Of MUAs, I think that at least mh supports the functionality, but is anyone using it? I use it all the time. I use it mostly for I-D announcements, but I also occasionally construct and send a message/external-body object myself. Ned
Re: Does anyone use message/external-body?
on 11/15/2002 4:14 PM Keith Moore wrote: However, this raises a question: does *anyone* use external-body in association with I-D announcements? Several MUAs support message/external-body, but they don't all work with the I-D announcements. Specifically, some MUAs only render the entities if a Content-Transfer-Encoding MIME header field is defined, How bizarre. You mean those MUAs can default to 7bit for other bodyparts but not for message/external-body? That's right. They aren't applying the default CTE to the entity headers inside the message/external-body entity. And that multiple implementors have made this same error? Netscape has had this problem since 3.x, and Mozilla still has it (presumably they are all the same code tree). I seem to remember others having the same problem but I can't find my testing notes. Even though fixing the MUAs would be the best fix in the long-term, adding the CTE MIME header field to these entities would at least allow more MUAs to render the entities appropriately. Since this is a mandatory header field for some entities, there is some argument that the missing CTE is the problem anyway. The RFC is quite clear that in the absence of a content-transfer-encoding field it is interpreted as 7bit. Well, yeah, I don't disagree with the default interpretation. Some argument specifically refers to those times when the docs aren't 7bit (plenty of examples of I-Ds with 8bit text, despite the rules there too), which eventually nests into ~it should always be declared. But I do think it would be an interesting experiment to add the line content-transfer-encoding: 7bit to the external body parts of those notices, just to see how many more MUAs worked with them. It makes NS/Moz usable anyway. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Does anyone use message/external-body?
I suspect that the use of external-body has been almost wholly, if not completely, supplanted. Of MUAs, I think that at least mh supports the functionality, but is anyone using it? I use mh, but I don't use message/external-body. It's not that the feature is a bad idea, it's that mh's user interface for it is too annoying to use. I'd like to know what could be done to encourage other UAs to implement it, and in a user-friendly manner. (no, using HTML tags doesn't provide the same functionality) Keith
Re: Does anyone use message/external-body?
However, this raises a question: does *anyone* use external-body in association with I-D announcements? I access new I-Ds and RFCs through the message/external-body subparts of the announcement, and I sometimes send out documents of my own (not always IETF-related) using the same mecahnism. I hope that lays your questions to rest.
Re: Does anyone use message/external-body?
on 11/14/2002 11:46 PM Dan Kohn wrote: However, this raises a question: does *anyone* use external-body in association with I-D announcements? Several MUAs support message/external-body, but they don't all work with the I-D announcements. Specifically, some MUAs only render the entities if a Content-Transfer-Encoding MIME header field is defined, and the I-Ds don't define that MIME header field with those entities. The result is that Netscape, Mozilla and some others don't render those links, meaning that the message/external-body entities cannot be used by users with the affected MUAs. This obviously limits usability. Even though fixing the MUAs would be the best fix in the long-term, adding the CTE MIME header field to these entities would at least allow more MUAs to render the entities appropriately. Since this is a mandatory header field for some entities, there is some argument that the missing CTE is the problem anyway. As to the larger question, I'm opposed to replacing the external links with URLs. There are just as many known problems with rendering long URLs as there are with message/external-body entities (eg, your example folded and became unusable in Mozilla). Besides, the IETF should eat its own dog food, and message/external-body is an important type. Now if we could just make it work with some of the popular MUAs... While we're on the topic of troublesome messages from the IETF, it's also interesting to note that the I-D submission response messages are also malformed, containing two different Subject header fields: Subject: Re: draft-ietf-crisp-lw-user-00.txt Subject: Autoreply from Internet Draft Submission Manager -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Does anyone use message/external-body?
On Fri, 2002-11-15 at 14:17, Eric A. Hall wrote: As to the larger question, I'm opposed to replacing the external links with URLs. There are just as many known problems with rendering long URLs as there are with message/external-body entities (eg, your example folded and became unusable in Mozilla). But you can put URLs into message/external-body (see RFC-2017). This would be easy for receiving MUAs to implement, since most have access to a browser one way or another; and it would be easier for users to work with, since people are accustomed to URLs by this point. Some MUAs already let you drag a link from a browser, or specify an attachment by URL; adding the option to send it as a message/external-body instead of inline would be a very small extra for users to learn. -- /\ |John Stracke | http://www.centivinc.com |HTML OK | |Principal Engineer|=| |Centiv|Simply vanished--like an old oak table.| |[EMAIL PROTECTED]|--Lord Percy, _Black Adder II_ | \/
Re: Does anyone use message/external-body?
However, this raises a question: does *anyone* use external-body in association with I-D announcements? Several MUAs support message/external-body, but they don't all work with the I-D announcements. Specifically, some MUAs only render the entities if a Content-Transfer-Encoding MIME header field is defined, How bizarre. You mean those MUAs can default to 7bit for other bodyparts but not for message/external-body? And that multiple implementors have made this same error? Even though fixing the MUAs would be the best fix in the long-term, adding the CTE MIME header field to these entities would at least allow more MUAs to render the entities appropriately. Since this is a mandatory header field for some entities, there is some argument that the missing CTE is the problem anyway. The RFC is quite clear that in the absence of a content-transfer-encoding field it is interpreted as 7bit. And while for some types it is a practical necessity (try encoding a JPEG image using only octets between 0x01-0x7f with 0x0d 0x0a pairs every 80 or so octets) as far as the MIME standards are concerned it's not mandatory for any kind of body part. Certainly it's not needed for message/external-body. But I do think it would be an interesting experiment to add the line content-transfer-encoding: 7bit to the external body parts of those notices, just to see how many more MUAs worked with them. Keith
Re: Does anyone use message/external-body?
moore I use mh, but I don't use message/external-body. It's not that moore the feature is a bad idea, it's that mh's user interface for it moore is too annoying to use. You're using MH as your MUA and you are complaining about something not having a user-friendly interface? B^) MH is modular. Write your own or use a more user-friendly and modern mailer... Don't bitch about possible new technology when you're using software that hasn't been updated in multiple years. For reference, I do use MH. I just don't bitch about its ugliness.
