pem-dev
[Top] [All Lists]

Re: draft 1113 I-D changes for Content-Domain

1992-07-22 06:25:00
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Originator-Certificate: MIIBjjCCATgCAQIwDQYJKoZIhvcNAQECBQAwRjELM
 AkGA1UEBhMCVVMxJDAiBgNVBAoTG1RydXN0ZWQgSW5mb3JtYXRpb24gU3lzdGVtc
 zERMA8GA1UECxMIR2xlbndvb2QwHhcNOTIwNzE3MTQwNzM0WhcNOTQwNzE3MTQwN
 zM0WjBgMQswCQYDVQQGEwJVUzEkMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvb
 iBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1UEAxMPSmFtZXMgTS4gR
 2FsdmluMFowDQYJKoZIhvcNAQEBBQADSQAwRgJBAMQMw5IxCtHdZfe+oAdrm8mq9
 6RjvRfbG8I6Y903VX3ZJysXlWEDB2jYlm5aif6Pds2OdGq9DqNo5+swciLIXvECA
 QMwDQYJKoZIhvcNAQECBQADQQATTPt6kCH9064K6dlzxZRGxfPUZOGw5R4DpurJx
 +hpHf5/3SXztgusxGbhv9XU/GezmLvNQDdjwqWCp8g7VpDD
Issuer-Certificate: MIIBZTCCAQ8CAQIwDQYJKoZIhvcNAQECBQAwNzELMAkGA
 1UEBhMCVVMxKDAmBgNVBAoTH1RydXN0ZWQgSW5mb3JtYXRpb24gU3lzdGVtcyBQQ
 0EwHhcNOTIwNzE3MTMyMzI4WhcNOTQwNzE3MTMyMzI4WjBGMQswCQYDVQQGEwJVU
 zEkMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLE
 whHbGVud29vZDBaMA0GCSqGSIb3DQEBAQUAA0kAMEYCQQDE+Wmy9YJM1p+NNPBwa
 GAJWx1FvRNSTNaCa+ZgItM5x3Yl5+BFBIf/QfApcyiaOpFteindkKbryeu4WXd1v
 C6HAgEDMA0GCSqGSIb3DQEBAgUAA0EAJQZuSuHg+LJy3wCv1YRd1l0eB66UOVDfZ
 nbdG/u86flC8J/4Y+QaD7DM579sPbAF0Hv7Wv2yaMzlarafMGaibA==
MIC-Info: RSA-MD5,RSA,jGv0eBm1UyZKiiF6EEVVgBemAbRs4AVeOL1g/fgDnkt
 64z95O8cUt6QvvWaJmvF2HuO14A3NFTOaty6PCuM/bQ==

        4.6.1.2  Content-Domain Field
        
           The "Content-Domain:" encapsulated header field describes the
           type of content which is represented within a PEM message's
           encapsulated text.  It carries one string argument, values
           for which are registered in [ID1115+].  Only one
           "Content-Domain:" field occurs in a PEM message; this field
           is the PEM message's second encapsulated header field,
           immediately following the "Proc-Type:" field.

I would appreciate if someone who was at the meeting could talk about
this new header a bit more.  I am sure the thoughts I express below were
discussed at the meeting, so any clarification would be helpful.

My model of PEM is not that it carries rfc822 mail, ie its content is
not rfc822, rather that the application which uses PEM is rfc822 mail.
This is best supported by the fact that PEM expects as input an rfc822
message, it massages the body of said input message, and outputs the
same rfc822 headers with a massaged body.  This massaged body is not an
rfc822 message; it is a possibly encrypted, possibly encoded, signed
rfc822 body.

Carrying this model a step further, if the intent is that future values
for this header field are MIME and X.400, this feels like a step
backwards.  Wouldn't it be better to view PEM as a process independent
of any application, that simply massages an input stream?  I guess the
real question I'm asking is should PEM be cognizant of the application
making use of it?  I would expect MIME to make use of PEM, not PEM to
make use of MIME, for example.

Any help in understanding what happened at the meeting would be
appreciated.

Thanks,

Jim
-----END PRIVACY-ENHANCED MESSAGE-----

<Prev in Thread] Current Thread [Next in Thread>