home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / alt / security / pgp / 586 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  2.0 KB
  1. Xref: sparky alt.security.pgp:586 comp.mail.mime:177
  2. Newsgroups: alt.security.pgp,comp.mail.mime
  3. Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!news.cs.indiana.edu!mvanheyn@strawberry.ucs.indiana.edu
  4. From: Marc VanHeyningen <mvanheyn@whale.cs.indiana.edu>
  5. Subject: Re: pgp headers for MIME
  6. Message-ID: <1993Jan21.223119.14095@news.cs.indiana.edu>
  7. X-Quoted: 27%
  8. Organization: Computer Science Dept, Indiana University
  9. References: <C18C4r.6K8@wizzy.com>
  10. Date: Thu, 21 Jan 1993 22:31:11 -0500
  11. Lines: 38
  12.  
  13. Thus said andyr@wizzy.com (Andy Rabagliati):
  14. >TW> I think pgp data should go so:
  15. >TW> 
  16. >TW> Content-Type: text/plain; charset=ISO-8859-1
  17. >TW> Content-transfer-encoding: X-PGP-{VERSION}
  18. >TW> 
  19. >TW> Where {VERSION} would be: 2.0, 2.1, etc...
  20. >TW> 
  21. >TW> This would allow the benefit of transferring text, sounds,
  22. >TW> graphics, etc...
  23.  
  24. Quoting from RFC 1341:
  25.  
  26.             However, unlike Content-Types and subtypes, the creation  of
  27.             new   Content-Transfer-Encoding  values  is  explicitly  and
  28.             strongly  discouraged,  as  it  seems   likely   to   hinder
  29.             interoperability  with  little potential benefit.  Their use
  30.             is allowed only  as  the  result  of  an  agreement  between
  31.             cooperating user agents.
  32.  
  33. What's wrong with merely using a new Content-Type, something like
  34. application/x-pgp or message/x-pgp, and having an encapsulated
  35. Content-Type: contain the actual variety of data?
  36.  
  37. Or, you could model it after the MIME-PEM standard, and make a
  38. multipart/x-pgp type.  That would be the ideal solution, but it's only
  39. worth doing if you thing PGP's current mechanism for message
  40. formatting will really become the (or at least a) long-term standard.
  41.  
  42. Including version is a good idea, but it doesn't need to be part of
  43. the subtype, you can just throw in version=2.1.
  44.  
  45. Creating a new Content-Transfer-Encoding is a very bad idea.
  46. -- 
  47. Marc VanHeyningen    mvanheyn@whale.cs.indiana.edu    MIME & RIPEM accepted
  48.  
  49. What's the use of a good quotation if you can't change it?
  50.         - Doctor Who
  51.