draft-ietf-mmusic-sap-v2-06.txt		rfc2974.txt
	Mark Handley
	ACIRI
	Colin Perkins
	UCL
	Edmund Whelan
	UCL
	Session Announcement Protocol		Network Working Group M. Handley
	draft-ietf-mmusic-sap-v2-06.txt		Request for Comments: 2974 ACIRI
			Category: Experimental C. Perkins
	Status of this memo		USC/ISI
			E. Whelan
	This document is an Internet-Draft and is in full conformance with		UCL
	all provisions of Section 10 of RFC2026.		October 2000
	Internet-Drafts are working documents of the Internet Engineering		Session Announcement Protocol
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Status of this Memo
	and may be updated, replaced, or obsoleted by other documents at
	any time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		This memo defines an Experimental Protocol for the Internet
	http://www.ietf.org/ietf/1id-abstracts.txt		community. It does not specify an Internet standard of any kind.
			Discussion and suggestions for improvement are requested.
			Distribution of this memo is unlimited.
	The list of Internet-Draft Shadow Directories can be accessed at		Copyright Notice
	http://www.ietf.org/shadow.html.
	This document is a product of the Multiparty Multimedia Session Control		Copyright (C) The Internet Society (2000). All Rights Reserved.
	working group of the Internet Engineering Task Force. Comments are
	solicited and should be addressed to the working group's mailing list at
	confctrl@isi.edu and/or the authors.
	Abstract		Abstract
	This document describes version 2 of the multicast session		This document describes version 2 of the multicast session directory
	directory announcement protocol, SAP, and the related issues		announcement protocol, Session Announcement Protocol (SAP), and the
	affecting security and scalability that should be taken		related issues affecting security and scalability that should be
	into account by implementors.		taken into account by implementors.
	1 Introduction		1 Introduction
	In order to assist the advertisement of multicast multimedia conferences		In order to assist the advertisement of multicast multimedia
	and other multicast sessions, and to communicate the relevant session		conferences and other multicast sessions, and to communicate the
	setup information to prospective participants, a distributed session		relevant session setup information to prospective participants, a
	directory may be used. An instance of such a session directory periodically		distributed session directory may be used. An instance of such a
	multicasts packets containing a description of the session, and these		session directory periodically multicasts packets containing a
	advertisements are received by other session directories such that		description of the session, and these advertisements are received by
	potential remote participants can use the session description to start		other session directories such that potential remote participants can
	the tools required to participate in the session.		use the session description to start the tools required to
			participate in the session.
	This memo describes the issues involved in the multicast announcement		This memo describes the issues involved in the multicast announcement
	of session description information and defines an announcement protocol		of session description information and defines an announcement
	to be used. Sessions are described using the session description		protocol to be used. Sessions are described using the session
	protocol which is described in a companion memo [4].		description protocol which is described in a companion memo [4].
	2 Terminology		2 Terminology
	A SAP announcer periodically multicasts an announcement packet to a well		A SAP announcer periodically multicasts an announcement packet to a
	known multicast address and port. The announcement is multicast with the		well known multicast address and port. The announcement is multicast
	same scope as the session it is announcing, ensuring that the recipients of		with the same scope as the session it is announcing, ensuring that
	the announcement are within the scope of the session the announcement		the recipients of the announcement are within the scope of the
	describes (bandwidth and other such constraints permitting). This is also		session the announcement describes (bandwidth and other such
	important for the scalability of the protocol, as it keeps local session		constraints permitting). This is also important for the scalability
	announcements local.		of the protocol, as it keeps local session announcements local.
	A SAP listener learns of the multicast scopes it is within (for example,		A SAP listener learns of the multicast scopes it is within (for
	using the Multicast-Scope Zone Announcement Protocol [5]) and listens on		example, using the Multicast-Scope Zone Announcement Protocol [5])
	the well known SAP address and port for those scopes. In this manner, it		and listens on the well known SAP address and port for those scopes.
	will eventually learn of all the sessions being announced, allowing those		In this manner, it will eventually learn of all the sessions being
	sessions to be joined.		announced, allowing those sessions to be joined.
	The key words `MUST', `MUST NOT', `REQUIRED', `SHALL', `SHALL NOT',		The key words `MUST', `MUST NOT', `REQUIRED', `SHALL', `SHALL NOT',
	`SHOULD', `SHOULD NOT', `RECOMMENDED', `MAY', and `OPTIONAL' in this		`SHOULD', `SHOULD NOT', `RECOMMENDED', `MAY', and `OPTIONAL' in this
	document are to be interpreted as described in [1].		document are to be interpreted as described in [1].
	3 Session Announcement		3 Session Announcement
	As noted previously, a SAP announcer periodically sends an announcement		As noted previously, a SAP announcer periodically sends an
	packet to a well known multicast address and port. There is no rendezvous		announcement packet to a well known multicast address and port.
	mechanism - the SAP announcer is not aware of the presence or absence of		There is no rendezvous mechanism - the SAP announcer is not aware of
	any SAP listeners - and no additional reliability is provided over the		the presence or absence of any SAP listeners - and no additional
	standard best-effort UDP/IP semantics.		reliability is provided over the standard best-effort UDP/IP
			semantics.
	That announcement contains a session description and SHOULD contain		That announcement contains a session description and SHOULD contain
	an authentication header. The session description MAY be encrypted		an authentication header. The session description MAY be encrypted
	although this is NOT RECOMMENDED (see section 7).		although this is NOT RECOMMENDED (see section 7).
	A SAP announcement is multicast with the same scope as the session		A SAP announcement is multicast with the same scope as the session it
	it is announcing, ensuring that the recipients of the announcement		is announcing, ensuring that the recipients of the announcement are
	are within the scope of the session the announcement describes.		within the scope of the session the announcement describes. There are
	There are a number of possiblities:		a number of possibilities:
	IPv4 global scope sessions use multicast addresses in the range		IPv4 global scope sessions use multicast addresses in the range
	224.2.128.0 - 224.2.255.255 with SAP announcements being sent		224.2.128.0 - 224.2.255.255 with SAP announcements being sent to
	to 224.2.127.254 (note that 224.2.127.255 is used by the obsolete		224.2.127.254 (note that 224.2.127.255 is used by the obsolete
	SAPv0 and MUST NOT be used).		SAPv0 and MUST NOT be used).
	IPv4 administrative scope sessions using administratively scoped		IPv4 administrative scope sessions using administratively scoped IP
	IP multicast as defined in [7]. The multicast address to be		multicast as defined in [7]. The multicast address to be used for
	used for announcements is the highest multicast address in the		announcements is the highest multicast address in the relevant
	relevant administrative scope zone. For example, if the scope		administrative scope zone. For example, if the scope range is
	range is 239.16.32.0 - 239.16.33.255, then 239.16.33.255 is used		239.16.32.0 - 239.16.33.255, then 239.16.33.255 is used for SAP
	for SAP announcements.		announcements.
	IPv6 sessions are announced on the address FF0X:0:0:0:0:0:2:7FFE		IPv6 sessions are announced on the address FF0X:0:0:0:0:0:2:7FFE
	where X is the 4-bit scope value. For example, an announcement		where X is the 4-bit scope value. For example, an announcement
	for a link-local session assigned the address FF02:0:0:0:0:0:1234:5678,		for a link-local session assigned the address
	should be advertised on SAP address FF02:0:0:0:0:0:2:7FFE.		FF02:0:0:0:0:0:1234:5678, should be advertised on SAP address
			FF02:0:0:0:0:0:2:7FFE.
	Ensuring that a description is not used by a potential participant		Ensuring that a description is not used by a potential participant
	outside the session scope is not addressed in this memo.		outside the session scope is not addressed in this memo.
	SAP announcements MUST be sent on port 9875 and SHOULD be sent with		SAP announcements MUST be sent on port 9875 and SHOULD be sent with
	an IP time-to-live of 255 (the use of TTL scoping for multicast is		an IP time-to-live of 255 (the use of TTL scoping for multicast is
	discouraged [7]).		discouraged [7]).
	If a session uses addresses in multiple administrative scope ranges,		If a session uses addresses in multiple administrative scope ranges,
	it is necessary for the announcer to send identical copies of the		it is necessary for the announcer to send identical copies of the
	announcement to each administrative scope range. It is up to the		announcement to each administrative scope range. It is up to the
	listeners to parse such multiple announcements as the same session		listeners to parse such multiple announcements as the same session
	(as identified by the SDP origin field, for example). The announcement		(as identified by the SDP origin field, for example). The
	rate for each administrative scope range MUST be calculated separately,		announcement rate for each administrative scope range MUST be
	as if the multiple announcements were separate.		calculated separately, as if the multiple announcements were
			separate.
	Multiple announcers may announce a single session, as an aid to robustness		Multiple announcers may announce a single session, as an aid to
	in the face of packet loss and failure of one or more announcers. The rate		robustness in the face of packet loss and failure of one or more
	at which each announcer repeats its announcement MUST be scaled back such		announcers. The rate at which each announcer repeats its
	that the total announcement rate is equal to that which a single server		announcement MUST be scaled back such that the total announcement
	would choose. Announcements made in this manner MUST be identical.		rate is equal to that which a single server would choose.
			Announcements made in this manner MUST be identical.
	If multiple announcements are being made for a session, then each		If multiple announcements are being made for a session, then each
	announcement MUST carry an authentication header signed by the same		announcement MUST carry an authentication header signed by the same
	key, or be treated as a completely separate announcement by listeners.		key, or be treated as a completely separate announcement by
			listeners.
	An IPv4 SAP listener SHOULD listen on the IPv4 global scope SAP address and		An IPv4 SAP listener SHOULD listen on the IPv4 global scope SAP
	on the SAP addresses for each IPv4 administrative scope zone it is within.		address and on the SAP addresses for each IPv4 administrative scope
	The discovery of administrative scope zones is outside the scope of this		zone it is within. The discovery of administrative scope zones is
	memo, but it is assumed that each SAP listener within a particular scope		outside the scope of this memo, but it is assumed that each SAP
	zone is aware of that scope zone. A SAP listener which supports IPv6		listener within a particular scope zone is aware of that scope zone.
	SHOULD also listen to the IPv6 SAP addresses.		A SAP listener which supports IPv6 SHOULD also listen to the IPv6 SAP
			addresses.
	3.1 Announcement Interval		3.1 Announcement Interval
	The time period between repetitions of an announcement is chosen		The time period between repetitions of an announcement is chosen such
	such that the total bandwidth used by all announcements on a single		that the total bandwidth used by all announcements on a single SAP
	SAP group remains below a preconfigured limit. If not otherwise		group remains below a preconfigured limit. If not otherwise
	specified, the bandwidth limit SHOULD be assumed to be 4000 bits		specified, the bandwidth limit SHOULD be assumed to be 4000 bits per
	per second.		second.
	Each announcer is expected to listen to other announcements in order		Each announcer is expected to listen to other announcements in order
	to determine the total number of sessions being announced on a particular		to determine the total number of sessions being announced on a
	group. Sessions are uniquely identified by the combination of the		particular group. Sessions are uniquely identified by the
	message identifier hash and originating source fields of the SAP		combination of the message identifier hash and originating source
	header (note that SAP v0 announcers always set the message identifier		fields of the SAP header (note that SAP v0 announcers always set the
	hash to zero, and if such an announcement is received the entire		message identifier hash to zero, and if such an announcement is
	message MUST be compared to determine uniqueness).		received the entire message MUST be compared to determine
			uniqueness).
	Announcements are made by periodic multicast to the group. The base		Announcements are made by periodic multicast to the group. The base
	interval between announcements is derived from the number of announcements		interval between announcements is derived from the number of
	being made in that group, the size of the announcement and the configured		announcements being made in that group, the size of the announcement
	bandwidth limit. The actual transmission time is derived from this		and the configured bandwidth limit. The actual transmission time is
	base interval as follows:		derived from this base interval as follows:
	1.The announcer initialises the variable tp to be the last time		1. The announcer initializes the variable tp to be the last time a
	a particular announcement was transmitted (or the current time		particular announcement was transmitted (or the current time if
	if this is the first time this announcement is to be made).		this is the first time this announcement is to be made).
	2.Given a configured bandwidth limit in bits/second and an announcement		2. Given a configured bandwidth limit in bits/second and an
	of ad_size bytes, the base announcement interval in seconds is		announcement of ad_size bytes, the base announcement interval
			in seconds is
	interval =max(300; (8*no_of_ads*ad_size)/limit)		interval =max(300; (8*no_of_ads*ad_size)/limit)
	3.An offset is calculated based on the base announcement interval		3. An offset is calculated based on the base announcement interval
	offset= rand(interval* 2/3)-(interval/3)		offset= rand(interval* 2/3)-(interval/3)
	4.The next transmission time for an announcement derived as		4. The next transmission time for an announcement derived as
	tn =tp+ interval+ offset		tn =tp+ interval+ offset
	The announcer then sets a timer to expire at tn and waits. At time		The announcer then sets a timer to expire at tn and waits. At time
	tn the announcer SHOULD recalculate the next transmission time. If		tn the announcer SHOULD recalculate the next transmission time. If
	the new value of tn is before the current time, the announcement		the new value of tn is before the current time, the announcement is
	is sent immediately. Otherwise the transmission is rescheduled for		sent immediately. Otherwise the transmission is rescheduled for the
	the new tn. This reconsideration prevents transient packet bursts		new tn. This reconsideration prevents transient packet bursts on
	on startup and when a network partition heals.		startup and when a network partition heals.
	4 Session Deletion		4 Session Deletion
	Sessions may be deleted in one of several ways:		Sessions may be deleted in one of several ways:
	Explicit Timeout The session description payload may contain timestamp		Explicit Timeout The session description payload may contain
	information specifying the start- and end-times of the session.		timestamp information specifying the start- and end-times of the
	If the current time is later than the end-time of the session,		session. If the current time is later than the end-time of the
	then the session SHOULD be deleted from the receiver's session		session, then the session SHOULD be deleted from the receiver's
	cache.		session cache.
	Implicit Timeout A session announcement message should be received		Implicit Timeout A session announcement message should be received
	periodically for each session description in a receiver's session		periodically for each session description in a receiver's session
	cache. The announcement period can be predicted by the receiver		cache. The announcement period can be predicted by the receiver
	from the set of sessions currently being announced. If a session		from the set of sessions currently being announced. If a session
	announcement message has not been received for ten times the		announcement message has not been received for ten times the
	announcement period, or one hour, whichever is the greater, then		announcement period, or one hour, whichever is the greater, then
	the session is deleted from the receiver's session cache. The		the session is deleted from the receiver's session cache. The one
	one hour minimum is to allow for transient network partitionings.		hour minimum is to allow for transient network partitionings.
	Explicit Deletion A session deletion packet is received specifying		Explicit Deletion A session deletion packet is received specifying
	the session to be deleted. Session deletion packets SHOULD have		the session to be deleted. Session deletion packets SHOULD have a
	a valid authentication header, matching that used to authenticate		valid authentication header, matching that used to authenticate
	previous announcement packets. If this authentication is missing,		previous announcement packets. If this authentication is missing,
	the deletion message SHOULD be ignored.		the deletion message SHOULD be ignored.
	5 Session Modification		5 Session Modification
	A pre-announced session can be modified by simply announcing the modified		A pre-announced session can be modified by simply announcing the
	session description. In this case, the version hash in the SAP header MUST		modified session description. In this case, the version hash in the
	be changed to indicate to receivers that the packet contents should be		SAP header MUST be changed to indicate to receivers that the packet
	parsed (or decrypted and parsed if it is encrypted). The session itself,		contents should be parsed (or decrypted and parsed if it is
	as distinct from the session announcement, is uniquely identified by the		encrypted). The session itself, as distinct from the session
	payload and not by the message identifier hash in the header.		announcement, is uniquely identified by the payload and not by the
			message identifier hash in the header.
	The same rules apply for session modification as for session deletion:		The same rules apply for session modification as for session
			deletion:
	o Either the modified announcement must contain an authentication		o Either the modified announcement must contain an authentication
	header signed by the same key as the cached session announcement		header signed by the same key as the cached session announcement
	it is modifying, or:		it is modifying, or:
	o The cached session announcement must not contain an authentication		o The cached session announcement must not contain an authentication
	header, and the session modification announcement must originate		header, and the session modification announcement must originate
	from the same host as the session it is modifying.		from the same host as the session it is modifying.
	If an announcement is received containing an authentication header		If an announcement is received containing an authentication header
	and the cached announcement did not contain an authentication header,		and the cached announcement did not contain an authentication header,
	or it contained a different authentication header, then the modified		or it contained a different authentication header, then the modified
	announcement MUST be treated as a new and different announcement,		announcement MUST be treated as a new and different announcement, and
	and displayed in addition to the un-authenticated announcement. The		displayed in addition to the un-authenticated announcement. The same
	same should happen if a modified packet without an authentication		should happen if a modified packet without an authentication header
	header is received from a different source than the original announcement.		is received from a different source than the original announcement.
	0 1 2 3		These rules prevent an announcement having an authentication header
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		added by a malicious user and then being deleted using that header,
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		and it also prevents a denial-of-service attack by someone putting
	| V=1 |A|R|T|E|C| auth len | msg id hash |		out a spoof announcement which, due to packet loss, reaches some
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		participants before the original announcement. Note that under such
	| |		circumstances, being able to authenticate the message originator is
	: originating source (32 or 128 bits) :		the only way to discover which session is the correct session.
	: :
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| optional authentication data |
	: .... :
	*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
	| optional payload type |
	+ +-+- - - - - - - - - -+
	| |0| |
	+ - - - - - - - - - - - - - - - - - - - - +-+ |
	| |
	: payload :
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Packet format		0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| V=1 |A|R|T|E|C| auth len | msg id hash |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			: originating source (32 or 128 bits) :
			: :
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| optional authentication data |
			: .... :
			*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
			| optional payload type |
			+ +-+- - - - - - - - - -+
			| |0| |
			+ - - - - - - - - - - - - - - - - - - - - +-+ |
			| |
			: payload :
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	These rules prevent an announcement having an authentication header		Figure 1: Packet format
	added by a malicious user and then being deleted using that header,
	and it also prevents a denial-of-service attack by someone putting
	out a spoof announcement which, due to packet loss, reaches some
	participants before the original announcement. Note that under such
	circumstances, being able to authenticate the message originator is
	the only way to discover which session is the correct session.
	6 Packet Format		6 Packet Format
	SAP data packets have the format described in figure 1.		SAP data packets have the format described in figure 1.
	V: Version Number. The version number field MUST be set to 1 (SAPv2		V: Version Number. The version number field MUST be set to 1 (SAPv2
	announcements which use only SAPv1 features are backwards compatible,		announcements which use only SAPv1 features are backwards
	those which use new features can be detected by other means,		compatible, those which use new features can be detected by other
	so the SAP version number doesn't need to change).		means, so the SAP version number doesn't need to change).
	A: Address type. If the A bit is 0, the originating source field		A: Address type. If the A bit is 0, the originating source field
	contains a 32-bit IPv4 address. If the A bit is 1, the originating		contains a 32-bit IPv4 address. If the A bit is 1, the
	source contains a 128-bit IPv6 address.		originating source contains a 128-bit IPv6 address.
	R: Reserved. SAP announcers MUST set this to 0, SAP listeners MUST		R: Reserved. SAP announcers MUST set this to 0, SAP listeners MUST
	ignore the contents of this field.		ignore the contents of this field.
	T: Message Type. If the T field is set to 0 this is a session announcement		T: Message Type. If the T field is set to 0 this is a session
	packet, if 1 this is a session deletion packet.		announcement packet, if 1 this is a session deletion packet.
	E: Encryption Bit. If the encryption bit is set to 1, the payload		E: Encryption Bit. If the encryption bit is set to 1, the payload of
	of the SAP packet is encrypted. If this bit is 0 the packet		the SAP packet is encrypted. If this bit is 0 the packet is not
	is not encrypted. See section 7 for details of the encryption		encrypted. See section 7 for details of the encryption process.
	process.
	C: Compressed bit. If the compressed bit is set to 1, the payload		C: Compressed bit. If the compressed bit is set to 1, the payload is
	is compressed using the zlib compression algorithm [3]. If the		compressed using the zlib compression algorithm [3]. If the
	payload is to be compressed and encrypted, the compression MUST		payload is to be compressed and encrypted, the compression MUST be
	be performed first.		performed first.
	Authentication Length. An 8 bit unsigned quantity giving the number		Authentication Length. An 8 bit unsigned quantity giving the number
	of 32 bit words following the main SAP header that contain		of 32 bit words following the main SAP header that contain
	authentication data. If it is zero, no authentication header		authentication data. If it is zero, no authentication header is
	is present.		present.
	Authentication data containing a digital signature of the packet,		Authentication data containing a digital signature of the packet,
	with length as specified by the authentication length header		with length as specified by the authentication length header
	field. See section 8 for details of the authentication process.		field. See section 8 for details of the authentication process.
	Message Identifier Hash. A 16 bit quantity that, used in combination		Message Identifier Hash. A 16 bit quantity that, used in combination
	with the originating source, provides a globally unique identifier		with the originating source, provides a globally unique identifier
	indicating the precise version of this announcement. The choice		indicating the precise version of this announcement. The choice
	of value for this field is not specified here, except that it		of value for this field is not specified here, except that it MUST
	MUST be unique for each session announced by a particular SAP		be unique for each session announced by a particular SAP announcer
	announcer and it MUST be changed if the session description is		and it MUST be changed if the session description is modified (and
	modified (and a session deletion message SHOULD be sent for the		a session deletion message SHOULD be sent for the old version of
	old version of the session).		the session).
	Earlier versions of SAP used a value of zero to mean that the		Earlier versions of SAP used a value of zero to mean that the hash
	hash should be ignored and the payload should always be parsed.		should be ignored and the payload should always be parsed. This
	This had the unfortunate side-effect that SAP announcers had		had the unfortunate side-effect that SAP announcers had to study
	to study the payload data to determine how many unique sessions		the payload data to determine how many unique sessions were being
	were being advertised, making the calculation of the announcement		advertised, making the calculation of the announcement interval
	interval more complex that necessary. In order to decouple the		more complex that necessary. In order to decouple the session
	session announcement process from the contents of those announcements,		announcement process from the contents of those announcements, SAP
	SAP announcers SHOULD NOT set the message identifier hash to zero.		announcers SHOULD NOT set the message identifier hash to zero.
	SAP listeners MAY silently discard messages if the message identifier		SAP listeners MAY silently discard messages if the message
	hash is set to zero.		identifier hash is set to zero.
	Originating Source. This gives the IP address of the original source		Originating Source. This gives the IP address of the original source
	of the message. This is an IPv4 address if the A field is set		of the message. This is an IPv4 address if the A field is set to
	to zero, else it is an IPv6 address. The address is stored		zero, else it is an IPv6 address. The address is stored in
	in network byte order.		network byte order.
	SAPv0 permitted the originating source to be zero if the message		SAPv0 permitted the originating source to be zero if the message
	identifier hash was also zero. This practise is no longer legal,		identifier hash was also zero. This practise is no longer legal,
	and SAP announcers SHOULD NOT set the originating source to zero.		and SAP announcers SHOULD NOT set the originating source to zero.
	SAP listeners MAY silently discard packets with the originating		SAP listeners MAY silently discard packets with the originating
	source set to zero.		source set to zero.
	The header is followed by an optional payload type field and the		The header is followed by an optional payload type field and the
	payload data itself. If the E or C bits are set in the header both		payload data itself. If the E or C bits are set in the header both
	the payload type and payload are encrypted and/or compressed.		the payload type and payload are encrypted and/or compressed.
	The payload type field is a MIME content type specifier, describing the		The payload type field is a MIME content type specifier, describing
	format of the payload. This is a variable length ASCII text string,		the format of the payload. This is a variable length ASCII text
	followed by a single zero byte (ASCII NUL). The payload type SHOULD be		string, followed by a single zero byte (ASCII NUL). The payload type
	included in all packets. If the payload type is `application/sdp' both the		SHOULD be included in all packets. If the payload type is
	payload type and its terminating zero byte MAY be omitted, although this is		`application/sdp' both the payload type and its terminating zero byte
	intended for backwards compatibility with SAP v1 listeners only.		MAY be omitted, although this is intended for backwards compatibility
			with SAP v1 listeners only.
	The absence of a payload type field may be noted since the payload		The absence of a payload type field may be noted since the payload
	section of such a packet will start with an SDP `v=0' field, which		section of such a packet will start with an SDP `v=0' field, which is
	is not a legal MIME content type specifier.		not a legal MIME content type specifier.
	All implementations MUST support payloads of type `application/sdp'		All implementations MUST support payloads of type `application/sdp'
	[4]. Other formats MAY be supported although since there is no negotiation		[4]. Other formats MAY be supported although since there is no
	in SAP an announcer which chooses to use a session description format		negotiation in SAP an announcer which chooses to use a session
	other than SDP cannot know that the listeners are able to understand		description format other than SDP cannot know that the listeners are
	the announcement. A proliferation of payload types in announcements		able to understand the announcement. A proliferation of payload
	has the potential to lead to severe interoperability problems, and		types in announcements has the potential to lead to severe
	for this reason, the use of non-SDP payloads is NOT RECOMMENDED.		interoperability problems, and for this reason, the use of non-SDP
			payloads is NOT RECOMMENDED.
	If the packet is an announcement packet, the payload contains a session		If the packet is an announcement packet, the payload contains a
	description.		session description.
	If the packet is a session deletion packet, the payload contains		If the packet is a session deletion packet, the payload contains a
	a session deletion message. If the payload format is `application/sdp'		session deletion message. If the payload format is `application/sdp'
	the deletion message is a single SDP line consisting of the origin		the deletion message is a single SDP line consisting of the origin
	field of the announcement to be deleted.		field of the announcement to be deleted.
	It is desirable for the payload to be sufficiently small that SAP packets		It is desirable for the payload to be sufficiently small that SAP
	do not get fragmented by the underlying network. Fragmentation has a loss		packets do not get fragmented by the underlying network.
	multiplier effect, which is known to significantly affect the reliability		Fragmentation has a loss multiplier effect, which is known to
	of announcements. It is RECOMMENDED that SAP packets are smaller than		significantly affect the reliability of announcements. It is
	1kByte in length, although if it is known that announcements will use a		RECOMMENDED that SAP packets are smaller than 1kByte in length,
	network with a smaller MTU than this, then that SHOULD be used as the		although if it is known that announcements will use a network with a
	maximum recommended packet size.		smaller MTU than this, then that SHOULD be used as the maximum
			recommended packet size.
	7 Encrypted Announcements		7 Encrypted Announcements
	An announcement is received by all listeners in the scope to which		An announcement is received by all listeners in the scope to which it
	it is sent. If an announcement is encrypted, and many of the receivers		is sent. If an announcement is encrypted, and many of the receivers
	do not have the encryption key, there is a considerable waste of		do not have the encryption key, there is a considerable waste of
	bandwidth since those receivers cannot use the announcement they have		bandwidth since those receivers cannot use the announcement they have
	received. For this reason, the use of encrypted SAP announcements		received. For this reason, the use of encrypted SAP announcements is
	is NOT RECOMMENDED on the global scope SAP group or on administrative		NOT RECOMMENDED on the global scope SAP group or on administrative
	scope groups which may have many receivers which cannot decrypt those		scope groups which may have many receivers which cannot decrypt those
	announcements.		announcements.
	The opinion of the authors is that encrypted SAP is useful in special		The opinion of the authors is that encrypted SAP is useful in special
	cases only, and that the vast majority of scenarios where encrypted		cases only, and that the vast majority of scenarios where encrypted
	SAP has been proposed may be better served by distributing session		SAP has been proposed may be better served by distributing session
	details using another mechanism. There are, however, certain scenarios		details using another mechanism. There are, however, certain
	where encrypted announcements may be useful. For this reason, the		scenarios where encrypted announcements may be useful. For this
	encryption bit is included in the SAP header to allow experimentation		reason, the encryption bit is included in the SAP header to allow
	with encrypted announcements.		experimentation with encrypted announcements.
	This memo does not specify details of the encryption algorithm to		This memo does not specify details of the encryption algorithm to be
	be used or the means by which keys are generated and distributed.		used or the means by which keys are generated and distributed. An
	An additional specification should define these, if it is desired		additional specification should define these, if it is desired to use
	to use encrypted SAP.		encrypted SAP.
	Note that if an encrypted announcement is being announced via a proxy,		Note that if an encrypted announcement is being announced via a
	then there may be no way for the proxy to discover that the announcement		proxy, then there may be no way for the proxy to discover that the
	has been superseded, and so it may continue to relay the old announcement		announcement has been superseded, and so it may continue to relay the
	in addition to the new announcement. SAP provides no mechanism to		old announcement in addition to the new announcement. SAP provides
	chain modified encrypted announcements, so it is advisable to announce		no mechanism to chain modified encrypted announcements, so it is
	the unmodified session as deleted for a short time after the modification		advisable to announce the unmodified session as deleted for a short
	has occurred. This does not guarantee that all proxies have deleted		time after the modification has occurred. This does not guarantee
	the session, and so receivers of encrypted sessions should be prepared		that all proxies have deleted the session, and so receivers of
	to discard old versions of session announcements that they may receive.		encrypted sessions should be prepared to discard old versions of
	In most cases however, the only stateful proxy will be local to (and		session announcements that they may receive. In most cases however,
	known to) the sender, and an additional (local-area) protocol involving		the only stateful proxy will be local to (and known to) the sender,
	a handshake for such session modifications can be used to avoid this		and an additional (local-area) protocol involving a handshake for
	problem.		such session modifications can be used to avoid this problem.
	Session announcements that are encrypted with a symmetric algorithm		Session announcements that are encrypted with a symmetric algorithm
	may allow a degree of privacy in the announcement of a session, but		may allow a degree of privacy in the announcement of a session, but
	it should be recognised that a user in possession of such a key can		it should be recognized that a user in possession of such a key can
	pass it on to other users who should not be in possession of such		pass it on to other users who should not be in possession of such a
	a key. Thus announcements to such a group of key holders cannot		key. Thus announcements to such a group of key holders cannot be
	be assumed to have come from an authorised key holder unless there		assumed to have come from an authorized key holder unless there is an
	is an appropriate authentication header signed by an authorised key		appropriate authentication header signed by an authorized key holder.
	holder. In addition the recipients of such encrypted announcements		In addition the recipients of such encrypted announcements cannot be
	cannot be assumed to only be authorised key holders. Such encrypted		assumed to only be authorized key holders. Such encrypted
	announcements do not provide any real security unless all of the		announcements do not provide any real security unless all of the
	authorised key holders are trusted to maintain security of such session		authorized key holders are trusted to maintain security of such
	directory keys. This property is shared by the multicast session		session directory keys. This property is shared by the multicast
	tools themselves, where it is possible for an un-trustworthy member		session tools themselves, where it is possible for an un-trustworthy
	of the session to pass on encryption keys to un-authorised users.		member of the session to pass on encryption keys to un-authorized
	However it is likely that keys used for the session tools will be		users. However it is likely that keys used for the session tools
	more short lived than those used for session directories.		will be more short lived than those used for session directories.
	Similar considerations should apply when session announcements are		Similar considerations should apply when session announcements are
	encrypted with an asymmetric algorithm, but then it is possible to		encrypted with an asymmetric algorithm, but then it is possible to
	restrict the possessor(s) of the private key, so that announcements		restrict the possessor(s) of the private key, so that announcements
	to a key-holder group can not be made, even if one of the untrusted		to a key-holder group can not be made, even if one of the untrusted
	members of the group proves to be un-trustworthy.		members of the group proves to be un-trustworthy.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| V=1 |P| Auth | |		| V=1 |P| Auth | |
	+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+ |
	| Format specific authentication subheader |		| Format specific authentication subheader |
	: .................. :		: .................. :
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Format of the authentication data in the SAP header		Figure 2: Format of the authentication data in the SAP header
	8 Authenticated Announcements		8 Authenticated Announcements
	The authentication header can be used for two purposes:		The authentication header can be used for two purposes:
	o Verification that changes to a session description or deletion		o Verification that changes to a session description or deletion of
	of a session are permitted.		a session are permitted.
	o Authentication of the identity of the session creator.		o Authentication of the identity of the session creator.
	In some circumstances only verification is possible because a certificate		In some circumstances only verification is possible because a
	signed by a mutually trusted person or authority is not available.		certificate signed by a mutually trusted person or authority is not
	However, under such circumstances, the session originator may still		available. However, under such circumstances, the session originator
	be authenticated to be the same as the session originator of previous		may still be authenticated to be the same as the session originator
	sessions claiming to be from the same person. This may or may not		of previous sessions claiming to be from the same person. This may
	be sufficient depending on the purpose of the session and the people		or may not be sufficient depending on the purpose of the session and
	involved.		the people involved.
	Clearly the key used for the authentication should not be trusted		Clearly the key used for the authentication should not be trusted to
	to belong to the session originator unless it has been separately		belong to the session originator unless it has been separately
	authenticated by some other means, such as being certified by a trusted		authenticated by some other means, such as being certified by a
	third party. Such certificates are not normally included in an SAP		trusted third party. Such certificates are not normally included in
	header because they take more space than can normally be afforded		an SAP header because they take more space than can normally be
	in an SAP packet, and such verification must therefore take place		afforded in an SAP packet, and such verification must therefore take
	by some other mechanism. However, as certified public keys are normally		place by some other mechanism. However, as certified public keys are
	locally cached, authentication of a particular key only has to take		normally locally cached, authentication of a particular key only has
	place once, rather than every time the session directory retransmits		to take place once, rather than every time the session directory
	the announcement.		retransmits the announcement.
	SAP is not tied to any single authentication mechanism. Authentication		SAP is not tied to any single authentication mechanism.
	data in the header is self-describing, but the precise format depends		Authentication data in the header is self-describing, but the precise
	on the authentication mechanism in use. The generic format of the		format depends on the authentication mechanism in use. The generic
	authentication data is given in figure 2. The structure of the format		format of the authentication data is given in figure 2. The
	specific authentication subheader, using both the PGP and the CMS		structure of the format specific authentication subheader, using both
	formats, is discussed in sections 8.1 and 8.2 respectively. Additional		the PGP and the CMS formats, is discussed in sections 8.1 and 8.2
	formats may be added in future.		respectively. Additional formats may be added in future.
	Version Number, V: The version number of the authentication format		Version Number, V: The version number of the authentication format
	specified by this memo is 1.		specified by this memo is 1.
	Padding Bit, P: If necessary the authentication data is padded		Padding Bit, P: If necessary the authentication data is padded to be
	to be a multiple of 32 bits and the padding bit is set. In		a multiple of 32 bits and the padding bit is set. In this case
	this case the last byte of the authentication data contains the		the last byte of the authentication data contains the number of
	number of padding bytes (including the last byte) that must be		padding bytes (including the last byte) that must be discarded.
	discarded.
	Authentication Type, Auth: The authentication type is a 4 bit encoded		Authentication Type, Auth: The authentication type is a 4 bit
	field that denotes the authentication infrastructure the sender		encoded field that denotes the authentication infrastructure the
	expects the recipients to use to check the authenticity and integrity		sender expects the recipients to use to check the authenticity and
	of the information. This defines the format of the authentication		integrity of the information. This defines the format of the
	subheader and can take the values: 0 = PGP format, 1 = CMS		authentication subheader and can take the values: 0 = PGP format,
	format. All other values are undefined and SHOULD be ignored.		1 = CMS format. All other values are undefined and SHOULD be
			ignored.
	If a SAP packet is to be compressed or encrypted, this MUST be done		If a SAP packet is to be compressed or encrypted, this MUST be done
	before the authentication is added.		before the authentication is added.
	The digital signature in the authentication data MUST be calculated		The digital signature in the authentication data MUST be calculated
	over the entire packet, including the header. The authentication		over the entire packet, including the header. The authentication
	length MUST be set to zero and the authentication data excluded when		length MUST be set to zero and the authentication data excluded when
	calculating the digital signature.		calculating the digital signature.
	It is to be expected that sessions may be announced by a number of		It is to be expected that sessions may be announced by a number of
	different mechanisms, not only SAP. For example, a session description		different mechanisms, not only SAP. For example, a session
	may placed on a web page, sent by email or conveyed in a session		description may placed on a web page, sent by email or conveyed in a
	initiation protocol. To ease interoperability with these other		session initiation protocol. To ease interoperability with these
	mechanisms, application level security is employed, rather than		other mechanisms, application level security is employed, rather than
	using IPsec authentication headers.		using IPsec authentication headers.
	8.1 PGP Authentication		8.1 PGP Authentication
	A full description of the PGP protocol can be found in [2]. When using PGP		A full description of the PGP protocol can be found in [2]. When
	for SAP authentication the basic format specific authentication subheader		using PGP for SAP authentication the basic format specific
	comprises a digital signature packet as described in [2]. The signature		authentication subheader comprises a digital signature packet as
	type MUST be 0x01 which means the signature is that of a canonical text		described in [2]. The signature type MUST be 0x01 which means the
	document.		signature is that of a canonical text document.
	8.2 CMS Authentication		8.2 CMS Authentication
	A full description of the Cryptographic Message Syntax can be found		A full description of the Cryptographic Message Syntax can be found
	in [6]. The format specific authentication subheader will, in the		in [6]. The format specific authentication subheader will, in the
	CMS case, have an ASN.1 ContentInfo type with the ContentType being		CMS case, have an ASN.1 ContentInfo type with the ContentType being
	signedData.		signedData.
	Use is made of the option available in PKCS#7 to leave the content		Use is made of the option available in PKCS#7 to leave the content
	itself blank as the content which is signed is already present in		itself blank as the content which is signed is already present in the
	the packet. Inclusion of it within the SignedData type would duplicate		packet. Inclusion of it within the SignedData type would duplicate
	this data and increase the packet length unnecessarily. In addition		this data and increase the packet length unnecessarily. In addition
	this allows recipients with either no interest in the authentication,		this allows recipients with either no interest in the authentication,
	or with no mechanism for checking it, to more easily skip the authentication		or with no mechanism for checking it, to more easily skip the
	information.		authentication information.
	There SHOULD be only one signerInfo and related fields corresponding		There SHOULD be only one signerInfo and related fields corresponding
	to the originator of the SAP announcement. The signingTime SHOULD		to the originator of the SAP announcement. The signingTime SHOULD be
	be present as a signedAttribute. However, due to the strict size		present as a signedAttribute. However, due to the strict size
	limitations on the size of SAP packets, certificates and CRLs SHOULD		limitations on the size of SAP packets, certificates and CRLs SHOULD
	NOT be included in the signedData structure. It is expected that		NOT be included in the signedData structure. It is expected that
	users of the protocol will have other methods for certificate and		users of the protocol will have other methods for certificate and CRL
	CRL distribution.		distribution.
	9 Scalability and caching		9 Scalability and caching
	SAP is intended to announce the existence of long-lived wide-area		SAP is intended to announce the existence of long-lived wide-area
	multicast sessions. It is not an especially timely protocol: sessions		multicast sessions. It is not an especially timely protocol:
	are announced by periodic multicast with a repeat rate on the order		sessions are announced by periodic multicast with a repeat rate on
	of tens of minutes, and no enhanced reliability over UDP. This leads		the order of tens of minutes, and no enhanced reliability over UDP.
	to a long startup delay before a complete set of announcements is		This leads to a long startup delay before a complete set of
	heard by a listener. This delay is clearly undesirable for interactive		announcements is heard by a listener. This delay is clearly
	browsing of announced sessions.		undesirable for interactive browsing of announced sessions.
	In order to reduce the delays inherent in SAP, it is recommended		In order to reduce the delays inherent in SAP, it is recommended that
	that proxy caches are deployed. A SAP proxy cache is expected to		proxy caches are deployed. A SAP proxy cache is expected to listen
	listen to all SAP groups in its scope, and to maintain an up-to-date		to all SAP groups in its scope, and to maintain an up-to-date list of
	list of all announced sessions along with the time each announcement		all announced sessions along with the time each announcement was last
	was last received. When a new SAP listeners starts, it should contact		received. When a new SAP listeners starts, it should contact its
	its local proxy to download this information, which is then sufficient		local proxy to download this information, which is then sufficient
	for it to process future announcements directly, as if it has been		for it to process future announcements directly, as if it has been
	continually listening.		continually listening.
	The protocol by which a SAP listener contacts its local proxy cache		The protocol by which a SAP listener contacts its local proxy cache
	is not specified here.		is not specified here.
	10 Security Considerations		10 Security Considerations
	SAP contains mechanisms for ensuring integrity of session announcements,		SAP contains mechanisms for ensuring integrity of session
	for authenticating the origin of an announcement and for encrypting		announcements, for authenticating the origin of an announcement and
	such announcements (sections 7 and 8).		for encrypting such announcements (sections 7 and 8).
	As stated in section 5, if a session modification announcement is		As stated in section 5, if a session modification announcement is
	received that contains a valid authentication header, but which is		received that contains a valid authentication header, but which is
	not signed by the original creator of the session, then the session		not signed by the original creator of the session, then the session
	must be treated as a new session in addition to the original session		must be treated as a new session in addition to the original session
	with the same SDP origin information unless the originator of one		with the same SDP origin information unless the originator of one of
	of the session descriptions can be authenticated using a certificate		the session descriptions can be authenticated using a certificate
	signed by a trusted third party. If this were not done, there would		signed by a trusted third party. If this were not done, there would
	be a possible denial of service attack whereby a party listens for		be a possible denial of service attack whereby a party listens for
	new announcements, strips off the original authentication header,		new announcements, strips off the original authentication header,
	modifies the session description, adds a new authentication header		modifies the session description, adds a new authentication header
	and re-announces the session. If a rule was imposed that such spoof		and re-announces the session. If a rule was imposed that such spoof
	announcements were ignored, then if packet loss or late starting		announcements were ignored, then if packet loss or late starting of a
	of a session directory instance caused the original announcement to		session directory instance caused the original announcement to fail
	fail to arrive at a site, but the spoof announcement did so, this		to arrive at a site, but the spoof announcement did so, this would
	would then prevent the original announcement from being accepted at		then prevent the original announcement from being accepted at that
	that site.		site.
	A similar denial-of-service attack is possible if a session announcement		A similar denial-of-service attack is possible if a session
	receiver relies completely on the originating source and hash fields to		announcement receiver relies completely on the originating source and
	indicate change, and fails to parse the remainder of announcements for		hash fields to indicate change, and fails to parse the remainder of
	which it has seen the origin/hash combination before.		announcements for which it has seen the origin/hash combination
			before.
	A denial of service attack is possible from a malicious site close		A denial of service attack is possible from a malicious site close to
	to a legitimate site which is making a session announcement. This		a legitimate site which is making a session announcement. This can
	can happen if the malicious site floods the legitimate site with		happen if the malicious site floods the legitimate site with huge
	huge numbers of (illegal) low TTL announcements describing high TTL		numbers of (illegal) low TTL announcements describing high TTL
	sessions. This may reduce the session announcement rate of the legitimate		sessions. This may reduce the session announcement rate of the
	announcement to below a tenth of the rate expected at remote sites		legitimate announcement to below a tenth of the rate expected at
	and therefore cause the session to time out. Such an attack is likely		remote sites and therefore cause the session to time out. Such an
	to be easily detectable, and we do not provide any mechanism here		attack is likely to be easily detectable, and we do not provide any
	to prevent it.		mechanism here to prevent it.
	A Summary of differences between SAPv0 and SAPv1		A. Summary of differences between SAPv0 and SAPv1
	For this purpose SAPv0 is defined as the protocol in use by version		For this purpose SAPv0 is defined as the protocol in use by version
	2.2 of the session directory tool, sdr. SAPv1 is the protocol described		2.2 of the session directory tool, sdr. SAPv1 is the protocol
	in the 19 November 1996 version of this memo (draft-ietf-mmusic-sap-00.txt).		described in the 19 November 1996 version of this memo. The packet
	The packet headers of SAP messages are the same in V0 and V1 in		headers of SAP messages are the same in V0 and V1 in that a V1 tool
	that a V1 tool can parse a V0 announcement header but not vice-versa.		can parse a V0 announcement header but not vice-versa. In SAPv0, the
	In SAPv0, the fields have the following values:		fields have the following values:
	o Version Number: 0		o Version Number: 0
	o Message Type: 0 (Announcement)		o Message Type: 0 (Announcement)
	o Authentication Type: 0 (No Authentication)		o Authentication Type: 0 (No Authentication)
	o Encryption Bit: 0 (No Encryption)		o Encryption Bit: 0 (No Encryption)
	o Compression Bit: 0 (No compression)		o Compression Bit: 0 (No compression)
	o Message Id Hash: 0 (No Hash Specified)		o Message Id Hash: 0 (No Hash Specified)
	o Originating Source: 0 (No source specified, announcement has		o Originating Source: 0 (No source specified, announcement has
	not been relayed)		not been relayed)
	B Summary of differences between SAPv1 and SAPv2		B. Summary of differences between SAPv1 and SAPv2
	The packet headers of SAP messages are the same in V1 and V2 in		The packet headers of SAP messages are the same in V1 and V2 in that
	that a V2 tool can parse a V1 announcement header but not necessarily		a V2 tool can parse a V1 announcement header but not necessarily
	vice-versa.		vice-versa.
	o The A bit has been added to the SAP header, replacing one of		o The A bit has been added to the SAP header, replacing one of the
	the bits of the SAPv1 message type field. If set to zero the		bits of the SAPv1 message type field. If set to zero the
	announcement is of an IPv4 session, and the packet is backwards		announcement is of an IPv4 session, and the packet is backwards
	compatible with SAPv1. If set to one the announcement is of		compatible with SAPv1. If set to one the announcement is of an
	an IPv6 session, and SAPv1 listeners (which do not support IPv6)		IPv6 session, and SAPv1 listeners (which do not support IPv6) will
	will see this as an illegal message type (MT) field.		see this as an illegal message type (MT) field.
	o The second bit of the message type field in SAPv1 has been replaced		o The second bit of the message type field in SAPv1 has been
	by a reserved, must-be-zero, bit. This bit was unused in SAPv1,		replaced by a reserved, must-be-zero, bit. This bit was unused in
	so this change just codifies existing usage.		SAPv1, so this change just codifies existing usage.
	o SAPv1 specified encryption of the payload. SAPv2 includes the		o SAPv1 specified encryption of the payload. SAPv2 includes the E
	E bit in the SAP header to indicate that the payload is encrypted,		bit in the SAP header to indicate that the payload is encrypted,
	but does not specify any details of the encryption.		but does not specify any details of the encryption.
	o SAPv1 allowed the message identifier hash and originating source		o SAPv1 allowed the message identifier hash and originating source
	fields to be set to zero, for backwards compatibility. This		fields to be set to zero, for backwards compatibility. This is no
	is no longer legal.		longer legal.
	o SAPv1 specified gzip compression. SAPv2 uses zlib (the only		o SAPv1 specified gzip compression. SAPv2 uses zlib (the only known
	known implementation of SAP compression used zlib, and gzip compression		implementation of SAP compression used zlib, and gzip compression
	was a mistake).		was a mistake).
	o SAPv2 provides a more complete specification for authentication.		o SAPv2 provides a more complete specification for authentication.
	o SAPv2 allows for non-SDP payloads to be transported. SAPv1 required		o SAPv2 allows for non-SDP payloads to be transported. SAPv1
	that the payload was SDP.		required that the payload was SDP.
	o SAPv1 included a timeout field for encrypted announcement, SAPv2		o SAPv1 included a timeout field for encrypted announcement, SAPv2
	does not (and relies of explicit deletion messages or implicit		does not (and relies of explicit deletion messages or implicit
	timeouts).		timeouts).
	C Acknowledgments		C. Acknowledgements
	SAP and SDP were originally based on the protocol used by the sd		SAP and SDP were originally based on the protocol used by the sd
	session directory from Van Jacobson at LBNL. Version 1 of SAP was		session directory from Van Jacobson at LBNL. Version 1 of SAP was
	designed by Mark Handley as part of the European Commission MICE		designed by Mark Handley as part of the European Commission MICE
	(Esprit 7602) and MERCI (Telematics 1007) projects. Version 2 includes		(Esprit 7602) and MERCI (Telematics 1007) projects. Version 2
	authentication features developed by Edmund Whelan, Goli Montasser-Kohsari		includes authentication features developed by Edmund Whelan, Goli
	and Peter Kirstein as part of the European Commission ICE-TEL project		Montasser-Kohsari and Peter Kirstein as part of the European
	(Telematics 1005), and support for IPv6 developed by Maryann P. Maher		Commission ICE-TEL project (Telematics 1005), and support for IPv6
	and Colin Perkins.		developed by Maryann P. Maher and Colin Perkins.
	D Authors' Addresses		D. Authors' Addresses
	Mark Handley <mjh@aciri.org>		Mark Handley
	AT&T Center for Internet Research at ICSI,		AT&T Center for Internet Research at ICSI,
	International Computer Science Institute,		International Computer Science Institute,
	1947 Center Street, Suite 600,		1947 Center Street, Suite 600,
	Berkeley, CA 94704, USA		Berkeley, CA 94704, USA
	Colin Perkins <c.perkins@cs.ucl.ac.uk>		EMail: mjh@aciri.org
	Department of Computer Science,
	University College London,
	Gower Street,
	London, WC1E 6BT, UK
	Edmund Whelan <e.whelan@cs.ucl.ac.uk>		Colin Perkins
	Department of Computer Science,		USC Information Sciences Institute
	University College London,		4350 N. Fairfax Drive, Suite 620
	Gower Street,		Arlington, VA 22203, USA
	London, WC1E 6BT, UK
			EMail: csp@isi.edu
			Edmund Whelan
			Department of Computer Science,
			University College London,
			Gower Street,
			London, WC1E 6BT, UK
			EMail: e.whelan@cs.ucl.ac.uk
	References		References
	[1] S. Bradner. Key words for use in RFCs to indicate requirement levels,		[1] Bradner, S., "Key words for use in RFCs to indicate requirement
	March 1997. RFC2119.		levels", BCP 14, RFC 2119, March 1997.
	[2] J. Callas, L. Donnerhacke, H. Finney, and R. Thayer. OpenPGP message		[2] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer. "OpenPGP
	format, November 1998. RFC2440.		message format", RFC 2440, November 1998.
	[3] P. Deutsch and J.-L. Gailly. Zlib compressed data format specification		[3] Deutsch, P. and J.-L. Gailly, "Zlib compressed data format
	version 3.3, May 1996. RFC1950.		specification version 3.3", RFC 1950, May 1996.
	[4] M. Handley and V. Jacobson. SDP: Session Description Protocol, April		[4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
	1998. RFC2327.		RFC 2327, April 1998.
	[5] M. Handley, D. Thaler, and R. Kermode. Multicast-scope zone		[5] Handley, M., Thaler, D. and R. Kermode, "Multicast-scope zone
	announcement protocol (MZAP), February 2000. RFC2776.		announcement protocol (MZAP)", RFC 2776, February 2000.
	[6] R. Housley. Cryptographic message syntax, June 1999. RFC2630.		[6] Housley, R., "Cryptographic message syntax", RFC 2630, June 1999.
	[7] D. Mayer. Administratively scoped IP multicast, July 1998. RFC2365.		[7] Mayer, D., "Administratively scoped IP multicast", RFC 2365, July
			1998.
			Full Copyright Statement
			Copyright (C) The Internet Society (2000). All Rights Reserved.
			This document and translations of it may be copied and furnished to
			others, and derivative works that comment on or otherwise explain it
			or assist in its implementation may be prepared, copied, published
			and distributed, in whole or in part, without restriction of any
			kind, provided that the above copyright notice and this paragraph are
			included on all such copies and derivative works. However, this
			document itself may not be modified in any way, such as by removing
			the copyright notice or references to the Internet Society or other
			Internet organizations, except as needed for the purpose of
			developing Internet standards in which case the procedures for
			copyrights defined in the Internet Standards process must be
			followed, or as required to translate it into languages other than
			English.
			The limited permissions granted above are perpetual and will not be
			revoked by the Internet Society or its successors or assigns.
			This document and the information contained herein is provided on an
			"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
			TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
			BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
			HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
			MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Acknowledgement
			Funding for the RFC Editor function is currently provided by the
			Internet Society.
End of changes. 134 change blocks.
	565 lines changed or deleted		571 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/