< draft-freed-pvcsc-02.txt		draft-freed-pvcsc-03.txt >
	Network Working Group Ned Freed		Network Working Group Ned Freed
	Internet Draft Keith Moore		Internet Draft Keith Moore
	<draft-freed-pvcsc-02.txt>		<draft-freed-pvcsc-03.txt>
	MIME Parameter Value and Encoded Word Extensions:		MIME Parameter Value and Encoded Word Extensions:
	Character Sets, Languages, and Continuations		Character Sets, Languages, and Continuations
	March 1997		June 1997
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are		This document is an Internet-Draft. Internet-Drafts are
	working documents of the Internet Engineering Task Force		working documents of the Internet Engineering Task Force
	(IETF), its areas, and its working groups. Note that other		(IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-		groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	skipping to change at page 2, line ? ¶		skipping to change at page 2, line ? ¶
	by other documents at any time. It is not appropriate to use		by other documents at any time. It is not appropriate to use
	Internet-Drafts as reference material or to cite them other		Internet-Drafts as reference material or to cite them other
	than as a "working draft" or "work in progress".		than as a "working draft" or "work in progress".
	To learn the current status of any Internet-Draft, please		To learn the current status of any Internet-Draft, please
	check the 1id-abstracts.txt listing contained in the		check the 1id-abstracts.txt listing contained in the
	Internet-Drafts Shadow Directories on ds.internic.net (US East		Internet-Drafts Shadow Directories on ds.internic.net (US East
	Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast),		Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast),
	or munnari.oz.au (Pacific Rim).		or munnari.oz.au (Pacific Rim).
			The current draft of this memo reflects comments received
			during the last call period. In particular, a reference to RFC
			2119 has been added, as have some directives on how to handle
			character sets with embedded language tagging facilities.
	1. Abstract		1. Abstract
	This memo defines extensions to the RFC 2045 media type and		This memo defines extensions to the RFC 2045 media type and
	RFC CDISP disposition parameter value mechanisms to provide		RFC CDISP disposition parameter value mechanisms to provide
	(1) a means to specify parameter values in character sets		(1) a means to specify parameter values in character sets
	other than US-ASCII,		other than US-ASCII,
	(2) to specify the language to be used should the value be		(2) to specify the language to be used should the value be
	displayed, and		displayed, and
	(3) a continuation mechanism for long parameter values to		(3) a continuation mechanism for long parameter values to
	avoid problems with header line wrapping.		avoid problems with header line wrapping.
	This memo also defines an extension to the encoded words		This memo also defines an extension to the encoded words
	defined in RFC 2047 to allow the specification of the language		defined in RFC 2047 to allow the specification of the language
	to be used for display as well as the character set.		to be used for display as well as the character set.
	skipping to change at page 3, line 16 ¶		skipping to change at page 3, line 21 ¶
	appear in, are limited to 7bit US-ASCII, and the		appear in, are limited to 7bit US-ASCII, and the
	encoded-word mechanisms of RFC 2047 are not available		encoded-word mechanisms of RFC 2047 are not available
	to parameter values. This makes it impossible to have		to parameter values. This makes it impossible to have
	parameter values in character sets other than US-ASCII		parameter values in character sets other than US-ASCII
	without specifying some sort of private per-parameter		without specifying some sort of private per-parameter
	encoding.		encoding.
	(3) It has recently become clear that character set		(3) It has recently become clear that character set
	information is not sufficient to properly display some		information is not sufficient to properly display some
	sorts of information -- language information is also		sorts of information -- language information is also
	needed [RFC-IAB-CHARSETS]. For example, support for		needed [RFC-2130]. For example, support for
	handicapped users may require reading text string		handicapped users may require reading text string
	aloud. The language the text is written in is needed		aloud. The language the text is written in is needed
	for this to be done correctly. Some parameter values		for this to be done correctly. Some parameter values
	may need to be displayed, hence there is a need to		may need to be displayed, hence there is a need to
	allow for the inclusion of language information.		allow for the inclusion of language information.
	The last problem on this list is also an issue for the encoded		The last problem on this list is also an issue for the encoded
	words defined by RFC 2047, as encoded words are intended		words defined by RFC 2047, as encoded words are intended
	primarily for display purposes.		primarily for display purposes.
	skipping to change at page 3, line 39 ¶		skipping to change at page 3, line 44 ¶
	fashion that is completely compatible at a syntactic level		fashion that is completely compatible at a syntactic level
	with existing MIME implementations. In addition, the		with existing MIME implementations. In addition, the
	extensions are designed to have as little impact as possible		extensions are designed to have as little impact as possible
	on existing uses of MIME.		on existing uses of MIME.
	IMPORTANT NOTE: These mechanisms end up being somewhat		IMPORTANT NOTE: These mechanisms end up being somewhat
	gibbous when they actually are used. As such, use of these		gibbous when they actually are used. As such, use of these
	mechanisms should not be used lightly; they should be reserved		mechanisms should not be used lightly; they should be reserved
	for situations where a real need for them exists.		for situations where a real need for them exists.
			2.1. Requirements notation
			This document occasionally uses terms that appear in capital
			letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD
			NOT", and "MAY" appear capitalized, they are being used to
			indicate particular requirements of this specification. A
			discussion of the meanings of these terms appears in [RFC-
			2119].
	3. Parameter Value Continuations		3. Parameter Value Continuations
	Long MIME media type or disposition parameter values do not		Long MIME media type or disposition parameter values do not
	interact well with header line wrapping conventions. In		interact well with header line wrapping conventions. In
	particular, proper header line wrapping depends on there being		particular, proper header line wrapping depends on there being
	places where linear whitespace (LWSP) is allowed, which may or		places where linear whitespace (LWSP) is allowed, which may or
	may not be present in a parameter value, and even if present		may not be present in a parameter value, and even if present
	may not be recognizable as such since specific knowledge of		may not be recognizable as such since specific knowledge of
	parameter value syntax may not be available to the agent doing		parameter value syntax may not be available to the agent doing
	the line wrapping. The result is that long parameter values		the line wrapping. The result is that long parameter values
	may end up getting truncated or otherwise damaged by incorrect		may end up getting truncated or otherwise damaged by incorrect
	line wrapping implementations.		line wrapping implementations.
	A mechanism is therefore needed to break up parameter values		A mechanism is therefore needed to break up parameter values
	into smaller units that are amenable to line wrapping. Any		into smaller units that are amenable to line wrapping. Any
	such mechanism must be compatible with existing MIME		such mechanism MUST be compatible with existing MIME
	processors. This means that		processors. This means that
	(1) the mechanism must not change the syntax of MIME media		(1) the mechanism MUST NOT change the syntax of MIME media
	type and disposition lines, and		type and disposition lines, and
	(2) the mechanism must not depend on parameter ordering		(2) the mechanism MUST NOT depend on parameter ordering
	since MIME states that parameters are not order		since MIME states that parameters are not order
	sensitive. Note that while MIME does prohibit		sensitive. Note that while MIME does prohibit
	modification of MIME headers during transport, it is		modification of MIME headers during transport, it is
	still possible that parameters will be reordered when		still possible that parameters will be reordered when
	user agent level processing is done.		user agent level processing is done.
	The obvious solution, then, is to use multiple parameters to		The obvious solution, then, is to use multiple parameters to
	contain a single parameter value and to use some kind of		contain a single parameter value and to use some kind of
	distinguished name to indicate when this is being done. And		distinguished name to indicate when this is being done. And
	this obvious solution is exactly what is specified here: The		this obvious solution is exactly what is specified here: The
	skipping to change at page 5, line 32 ¶		skipping to change at page 6, line 4 ¶
	Specifically, an asterisk at the end of a parameter name acts		Specifically, an asterisk at the end of a parameter name acts
	as an indicator that character set and language information		as an indicator that character set and language information
	may appear at the beginning of the parameter value. A single		may appear at the beginning of the parameter value. A single
	quote is used to separate the character set, language, and		quote is used to separate the character set, language, and
	actual value information in the parameter value string, and an		actual value information in the parameter value string, and an
	percent sign is used to flag octets encoded in hexadecimal.		percent sign is used to flag octets encoded in hexadecimal.
	For example:		For example:
	Content-Type: application/x-stuff;		Content-Type: application/x-stuff;
	title*=us-ascii'en'This%20is%20%2A%2A%2Afun%2A%2A%2A		title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A
	Note that it is perfectly permissible to leave either the		Note that it is perfectly permissible to leave either the
	character set or language field blank. This is done when		character set or language field blank. Note also that the
	either character set, language, or both are not relevant to		single quote delimiters MUST be present even when one of the
	the parameter value at hand. This MUST NOT be done in order		field values is omitted. This is done when either character
	to indicate a default character set or language -- parameter		set, language, or both are not relevant to the parameter value
	field definitions MUST NOT assign a default character set or		at hand. This MUST NOT be done in order to indicate a default
	lanugage.		character set or language -- parameter field definitions MUST
			NOT assign a default character set or lanugage.
	4.1. Combining Character Set, Language, and Parameter		4.1. Combining Character Set, Language, and Parameter
	Continuations		Continuations
	Character set and language information may be combined with		Character set and language information may be combined with
	the parameter continuation mechanism. For example:		the parameter continuation mechanism. For example:
	Content-Type: application/x-stuff		Content-Type: application/x-stuff
	title*1*=us-ascii'en'This%20is%20even%20more%20		title*1*=us-ascii'en'This%20is%20even%20more%20
	title*2*=%2A%2A%2Afun%2A%2A%2A%20		title*2*=%2A%2A%2Afun%2A%2A%2A%20
	skipping to change at page 6, line 34 ¶		skipping to change at page 7, line 10 ¶
	(5) If the first segment of a continued parameter value is		(5) If the first segment of a continued parameter value is
	encoded the language and character set field delimiters		encoded the language and character set field delimiters
	MUST be present even when the fields are left blank.		MUST be present even when the fields are left blank.
	5. Language specification in Encoded Words		5. Language specification in Encoded Words
	RFC 2047 provides support for non-US-ASCII character sets in		RFC 2047 provides support for non-US-ASCII character sets in
	RFC 822 message header comments, phrases, and any unstructured		RFC 822 message header comments, phrases, and any unstructured
	text field. This is done by defining an encoded word		text field. This is done by defining an encoded word
	construct which can appear in any of these places. Given that		construct which can appear in any of these places. Given that
	these are fields intended for display, it is sometimes		these are fields intended for display, it is sometimes
	necessary to associate language information with encoded words		necessary to associate language information with encoded words
	as well as just the character set. This specification extends		as well as just the character set. This specification extends
	the definition of an encoded word to allow the inclusion of		the definition of an encoded word to allow the inclusion of
	such information. This is simply done by suffixing the		such information. This is simply done by suffixing the
	character set specification with an asterisk followed by the		character set specification with an asterisk followed by the
	language tag. For example:		language tag. For example:
	From: =?US-ASCII*EN?Q?Keith_Moore?= <moore@cs.utk.edu>		From: =?US-ASCII*EN?Q?Keith_Moore?= <moore@cs.utk.edu>
	6. IMAP4 Handling of Parameter Values		6. IMAP4 Handling of Parameter Values
	IMAP4 [RFC-1730] servers SHOULD decode parameter value		IMAP4 [RFC-2060] servers SHOULD decode parameter value
	continuations when generating the BODY and BODYSTRUCTURE fetch		continuations when generating the BODY and BODYSTRUCTURE fetch
	attributes.		attributes.
	7. Modifications to MIME ABNF		7. Modifications to MIME ABNF
	The ABNF for MIME parameter values given in RFC 2045 is:		The ABNF for MIME parameter values given in RFC 2045 is:
	parameter := attribute "=" value		parameter := attribute "=" value
	attribute := token		attribute := token
	skipping to change at page 8, line 25 ¶		skipping to change at page 8, line 43 ¶
	language := <registered language tag [RFC-1766]>		language := <registered language tag [RFC-1766]>
	The ABNF given in RFC 2047 for encoded-words is:		The ABNF given in RFC 2047 for encoded-words is:
	encoded-word := "=?" charset "?" encoding "?" encoded-text "?="		encoded-word := "=?" charset "?" encoding "?" encoded-text "?="
	This specification changes this ABNF to:		This specification changes this ABNF to:
	encoded-word := "=?" charset ["*" language] "?" encoded-text "?="		encoded-word := "=?" charset ["*" language] "?" encoded-text "?="
	8. Security Considerations		8. Character sets which allow specification of language
			In the future it is likely that some character sets will
			provide facilities for inline language labelling. Such
			facilities are inherently more flexible than those defined
			here as they allow for language switching in the middle of a
			string.
			If and when such facilities are developed they SHOULD be used
			in preference to the language labelling facilities specified
			here. Note that all the mechanisms defined here allow for the
			omission of language labels so as to be able to accomodate
			this possible future usage.
			9. Security Considerations
	This RFC does not discuss security issues and is not believed		This RFC does not discuss security issues and is not believed
	to raise any security issues not already endemic in electronic		to raise any security issues not already endemic in electronic
	mail and present in fully conforming implementations of MIME.		mail and present in fully conforming implementations of MIME.
	9. References		10. References
	[RFC-822]		[RFC-822]
	Crocker, D., "Standard for the Format of ARPA Internet		Crocker, D., "Standard for the Format of ARPA Internet
	Text Messages", RFC 822 August, 1982.		Text Messages", RFC 822 August, 1982.
	[RFC-1730]
	Crispin, M., "Internet Message Access Protocol - Version
	4", RFC 1730, December 1994.
	[RFC-1766]		[RFC-1766]
	Alvestrand, H., "Tags for the Identification of		Alvestrand, H., "Tags for the Identification of
	Languages", RFC 1766, March, 1995.		Languages", RFC 1766, March, 1995.
	[RFC-CDISP]
	Troost, R., Dorner, S., and Moore, K., "Communicating
	Presentation Information in Internet Messages: The
	Content-Disposition Header", Internet Draft, February
	1997.
	[RFC-2045]		[RFC-2045]
	Freed, N. and Borenstein, N., "Multipurpose Internet Mail		Freed, N. and Borenstein, N., "Multipurpose Internet Mail
	Extensions (MIME) Part One: Format of Internet Message		Extensions (MIME) Part One: Format of Internet Message
	Bodies", RFC 2045, Innosoft, First Virtual Holdings,		Bodies", RFC 2045, Innosoft, First Virtual Holdings,
	December 1996.		December 1996.
	[RFC-2046]		[RFC-2046]
	Freed, N. and Borenstein, N., "Multipurpose Internet Mail		Freed, N. and Borenstein, N., "Multipurpose Internet Mail
	Extensions (MIME) Part Two: Media Types", RFC 2046,		Extensions (MIME) Part Two: Media Types", RFC 2046,
	Innosoft, First Virtual Holdings, December 1996.		Innosoft, First Virtual Holdings, December 1996.
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 23 ¶
	Internet Mail Extensions (MIME) Part Four: MIME		Internet Mail Extensions (MIME) Part Four: MIME
	Registration Procedures", RFC 2048, Innosoft, MCI, ISI,		Registration Procedures", RFC 2048, Innosoft, MCI, ISI,
	December 1996.		December 1996.
	[RFC-2049]		[RFC-2049]
	Freed, N. and Borenstein, N., "Multipurpose Internet Mail		Freed, N. and Borenstein, N., "Multipurpose Internet Mail
	Extensions (MIME) Part Five: Conformance Criteria and		Extensions (MIME) Part Five: Conformance Criteria and
	Examples", RFC 2049, Innosoft, FIrst Virtual Holdings,		Examples", RFC 2049, Innosoft, FIrst Virtual Holdings,
	December 1996.		December 1996.
	[RFC-IAB-CHARSETS]		[RFC-2060]
			Crispin, M., "Internet Message Access Protocol - Version
			4rev1", RFC 2060, December 1996.
			[RFC-2119]
			Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", RFC 2119, March 1997.
			[RFC-2130]
	Weider, C., Preston, C., Simonsen, K., Alvestrand, H.,		Weider, C., Preston, C., Simonsen, K., Alvestrand, H.,
	Atkinson, R., Crispin, M., Svanberg, P., "Report from the		Atkinson, R., Crispin, M., Svanberg, P., "Report from the
	IAB Character Set Workshop", Version 3.0, November 1996.		IAB Character Set Workshop", RFC 2130, April 1997.
	10. Authors' Addresses		[RFC-CDISP]
			Troost, R., Dorner, S., and Moore, K., "Communicating
			Presentation Information in Internet Messages: The
			Content-Disposition Header", Internet Draft, February
			1997.
			11. Authors' Addresses
	Ned Freed		Ned Freed
	Innosoft International, Inc.		Innosoft International, Inc.
	1050 East Garvey Avenue South		1050 East Garvey Avenue South
	West Covina, CA 91790		West Covina, CA 91790
	USA		USA
	tel: +1 818 919 3600 fax: +1 818 919 3614		tel: +1 818 919 3600 fax: +1 818 919 3614
	email: ned@innosoft.com		email: ned@innosoft.com
	Keith Moore		Keith Moore
End of changes. 20 change blocks.
	31 lines changed or deleted		63 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/