rfc9580v11.txt		rfc9580.txt
	skipping to change at line 3869 ¶		skipping to change at line 3869 ¶
	implementation.		implementation.
	Trust packets SHOULD NOT be emitted to output streams that are		Trust packets SHOULD NOT be emitted to output streams that are
	transferred to other users, and they SHOULD be ignored on any input		transferred to other users, and they SHOULD be ignored on any input
	other than local keyring files.		other than local keyring files.
	5.11. User ID Packet (Type ID 13)		5.11. User ID Packet (Type ID 13)
	A User ID packet consists of UTF-8 text that is intended to represent		A User ID packet consists of UTF-8 text that is intended to represent
	the name and email address of the keyholder. By convention, it		the name and email address of the keyholder. By convention, it
	includes a mail name-addr as described in [RFC5322], but there are no		includes a mail name-addr as described in [RFC2822], but there are no
	restrictions on its content. The packet length in the header		restrictions on its content. The packet length in the header
	specifies the length of the User ID.		specifies the length of the User ID.
	5.12. User Attribute Packet (Type ID 17)		5.12. User Attribute Packet (Type ID 17)
	The User Attribute packet is a variation of the User ID packet. It		The User Attribute packet is a variation of the User ID packet. It
	is capable of storing more types of data than the User ID packet,		is capable of storing more types of data than the User ID packet,
	which is limited to text. Like the User ID packet, a User Attribute		which is limited to text. Like the User ID packet, a User Attribute
	packet may be certified by the key owner ("self-signed") or any other		packet may be certified by the key owner ("self-signed") or any other
	key owner who cares to certify it. Except as noted, a User Attribute		key owner who cares to certify it. Except as noted, a User Attribute
	skipping to change at line 4433 ¶		skipping to change at line 4433 ¶
	version used to encode the message. To minimize metadata,		version used to encode the message. To minimize metadata,
	implementations SHOULD NOT emit this key and its corresponding value		implementations SHOULD NOT emit this key and its corresponding value
	except for debugging purposes with explicit user consent.		except for debugging purposes with explicit user consent.
	6.2.2.2. "Comment" Armor Header		6.2.2.2. "Comment" Armor Header
	The Armor Header Key Comment supplies a user-defined comment.		The Armor Header Key Comment supplies a user-defined comment.
	OpenPGP defines all text to be in UTF-8. A comment may be any UTF-8		OpenPGP defines all text to be in UTF-8. A comment may be any UTF-8
	string. However, the whole point of armoring is to provide 7-bit		string. However, the whole point of armoring is to provide 7-bit
	clean data. Consequently, if a comment has characters that are		clean data. Consequently, if a comment has characters that are
	outside the ASCII range of UTF, they may very well not survive		outside the ASCII range of UTF-8, they may very well not survive
	transport.		transport.
	6.2.2.3. "Hash" Armor Header		6.2.2.3. "Hash" Armor Header
	The Armor Header Key Hash is deprecated, but some older		The Armor Header Key Hash is deprecated, but some older
	implementations expect it in messages using the Cleartext Signature		implementations expect it in messages using the Cleartext Signature
	Framework (Section 7). When present, this Armor Header Key contains		Framework (Section 7). When present, this Armor Header Key contains
	a comma-separated list of hash algorithms used in the signatures on		a comma-separated list of hash algorithms used in the signatures on
	message, with digest names as specified in the "Text Name" column in		message, with digest names as specified in the "Text Name" column in
	Table 23. These headers SHOULD NOT be emitted unless:		Table 23. These headers SHOULD NOT be emitted unless:
	skipping to change at line 7184 ¶		skipping to change at line 7184 ¶
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144,		[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144,
	DOI 10.17487/RFC2144, May 1997,		DOI 10.17487/RFC2144, May 1997,
	<https://www.rfc-editor.org/info/rfc2144>.		<https://www.rfc-editor.org/info/rfc2144>.
			[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
			DOI 10.17487/RFC2822, April 2001,
			<https://www.rfc-editor.org/info/rfc2822>.
	[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,		[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
	"MIME Security with OpenPGP", RFC 3156,		"MIME Security with OpenPGP", RFC 3156,
	DOI 10.17487/RFC3156, August 2001,		DOI 10.17487/RFC3156, August 2001,
	<https://www.rfc-editor.org/info/rfc3156>.		<https://www.rfc-editor.org/info/rfc3156>.
	[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard		[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
	(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,		(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
	September 2002, <https://www.rfc-editor.org/info/rfc3394>.		September 2002, <https://www.rfc-editor.org/info/rfc3394>.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
End of changes. 3 change blocks.
	2 lines changed or deleted		6 lines changed or added
This html diff was produced by rfcdiff 1.48.