- From: Joseph Reagle <reagle@w3.org>
- Date: Fri, 24 May 2002 16:34:23 -0400
- To: Arjun Ray <aray@nyct.net>, xml-encryption@w3.org
On Friday 24 May 2002 14:39, Arjun Ray wrote: > Joseph Reagle <reagle@w3.org> wrote: > | I've attached a draft of an ietf-draft for a application/xenc+xml media > | type registration. > > Why a Content-Type and not a Content-Transfer-Encoding? An "XENC > application" is likely to be a helper or a filter, no? Arjun, the simple answer is because I'm a media-type newbie and following [1] and some examples, I don't see any indication a Content-Transfer-Encoding should be specified as part of the application. I note [2], but I expect any application that is sending XML over 7bit lines will do whatever is necessary...? What are you suggesting? [1] http://ietf.org/rfc//rfc2048.txt [2] http://ietf.org/rfc/rfc2045.txt 6. Content-Transfer-Encoding Header Field Many media types which could be usefully transported via email are represented, in their "natural" format, as 8bit character or binary data. Such data cannot be transmitted over some transfer protocols. For example, RFC 821 (SMTP) restricts mail messages to 7bit US-ASCII data with lines no longer than 1000 characters including any trailing CRLF line separator. It is necessary, therefore, to define a standard mechanism for encoding such data into a 7bit short line format. Proper labelling of unencoded material in less restrictive formats for direct use over less restrictive transports is also desireable. This document specifies that such encodings will be indicated by a new "Content- Transfer-Encoding" header field. This field has not been defined by any previous standard. -- Joseph Reagle Jr. http://www.w3.org/People/Reagle/ W3C Policy Analyst mailto:reagle@w3.org IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature/ W3C XML Encryption Chair http://www.w3.org/Encryption/2001/
Received on Friday, 24 May 2002 16:34:54 UTC