RFC 2974

Session Announcement Protocol

📅 published October 2000, from ietf

Session Announcement Protocol 🎀

Okay bestie, let's do the paperwork first 💅

  • Network Working Group: this one lives in the Network Working Group 🌸
  • RFC number: 2974
  • Category: Experimental 🧪
  • Authors: M. Handley (ACIRI), C. Perkins (USC/ISI), and E. Whelan (UCL) 👯
  • Date: October 2000 📅
  • Obsoletes / Updates: the title block doesn't have an Obsoletes or Updates line, so this one doesn't list anything it replaces or changes 🦋

Status of This Memo ✨

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 💜

Okay so this doc describes version 2 of the multicast session directory announcement protocol, the Session Announcement Protocol (SAP). It also covers the security and scalability issues implementors should keep in mind, because they're kind of a big deal 🔐🌈

1. Introduction 🧚

Okay so imagine you're hosting a multicast conference or some other multicast session and you need people to find out about it. A distributed session directory can handle that. Each session directory keeps sending out packets that describe the session, and other session directories pick those up. That way, potential remote participants can use the description to start up the tools they need to join in 🎉

This memo covers the issues involved in announcing session description info over multicast, and it defines the announcement protocol to use. Sessions get described with the session description protocol, which has its own companion memo [4]. Bestie, it's a whole system and it slays 💅

2. Terminology 📚

A SAP announcer keeps multicasting an announcement packet to a well-known multicast address and port. The announcement goes out with the same scope as the session it's announcing. That way, the people receiving it are inside the session's scope (as long as bandwidth and other constraints allow it). This also matters for scalability, because it keeps local session announcements local 🏡

A SAP listener figures out which multicast scopes it's inside. It can do that with something like the Multicast-Scope Zone Announcement Protocol [5]. Then it listens on the well-known SAP address and port for those scopes. Over time it learns about every session being announced, so it can join them 🦋

The key words MUST', MUST NOT', REQUIRED', SHALL', SHALL NOT', SHOULD', SHOULD NOT', RECOMMENDED', MAY', and OPTIONAL' in this document are to be interpreted as described in [1]. 📖

3. Session Announcement 📣

As we said before, a SAP announcer periodically sends an announcement packet to a well-known multicast address and port. There's no rendezvous mechanism here. The announcer has no idea whether any SAP listeners are around or not. There's also no extra reliability on top of the standard best-effort UDP/IP semantics, so it's giving "send it and hope" energy 🤞

The announcement contains a session description and SHOULD contain an authentication header. The session description MAY be encrypted, but that is NOT RECOMMENDED (see section 7) 🔒

A SAP announcement is multicast with the same scope as the session it's announcing, so the people receiving it are within the session's scope. There are a few possibilities:

  • IPv4 global scope sessions use multicast addresses in the range 224.2.128.0 - 224.2.255.255, and SAP announcements are sent to 224.2.127.254. (Note that 224.2.127.255 is used by the obsolete SAPv0 and MUST NOT be used.) 🌍
  • IPv4 administrative scope sessions use administratively scoped IP multicast as defined in [7]. The multicast address for announcements is the highest multicast address in the relevant administrative scope zone. For example, if the scope range is 239.16.32.0 - 239.16.33.255, then 239.16.33.255 is used for SAP announcements. 🗺️
  • 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 for a link-local session assigned the address FF02:0:0:0:0:0:1234:5678 should be advertised on SAP address FF02:0:0:0:0:0:2:7FFE. 🧊

Whether a description gets used by someone outside the session scope is not addressed in this memo. That's a whole other vibe 🙈

SAP announcements MUST be sent on port 9875, and they SHOULD be sent with an IP time-to-live of 255. (The use of TTL scoping for multicast is discouraged [7].) 📮

If a session uses addresses in multiple administrative scope ranges, the announcer needs to send identical copies of the announcement to each administrative scope range. The listeners are the ones who parse those multiple announcements as the same session. They can tell by things like the SDP origin field. The announcement rate for each administrative scope range MUST be calculated separately, as if the multiple announcements were separate ones 🧩

Multiple announcers can announce a single session. This helps with robustness when packets get lost or when one or more announcers fail 🛟 Each announcer's repeat rate MUST be scaled back so the total announcement rate equals what a single server would choose. Announcements made this way MUST be identical 👯‍♀️

