home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / vmsnet / mail / pmdf / 2094 < prev    next >
Encoding:
Internet Message Format  |  1992-08-12  |  3.3 KB
  1. Path: sparky!uunet!olivea!decwrl!decwrl!infopiz!mccall!ipmdf-newsgate!list
  2. From: ned@sigurd.innosoft.com (Ned Freed)
  3. Newsgroups: vmsnet.mail.pmdf
  4. Subject: RE: two minor points
  5. Message-ID: <01GNI8UCQC16984MDW@SIGURD.INNOSOFT.COM>
  6. Date: 13 Aug 92 03:24:41 GMT
  7. Organization: The Internet
  8. Lines: 45
  9. Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
  10. Resent-Date: 12 Aug 1992 20:24:41 -0700 (PDT)
  11. Resent-From: epmdf@YMIR.CLAREMONT.EDU
  12. Errors-To: epmdf@YMIR.CLAREMONT.EDU
  13. Resent-Message-ID: <01GNI9F8OMB694E2YG@YMIR.CLAREMONT.EDU>
  14. X-Vms-To: IN%"KLENSIN@INFOODS.MIT.EDU"
  15. X-Vms-Cc: IPMDF
  16. Mime-Version: 1.0
  17. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  18. Content-Transfer-Encoding: 7BIT
  19.  
  20. I'm sorry, but I stand by my previous statements 100%. I used the word
  21. "recommended" here with great care. I never said this was standardized.
  22. A "recommended standard" is very very different from a simple recommendation.
  23.  
  24. The fact of the matter is that despite the fact that this document is not
  25. standards-track it was nevertheless reviewed by the working group. I don't
  26. know what you mean by "no discussion" -- I saw considerable discussion and
  27. large amounts of consensus behind this document. In my opinion this was far
  28. more than sufficient to call the document "recommended".
  29.  
  30. You can view this as the effort as the product of personal opinion and
  31. not part of the group effort if you like, but let me assure you that the
  32. implementors I've talked to don't take this view at all. There are many
  33. reasons for this: (1) The document is written by one of the MIME coauthors
  34. (not me) and thus carries considerable weight, (2) The document was a product
  35. of the working group in large part (whether you think so or not), (3) The
  36. suggestions made by the document are without exception extremely reasonable
  37. and mostly obvious, (4) The document gives many suggestions which actually
  38. will speed the deployment and implementation of MIME, (5) Many of the
  39. things in this document were put there precisely because they were issues that
  40. implementors thought should be addressed by MIME, (6) Many of the things
  41. in this document were put there because people of influence with big e-mail
  42. problems wanted them solved.
  43.  
  44. I think the choice to make this document an informational one was and is sound,
  45. but it is a hell of a lot more than the ramblings of a random individual. In
  46. the final analysis, a lot of people (implementors too) think that an RFC of
  47. any sort is a standard, and if they like it they will implement it.
  48.  
  49. There is ample historical precedence for this, incidentally. Craig Partridge's
  50. RFC on how to use the DNS when delivering mail is an informational document.
  51. However, if it weren't for the fact that every mail system of substance on
  52. the Internet implemented this "personal opinion", there wouldn't be much
  53. successful transmission of mail these days. Try implementing mail strictly
  54. from the RFCs that describe the DNS's function and use and see how far you
  55. get (I've done this so I know more than I care to about it). The RFC number
  56. is 974 in case you care to have a look.
  57.  
  58.                 Ned
  59.  
  60. P.S. I don't have a problem with this, by the way. Informational RFCs of this
  61. sort are an absolutely vital part of the process by which we implement
  62. Internet standards. They serve roughly the same purpose at all those annexes
  63. in OSI documents that "aren't part of the standard" do. You ignore these at
  64. your peril, just as you ignore certain informational RFCs at your peril.
  65.