If multiple announcements are being made for a session, then each announcement MUST carry an authentication header signed by the same key. Otherwise, listeners treat each one as a completely separate announcement 🔑

An IPv4 SAP listener SHOULD listen on the IPv4 global scope SAP address and on the SAP addresses for each IPv4 administrative scope zone it's within. Figuring out administrative scope zones is outside the scope of this memo. It's assumed that each SAP listener within a particular scope zone is aware of that scope zone. A SAP listener that supports IPv6 SHOULD also listen to the IPv6 SAP addresses 👂

3.1. Announcement Interval ⏰

The time between repeats of an announcement is picked so that the total bandwidth used by all announcements on a single SAP group stays under a preconfigured limit. If it isn't otherwise specified, the bandwidth limit SHOULD be assumed to be 4000 bits per second 📶

Each announcer should listen to other announcements so it can figure out how many sessions are being announced on a particular group. Sessions are uniquely identified by the combination of the message identifier hash and originating source fields of the SAP header. (Note that SAP v0 announcers always set the message identifier hash to zero, so if one of those announcements is received, the entire message MUST be compared to determine uniqueness.) 🔍

Announcements are made by periodic multicast to the group. The base interval between announcements comes from the number of announcements being made in that group, the size of the announcement, and the configured bandwidth limit. The actual transmission time comes from that base interval like this:

  1. The announcer sets the variable tp to the last time a particular announcement was transmitted. (If this is the first time the announcement is going out, it uses the current time.)
  2. Given a configured bandwidth limit in bits/second and an announcement of ad_size bytes, the base announcement interval in seconds is:
interval =max(300; (8*no_of_ads*ad_size)/limit)
  1. An offset gets calculated based on the base announcement interval:
offset= rand(interval* 2/3)-(interval/3)
  1. The next transmission time for an announcement is derived as:
tn =tp+ interval+ offset

The announcer then sets a timer to expire at tn and waits. When time tn arrives, the announcer SHOULD recalculate the next transmission time. If the new value of tn is before the current time, the announcement is sent right away. Otherwise, the transmission gets rescheduled for the new tn. This reconsideration stops transient packet bursts on startup and when a network partition heals 🩹✨

4. Session Deletion 🗑️

Sessions can be deleted in a few different ways:

  • Explicit Timeout: The session description payload may contain timestamp information that says when the session starts and ends. If the current time is later than the session's end-time, then the session SHOULD be deleted from the receiver's session cache. ⌛
  • Implicit Timeout: A session announcement message should be received periodically for each session description in a receiver's session cache. The receiver can predict the announcement period from the set of sessions currently being announced. If a session announcement message hasn't been received for ten times the announcement period, or one hour, whichever is greater, then the session is deleted from the receiver's session cache. The one hour minimum is there to allow for transient network partitionings. 🕰️
  • Explicit Deletion: A session deletion packet is received that specifies the session to be deleted. Session deletion packets SHOULD have a valid authentication header, matching the one used to authenticate previous announcement packets. If that authentication is missing, the deletion message SHOULD be ignored. 🚫

5. Session Modification ✨

okay so modifying a session is lowkey easy 💅 you just announce the modified session description. BUT the version hash in the SAP header MUST be changed so receivers know to parse the packet contents (or decrypt and then parse them, if it's encrypted) 🔥. The session itself is identified by its payload, NOT by the message identifier hash in the header, so the announcement and the session are two different things, bestie 🦋

The same rules apply to session modification as to session deletion:

  • Either the modified announcement must contain an authentication header signed by the same key as the cached session announcement it is modifying, or:
  • The cached session announcement must not contain an authentication header, and the session modification announcement must originate from the same host as the session it is modifying.

If an announcement is received with an authentication header, and the cached announcement had no authentication header or a different one, then the modified announcement MUST be treated as a new and different announcement. It gets displayed alongside the un-authenticated announcement 👀 The same should happen if a modified packet without an authentication header comes from a different source than the original announcement.

These rules stop someone from slapping an authentication header onto an announcement and then deleting it with that header 🙅‍♀️ They also block a denial-of-service trick where someone sends a spoof announcement that reaches some participants before the original does, because of packet loss. In that situation, being able to authenticate the message originator is the only way to figure out which session is the correct one 🔐

    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                            :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Packet format 🌸

6. Packet Format 📦

okay bestie, here's how a SAP data packet is laid out. It follows the format in figure 1 ✨

  • V: Version Number. The version number field MUST be set to 1. SAPv2 announcements that only use SAPv1 features are backwards compatible, and the ones that use new features can be detected by other means, so the SAP version number doesn't have to change 🎀
  • A: Address type. If the A bit is 0, the originating source field holds a 32-bit IPv4 address. If the A bit is 1, the originating source holds a 128-bit IPv6 address 🌈
  • R: Reserved. SAP announcers MUST set this to 0. SAP listeners MUST ignore the contents of this field 🤫
  • T: Message Type. If T is 0, it's a session announcement packet. If T is 1, it's a session deletion packet 🗑️
  • E: Encryption Bit. If the encryption bit is 1, the payload of the SAP packet is encrypted. If it's 0, the packet is not encrypted. See section 7 for the details of the encryption process 🔒
  • C: Compressed bit. If the compressed bit is 1, the payload is compressed using the zlib compression algorithm [3]. If the payload is both compressed and encrypted, the compression MUST be performed first 🫧
  • Authentication Length. An 8 bit unsigned quantity giving the number of 32 bit words that follow the main SAP header and contain authentication data. If it's zero, no authentication header is present 🙅‍♀️
  • Authentication data. A digital signature of the packet, with its length set by the authentication length header field. See section 8 for the details of the authentication process 🔐
  • Message Identifier Hash. A 16 bit quantity that, combined with the originating source, gives a globally unique identifier for the precise version of this announcement 🪪 The choice of value for this field is not specified here, except that it MUST be unique for each session announced by a particular SAP announcer. It MUST also be changed if the session description is modified, and a session deletion message SHOULD be sent for the old version of the session 🔄

Earlier versions of SAP used a value of zero to mean the hash should be ignored and the payload should always be parsed. The unfortunate side effect was that SAP announcers had to dig through the payload data to work out how many unique sessions were being advertised, which made the announcement interval calculation more complex than necessary 😭 To decouple the announcement process from the contents of those announcements, SAP announcers SHOULD NOT set the message identifier hash to zero.

SAP listeners MAY silently discard messages whose message identifier hash is set to zero 🫥

  • Originating Source. The IP address of the original source of the message. It's an IPv4 address if the A field is 0, and an IPv6 address otherwise. The address is stored in network byte order 🧭

SAPv0 allowed the originating source to be zero if the message identifier hash was also zero. That practice is no longer legal, so SAP announcers SHOULD NOT set the originating source to zero. SAP listeners MAY silently discard packets whose originating source is set to zero 💀

The header is followed by an optional payload type field and then the payload data itself. If the E or C bits are set in the header, both the payload type and the payload are encrypted and/or compressed ✨

The payload type field is a MIME content type specifier that describes the format of the payload. It's a variable length ASCII text string followed by a single zero byte (ASCII NUL) 🧁 The payload type SHOULD be included in all packets. If the payload type is `application/sdp', both the payload type and its terminating zero byte MAY be omitted. That's only for backwards compatibility with SAP v1 listeners, though 🙈

You can tell the payload type field is missing because the payload section of such a packet starts with the SDP `v=0' field, which is not a legal MIME content type specifier 🕵️‍♀️

All implementations MUST support payloads of type `application/sdp' [4] 💖 Other formats MAY be supported. But SAP has no negotiation, so an announcer that picks a session description format other than SDP can't know that its listeners understand the announcement. Lots of payload types floating around could cause severe interoperability problems, so using non-SDP payloads is NOT RECOMMENDED 🚫

If the packet is an announcement packet, the payload contains a session description 📝

If the packet is a session deletion packet, the payload contains a session deletion message. If the payload format is `application/sdp', the deletion message is a single SDP line consisting of the origin field of the announcement to be deleted 🗑️

It's really important that the payload stays small enough that SAP packets don't get fragmented by the underlying network 🥺 Fragmentation has a loss multiplier effect, which is known to seriously hurt the reliability of announcements. It is RECOMMENDED that SAP packets are smaller than 1kByte in length. If you know announcements will travel over a network with a smaller MTU than that, then that smaller size SHOULD be used as the maximum recommended packet size 🌟

7. Encrypted Announcements 🔐✨

okay bestie, every announcement goes to ALL the listeners in the scope it's sent to 🌸 so if it's encrypted and a bunch of receivers don't have the key, that's literally bandwidth going in the bin 😭 they got the packet and can't do anything with it. so the use of encrypted SAP announcements is NOT RECOMMENDED on the global scope SAP group, or on administrative scope groups that might have lots of receivers who can't decrypt stuff 🚫

the authors' take is that encrypted SAP is useful in special cases only 💅 and most of the scenarios where people have proposed it would honestly be better served by sending the session details through some other mechanism 🦋 BUT there are still a few situations where encrypted announcements could be useful, so the encryption bit is in the SAP header to allow experimenting with them 🧪

this memo does NOT get into the encryption algorithm or how keys get generated and distributed 🔑 if you want to use encrypted SAP, an additional specification should define those.

okay now the proxy drama 👀 if an encrypted announcement is being announced via a proxy, the proxy might have no way to discover that the announcement got superseded, so it could keep relaying the old announcement right alongside the new one 💀 SAP has no mechanism to chain modified encrypted announcements, so it's advisable to announce the unmodified session as deleted for a short time after the modification happens. that does NOT guarantee every proxy has deleted the session, so receivers of encrypted sessions should be prepared to discard old versions of session announcements they may receive. in most cases though, the only stateful proxy will be local to (and known to) the sender, and an additional (local-area) protocol involving a handshake for such session modifications can be used to avoid this problem ✨

⚠️ security alert: encrypted session announcements with a symmetric algorithm might give you a bit of privacy 🙈 BUT anyone holding that key can pass it on to people who should NOT have it. so announcements to a group of key holders can't just be assumed to come from an authorized key holder, UNLESS there's an appropriate authentication header signed by an authorized key holder. and the recipients of those encrypted announcements can't be assumed to only be authorized key holders either. these encrypted announcements don't give you any real security unless ALL the authorized key holders are trusted to keep those session directory keys secure 😤 this is the same deal with the multicast session tools themselves, where an untrustworthy member of the session could pass encryption keys on to unauthorized users. however, keys used for the session tools will likely be more short lived than the ones used for session directories ⏳

similar considerations should apply when session announcements are encrypted with an asymmetric algorithm 🗝️ but then it IS possible to restrict who holds the private key, so announcements to a key-holder group can't be made, even if one of the untrusted members of the group turns out to be untrustworthy 👑

                        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 |P| Auth  |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   |              Format  specific authentication subheader        |
   :                        ..................                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Format of the authentication data in the SAP header 🦋

8. Authenticated Announcements 🪪

the authentication header can be used for two purposes, bestie 👇

  • Verification that changes to a session description or deletion of a session are permitted.
  • Authentication of the identity of the session creator.

sometimes only verification is possible, because a certificate signed by a mutually trusted person or authority isn't available 🥺 but in that situation, the session originator may still be authenticated to be the same as the session originator of previous sessions claiming to be from the same person. whether that's enough totally depends on the purpose of the session and the people involved 🤷‍♀️

clearly, the key used for authentication should NOT be trusted to belong to the session originator unless it's been separately authenticated some other way, like being certified by a trusted third party 🎀 these certificates aren't normally included in an SAP header, because they take up more space than can normally be afforded in an SAP packet, so that verification has to happen some other mechanism 📦 however, certified public keys are normally cached locally, so authenticating a particular key only has to happen once, rather than every single time the session directory retransmits the announcement 🧠

SAP is not tied to any single authentication mechanism 🌈 the authentication data in the header is self-describing, but the precise format depends on the authentication mechanism in use. the generic format of the authentication data is shown in figure 2. the structure of the format specific authentication subheader, using both the PGP and the CMS formats, is discussed in sections 8.1 and 8.2 respectively. additional formats may be added in future 🔮

Version Number, V: the version number of the authentication format specified by this memo is 1.

Padding Bit, P: if necessary, the authentication data is padded to be a multiple of 32 bits and the padding bit is set. in this case, the last byte of the authentication data contains the number of padding bytes (including the last byte) that must be discarded 🧾

Authentication Type, Auth: the authentication type is a 4 bit encoded field that denotes the authentication infrastructure the sender expects the recipients to use to check the authenticity and integrity of the information. this defines the format of the authentication subheader and can take the values: 0 = PGP format, 1 = CMS format. all other values are undefined and SHOULD be ignored 🚫

if a SAP packet is going to be compressed or encrypted, that MUST be done before the authentication is added 🗜️

the digital signature in the authentication data MUST be calculated over the ENTIRE packet, including the header 💯 the authentication length MUST be set to zero, and the authentication data is excluded when calculating the digital signature 🧮

it's expected that sessions may be announced by a number of different mechanisms, not only SAP 🌍 for example, a session description may be placed on a web page, sent by email, or conveyed in a session initiation protocol. to make interoperability with these other mechanisms easier, application level security is used, rather than IPsec authentication headers 💌

8.1. PGP Authentication 🔏

a full description of the PGP protocol can be found in [2]. when using PGP for SAP authentication, the basic format specific authentication subheader comprises a digital signature packet as described in [2]. the signature type MUST be 0x01, which means the signature is that of a canonical text document ✍️

8.2. CMS Authentication 📜

a full description of the Cryptographic Message Syntax can be found in [6]. in the CMS case, the format specific authentication subheader will have an ASN.1 ContentInfo type, with the ContentType being signedData 💫

there's an option in PKCS#7 to leave the content itself blank, since the content being signed is already present in the packet, and the code uses that option 🙌 including it inside the SignedData type would duplicate that data and make the packet longer for no reason 🙅‍♀️ on top of that, this lets recipients who have no interest in the authentication, or no way to check it, skip the authentication info more easily 🏃‍♀️

there SHOULD be only one signerInfo and related fields corresponding to the originator of the SAP announcement 👤 the signingTime SHOULD be present as a signedAttribute. however, because SAP packets have strict size limitations, certificates and CRLs SHOULD NOT be included in the signedData structure 📉 it's expected that users of the protocol will have other methods for certificate and CRL distribution 🗂️

9. Scalability and caching 🐢

SAP is meant to announce the existence of long-lived wide-area multicast sessions 🌐 it is NOT an especially timely protocol. sessions are announced by periodic multicast with a repeat rate on the order of tens of minutes, and there's no enhanced reliability over UDP 😵‍💫 this leads to a long startup delay before a listener hears a complete set of announcements. that delay is clearly undesirable for interactive browsing of announced sessions 😩

to reduce the delays inherent in SAP, it is recommended that proxy caches are deployed 🚀 a SAP proxy cache is expected to listen to all SAP groups in its scope, and to maintain an up-to-date list of all announced sessions, along with the time each announcement was last received 📋 when a new SAP listener starts, it should contact its local proxy to download this information. that's then enough for it to process future announcements directly, as if it had been continually listening all along 🎉

the protocol by which a SAP listener contacts its local proxy cache is not specified here 🤐

10. Security Considerations 🔐✨

okay bestie, this is the spicy part 🌶️ SAP has some real defenses here: it can check that session announcements haven't been messed with (integrity), confirm who actually sent them (origin authentication), and scramble them up so only the right people can read them (encryption). Those live in sections 7 and 8 🫶

Now back to section 5 🙈 If a session modification announcement shows up with a valid authentication header but it wasn't signed by the original creator of the session, the session must be treated as a brand new session, sitting alongside the original one even though they share the same SDP origin info. The only exception is if the originator of one of those session descriptions can be authenticated using a certificate signed by a trusted third party 🔑 Why so strict? Because otherwise someone could be a total menace 😤 They listen for new announcements, rip off the original authentication header, change the session description, slap on a fresh authentication header, and re-announce the session. Now, you might think "cool, just ignore spoofed announcements!" but nope 💀 Say packet loss, or a session directory instance that started up late, means the real announcement never reached some site, but the spoofed one did. If we ignored spoofs, the original would get blocked from being accepted at that site. Not a vibe.

There's also a similar denial-of-service move 🚨 If a receiver totally trusts the originating source and hash fields to tell it when something has changed, and then doesn't bother parsing the rest of an announcement it's already seen that origin/hash combo for, it's basically asking to get tricked 🙃

And then there's the nearby-attacker situation 👀 A malicious site close to a legit site making a session announcement can flood it with huge numbers of (illegal) low TTL announcements that describe high TTL sessions. That can drag the legitimate announcement rate down to below a tenth of what remote sites expect, which can make the session time out 😭 The good news is this kind of attack is likely to be easy to spot. The bad news? This document doesn't provide any mechanism to stop it 💔

A. Summary of differences between SAPv0 and SAPv1 📚

Okay, so SAPv0 here means the protocol used by version 2.2 of the session directory tool, sdr 🎀 SAPv1 is the protocol from the 19 November 1996 version of this memo. The SAP packet headers are the same in V0 and V1, in that a V1 tool can parse a V0 announcement header but not the other way around. In SAPv0, the fields are set like this:

  • Version Number: 0
  • Message Type: 0 (Announcement)
  • Authentication Type: 0 (No Authentication)
  • Encryption Bit: 0 (No Encryption)
  • Compression Bit: 0 (No compression)
  • Message Id Hash: 0 (No Hash Specified)
  • Originating Source: 0 (No source specified, announcement has not been relayed)

B. Summary of differences between SAPv1 and SAPv2 🦋

The SAP packet headers are the same in V1 and V2 too, so a V2 tool can parse a V1 announcement header, but not necessarily the reverse 💜 Here's the glow-up list:

  • The A bit got added to the SAP header, replacing one bit of the SAPv1 message type field 🌈 If it's set to zero, the announcement is for an IPv4 session, and the packet stays backwards compatible with SAPv1. If it's set to one, the announcement is for an IPv6 session, and SAPv1 listeners (which don't support IPv6) will see it as an illegal message type (MT) field 💀
  • The second bit of the SAPv1 message type field got replaced by a reserved, must-be-zero bit. That bit wasn't used in SAPv1 anyway, so this just makes existing usage official ✅
  • SAPv1 specified encryption of the payload. SAPv2 includes the E bit in the SAP header to say the payload is encrypted, but it doesn't spell out any details of the encryption 🔒
  • SAPv1 let the message identifier hash and originating source fields be set to zero, for backwards compatibility. That's no longer legal 🙅‍♀️
  • SAPv1 specified gzip compression. SAPv2 uses zlib instead, because the only known implementation of SAP compression used zlib, and gzip compression was a mistake 🫠
  • SAPv2 provides a more complete specification for authentication 🔐
  • SAPv2 allows non-SDP payloads to be transported. SAPv1 required the payload to be SDP 🧚
  • SAPv1 included a timeout field for encrypted announcements. SAPv2 doesn't have one, and instead relies on explicit deletion messages or implicit timeouts ⏳

C. Acknowledgements 💖

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 designed by Mark Handley as part of the European Commission MICE (Esprit 7602) and MERCI (Telematics 1007) projects 🍓 Version 2 includes authentication features developed by Edmund Whelan, Goli Montasser-Kohsari and Peter Kirstein as part of the European Commission ICE-TEL project (Telematics 1005), and support for IPv6 developed by Maryann P. Maher and Colin Perkins 🫶

D. Authors' Addresses 📮

Mark Handley
AT&T Center for Internet Research at ICSI,
International Computer Science Institute,
1947 Center Street, Suite 600,
Berkeley, CA 94704, USA

EMail: mjh@aciri.org


Colin Perkins
USC Information Sciences Institute
4350 N. Fairfax Drive, Suite 620
Arlington, VA 22203, USA

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 📖

[1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.

[2] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer. "OpenPGP message format", RFC 2440, November 1998.

[3] Deutsch, P. and J.-L. Gailly, "Zlib compressed data format specification version 3.3", RFC 1950, May 1996.

[4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.

[5] Handley, M., Thaler, D. and R. Kermode, "Multicast-scope zone announcement protocol (MZAP)", RFC 2776, February 2000.

[6] Housley, R., "Cryptographic message syntax", RFC 2630, June 1999.

[7] Mayer, D., "Administratively scoped IP multicast", RFC 2365, July 1998.

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. 💜✨

📦 where this page comes from