--- 1/draft-ietf-mmusic-sap-v2-02.txt	2006-02-05 00:27:40.000000000 +0100
+++ 2/draft-ietf-mmusic-sap-v2-03.txt	2006-02-05 00:27:40.000000000 +0100
@@ -1,129 +1,125 @@
                                               Mark Handley
                                                      ACIRI
                                              Colin Perkins
                                                        UCL
                                              Edmund Whelan
                                                        UCL
 
                 Session Announcement Protocol
-               draft-ietf-mmusic-sap-v2-02.txt
+               draft-ietf-mmusic-sap-v2-03.txt
 
                     Status of this memo
 
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
+This document is an Internet-Draft and is in full conformance with
+all provisions of Section 10 of RFC2026.
 
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups.  Note that other groups
-may also distribute working documents as Internet-Drafts.
+Internet-Drafts are working documents of the Internet Engineering
+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 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."
+Internet-Drafts are draft documents valid for a maximum of six months
+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
 http://www.ietf.org/ietf/1id-abstracts.txt
 
 The list of Internet-Draft Shadow Directories can be accessed at
 http://www.ietf.org/shadow.html.
 
 This document is a product of the Multiparty Multimedia Session Control
 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.
+solicited and should be addressed to the working group's mailing
+list at confctrl@isi.edu and/or the authors.
 
                          Abstract
 
-    This document describes version 2 of the multicast session directory
-    announcement protocol, SAP, and the related issues affecting security
-    and scalability that should be taken into account by the implementors
-    of multicast session directory tools.
+    This document describes version 2 of the multicast session
+    directory announcement protocol, SAP, and the related issues
+    affecting security and scalability that should be taken
+    into account by the implementors of multicast session directory
+    tools.
 
 1  Introduction
 
 In order to assist the advertisement of multicast multimedia conferences
 and other multicast sessions, and to communicate the relevant session
 
 setup information to prospective participants, a distributed session
 directory may be used.  An instance of such a session directory periodically
 multicasts packets containing a description of the session, and these
-advertisements are received by potential participants who can use
-the session description to start the tools required to participate
-in the session.
+advertisements are received by potential participants who can use the
+session description to start the tools required to participate in the
+session.
 
-This memo describes the issues involved in the multicast announcement
-of session description information and defines an announcement protocol
-to be used by session directory clients.  Sessions are described
-using the session description protocol which is described in a companion
-memo [4].
+This memo describes the issues involved in the multicast announcement of
+session description information and defines an announcement protocol to be
+used by session directory clients.  Sessions are described using the
+session description protocol which is described in a companion memo [4].
 
 2  Terminology
 
-A SAP announcer periodically multicasts an announcement packet to
-a well known multicast address and port.  The announcement is multicast
-with the same scope as the session it is announcing, ensuring that
-the recipients of the announcement can also be potential recipients
-of the session the announcement describes (bandwidth and other such
-constraints permitting).  This is also important for the scalability
-of the protocol, as it keeps local session announcements local.
+A SAP announcer periodically multicasts an announcement packet to a well
+known multicast address and port.  The announcement is multicast with the
+same scope as the session it is announcing, ensuring that the recipients of
+the announcement can also be potential recipients of the session the
+announcement describes (bandwidth and other such constraints permitting).
+This is also important for the scalability of the protocol, as it keeps
+local session announcements local.
 
 A SAP listener learns of the multicast scopes it is within (for example,
-using the Multicast-Scope Zone Announcement Protocol [5]) and listens
-on the well known SAP address and port for those scopes.  In this
-manner, it will eventually learn of all the sessions being announced,
-allowing those sessions to be joined.
+using the Multicast-Scope Zone Announcement Protocol [5]) and listens on
+the well known SAP address and port for those scopes.  In this manner, it
+will eventually learn of all the sessions being announced, allowing those
+sessions to be joined.
 
 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 noted previously, a SAP announcer periodically sends an announcement
 packet to a well known multicast address and port.  There is no rendezvous
-mechanism - the SAP announcer is not aware of the presence or absence
-of any SAP listeners - and no additional reliability is provided
-over the standard best-effort UDP/IP semantics.
+mechanism - the SAP announcer is not aware of the presence or absence of
+any SAP listeners - and no additional reliability is provided over the
+standard best-effort UDP/IP semantics.
 
-That announcement contains a session description and SHOULD contain
-an authentication header.  The session description MAY be encrypted
-although this is NOT RECOMMENDED (see section 8).
+That announcement contains a session description and SHOULD contain an
+authentication header.  The session description MAY be encrypted although
+this is NOT RECOMMENDED (see section 7).
 
 A SAP announcement is multicast with the same scope as the session
 it is announcing, ensuring that the recipients of the announcement
 
 can also be potential recipients of the session being advertised.
-There are four possiblities:
+There a number of possiblities:
 
 IPv4 global scope sessions use multicast addresses in the range
     224.2.128.0 - 224.2.255.255 with SAP announcements being 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 using administratively scoped
     IP multicast as defined in [7].  The multicast address to be
     used 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,
+    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.
 
-Directory sessions are announced on an  address which is itself announced
-    by a SAP announcement.  See section 6 for details for directory
-    sessions.
-
 SAP announcements MUST be sent on port 9875 and SHOULD be sent with
 an IP time-to-live of 255.
 
 If a session uses addresses in multiple administrative scope ranges, it is
 necessary for the announcer to send identical copies of the announcement to
 each administrative scope range.  It is up to the listeners to parse such
 multiple announcements as the same session (as identified by the SDP origin
 field, for example).  The announcement rate for each administrative scope
 range MUST be calculated separately, as if the multiple announcements were
 separate.
@@ -136,71 +132,69 @@
 
 If multiple announcements are being made for a session, then each
 announcement MUST carry an authentication header signed by the same
 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 on the SAP addresses for each IPv4 administrative scope zone
 it is within.  The discovery of administrative scope zones is outside
 the scope of this memo, but it is assumed that each SAP listener
 within a particular scope zone is aware of that scope zone.  A SAP
-
 listener which supports IPv6 SHOULD also listen to the IPv6 SAP addresses.
-Support for directory sessions is OPTIONAL.
 
 3.1 Announcement Interval
 
 The time period between repetitions of an announcement is chosen
 such that the total bandwidth used by all announcements on a single
 SAP group remains below a preconfigured limit.  If not otherwise
 specified, the bandwidth limit SHOULD be assumed to be 4000 bits
 per second.
 
-Each announcer is expected to listen to other announcements in order
-to determine the total number of sessions 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 clients always set the message identifier
-hash to zero, and if such an announcement is received the entire
-message MUST be compared to determine uniqueness).
+Each announcer is expected to listen to other announcements in order to
+determine the total number of sessions 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 clients always set the message identifier hash to zero, and if such
+an announcement 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 is derived from the number of announcements
 being made in that group, the size of the announcement and the configured
-bandwidth limit.  The actual transmission time is derived from this
-base interval as follows:
+bandwidth limit.  The actual transmission time is derived from this base
+interval as follows:
 
   1.The announcer initialises the variable tp to be the last time
     a particular announcement was transmitted (or the current time
     if this is the first time this announcement is to be made).
 
   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)
+           interval =max(300; (8*no_of_ads*ad_size)=limit)
 
   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
 
                     tn = tp + interval + offset
 
-The announcer then sets a timer to expire at tn and waits.  When
-this timer expires, the announcement is transmitted.
+The announcer then sets a timer to expire at tn and waits. When this timer
+expires, the announcement is transmitted.
 
 If, at some time tc <tn, the no_of_ads changes (eg: if  a new announcer
-starts up, or an existing announcement is deleted), the announcer
-SHOULD recalculate the next transmission time.  If the new value
-of tn is less than tc the announcement is sent immediately.  Otherwise
-the transmission is rescheduled for the new tn.
+starts up, or an existing announcement is deleted), the announcer SHOULD
+recalculate the next transmission time.  If the new value of tn is less
+than tc the announcement is sent immediately.  Otherwise the transmission
+is rescheduled for the new tn.
 
 4  Session Deletion
 
 Sessions may be deleted in one of several ways:
 
 Explicit Timeout The session description payload contains timestamp
     information which specifies a start and end time for the session.
     If the current time is later than the end-time for the session,
     then the session is deleted from the receiver's session cache.
     If an announcement packet arrives with an end-time before the
@@ -218,86 +212,37 @@
     one hour minimum is to allow for transient network partitionings.
 
 Explicit Deletion A session deletion packet is received specifying
     the version of the session to be deleted.  The deletion packets
     should be ignored, unless they contain an authentication header
     which authenticates correctly and matches that used to authenticate
     the announcement which is being deleted.
 
 5  Session Modification
 
-A pre-announced session can be modified by simply announcing the
-modified session description.  In this case, the version hash in
-the SAP header MUST be changed to indicate to receivers that the
-packet contents should be parsed (or decrypted and parsed if it is
-encrypted).  The session itself, as distinct from the session announcement,
-is uniquely identified by the payload and not by the message identifier
-hash in the header.
+A pre-announced session can be modified by simply announcing the modified
+session description.  In this case, the version hash in the SAP header MUST
+be changed to indicate to receivers that the packet contents should be
+parsed (or decrypted and parsed if it is encrypted).  The session itself,
+as distinct from the session 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:
 
   o Either the modified announcement must contain an authentication
     header signed by the same key as the cached session announcement
     it is modifying, or:
 
   o 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.
 
-v=0
-o=cperkins 2890844526 2890842807 IN IP4 126.16.64.4
-s=Sample directory session
-m=directory 9875 SAP application/sdp
-c=IN IP4 224.2.127.12/255
-t=2873397496 2873404696
-
-        Figure 1:  Example SDP for a directory session
-
-If an announcement is received containing an authentication header
-and the cached announcement did not contain an authentication header,
-or it contained a different authentication header, then the modified
-announcement MUST be treated as a new and different announcement,
-and displayed in addition to the un-authenticated announcement.  The
-same should happen if a modified packet without an authentication
-header is received from a different source than the original announcement.
-These rules prevent an announcement having an authentication header
-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  Directory Sessions
-
-It is possible to announce sessions which describe other directories.
-Such directory sessions should each announce a single directory.  Receivers
-MUST ignore announcements which describe multiple directories.  Receivers
-SHOULD ignore non-authenticated directory sessions.
-
-Directory sessions may be described in SDP using the media type `directory'
-with transport `SAP' (see figure 1 for example).  Directory sessions
-SHOULD be announced with TTL 255 and SHOULD use port 9875.  Any SAP
-announcer may announce sessions in an announced SAP group, there
-is no explicit access control.
-
-If the announcement of a directory is deleted, announcers of sessions
-within that directory MUST stop announcing those sessions provided
-the deletion packet authenticates with the same key as the original
-announcement of the directory session.  If the deletion packet is
-not authenticated, or is authenticated with a different key, then
-it SHOULD be ignored.
-
-If the announcement of a directory times out, announcers of sessions
-within that directory SHOULD stop announcing those sessions.
-
-If the announcement of the directory is modified to use a different
  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               |
@@ -307,91 +252,100 @@
 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
 |                      optional payload type                    |
 +                                         +-+- - - - - - - - - -+
 |                                         |0|                   |
 + - - - - - - - - - - - - - - - - - - - - +-+                   |
 |                                                               |
 :                            payload                            :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
-                  Figure 2: Packet format
+                  Figure 1: Packet format
 
-address announcers of sessions within that directory MUST move their
-announcement to the new directory, provided the modification packet
-authenticates with the same key as the original announcement of the
-directory session.  If the modification packet is not authenticated,
-or is authenticated with a different key, then it SHOULD be ignored.
+If an announcement is received containing an authentication header
+and the cached announcement did not contain an authentication header,
+or it contained a different authentication header, then the modified
+announcement MUST be treated as a new and different announcement,
+and displayed in addition to the un-authenticated announcement.  The
+same should happen if a modified packet without an authentication
+header is received from a different source than the original announcement.
+These rules prevent an announcement having an authentication header
+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.
 
-7  Packet Format
+6  Packet Format
 
-SAP data packets have the format described in figure 2.
+SAP data packets have the format described in figure 1.
 
 V: Version Number. The version number field MUST be set to 1 (SAPv2
    announcements which use only SAPv1 features are backwards compatible,
    those which use new features can be detected by other means,
    so the SAP version number doesn't need to change).
 
 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
    source contains 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 the T field is set to 0 this is a session announcement
    packet, if 1 this is a session deletion packet.
 
 E: Encryption Bit. If the encryption bit is set to 1, the payload
    of the SAP packet is encrypted and the timeout field MUST be
    added to the packet header.  If this bit is 0 the packet is
    not encrypted and the timeout MUST NOT be present.  See section
-   8 for details of the encryption process.
+    7 for details of the encryption process.
 
 C: Compressed bit. If the compressed bit is set to 1, the payload
    is compressed using the zlib compression algorithm [3].  If the
    payload is to be compressed and encrypted, the compression MUST
    be performed first.
 
 Authentication Length. An 8 bit unsigned quantity giving the number
-   of 32 bit words following the main SAP header that contain authentication
-   data.  If it is zero, no authentication header is present.
+    of 32 bit words following the main SAP header that contain
+    authentication data.  If it is zero, no authentication header
+    is present.
 
 Authentication data containing a digital signature of the packet,
    with length as specified by the authentication length header
-   field.  See section 9 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
    with the originating source, provides a globally unique identifier
    indicating 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 and it MUST be changed if the session description is
    modified.
 
    Earlier versions of SAP used a value of zero to mean that the
    hash should be ignored and the payload should always be parsed.
    This had the unfortunate side-effect that SAP announcers had
    to study the payload data to determine how many unique sessions
    were being advertised, making the calculation of the announcement
    interval more complex that necessary.  In order to decouple the
    session announcement process from the contents of those announcements,
-   SAP announcers SHOULD NOT set the message identifier hash to
-   zero.
+    SAP announcers SHOULD NOT set the message identifier hash to zero.
 
    SAP listeners MAY silently discard messages if the message identifier
    hash is set to zero.
 
 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
-   to zero, else it is an IPv6 address.  The address is stored
-   in network byte order.
+    of the message.  This is an IPv4 address if the A field is set to
+    zero, else it is an IPv6 address.  The address is stored in network
+    byte order.
 
    SAPv0 permitted the originating source to be zero if the message
    identifier hash was also zero.  This practise is no longer legal,
    and SAP announcers SHOULD NOT set the originating source to zero.
    SAP listeners MAY silently discard packets with the originating
    source set to zero.
 
 Timeout. When the session payload is encrypted the detailed timing
    fields in the payload are not available to listeners which are
    not trusted with the decryption key.  Under such circumstances,
@@ -416,47 +371,45 @@
 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,
 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
 section of such a packet will start with an 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 although since there is no negotiation
-in SAP an announcer which chooses to use a session description format
-other than SDP cannot know that the listeners are able to understand
-the announcement.  A proliferation of payload types in announcements
-has the potential to lead to severe interoperability problems, and
-for this reason, the use of non-SDP payloads is NOT RECOMMENDED.
+All implementations MUST support payloads of type `application/sdp' [4].
+Other formats MAY be supported although since there is no negotiation in
+SAP an announcer which chooses to use a session description format other
+than SDP cannot know that the listeners are able to understand the
+announcement.  A proliferation of payload types in announcements has the
+potential to lead to severe 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
 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 is desirable for the payload to be sufficiently small that SAP
-packets do not get fragmented by the underlying network.  Fragmentation
-has a loss multiplier effect, which is known to significantly affect
-the reliability of announcements.  It is RECOMMENDED that SAP packets
-are smaller than 1kByte in length, although if it is known that
-announcements
-
-will use a network with a smaller MTU than this, then that SHOULD
-be used as the maximum recommended packet size.
+It is desirable for the payload to be sufficiently small that SAP packets
+do not get fragmented by the underlying network.  Fragmentation has a loss
+multiplier effect, which is known to significantly affect the reliability
+of announcements.  It is RECOMMENDED that SAP packets are smaller than
+1kByte in length, although if it is known that announcements will use a
+network with a smaller MTU than this, then that SHOULD be used as the
+maximum recommended packet size.
 
-8  Encrypted Announcements
+7  Encrypted Announcements
 
 An announcement is received by all listeners in the scope to which
 it is sent.  If an announcement is encrypted, and many of the receivers
 do not have the encryption key, there is a considerable waste of
 bandwidth since those receivers cannot use the announcement they have
 received.  For this reason, the use of encrypted SAP announcements
 is NOT RECOMMENDED on the global scope SAP group or on administrative
 scope groups which may have many receivers which cannot decrypt those
 announcements.
 
@@ -488,37 +442,35 @@
 problem.
 
 Session announcements that are encrypted with a symmetric algorithm
 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
 pass it on to other users who should not be in possession of such
 a key.  Thus announcements to such a group of key holders cannot
 be assumed to have come from an authorised key holder unless there
 is an appropriate authentication header signed by an authorised key
 holder.  In addition the recipients of such encrypted announcements
-
 cannot be assumed to only be authorised key holders.  Such encrypted
 announcements do not provide any real security unless all of the
 authorised key holders are trusted to maintain security of such session
 directory keys.  This property is shared by the multicast session
 tools themselves, where it is possible for an un-trustworthy member
 of the session to pass on encryption keys to un-authorised users.
 However it is likely that keys used for the session tools will be
 more short lived than those used for session directories.
-
 Similar considerations should apply when session announcements are
 encrypted with an assymetric algorithm, but then it is possible to
 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
 members of the group proves to be un-trustworthy.
 
-9  Authenticated Announcements
+8  Authenticated Announcements
 
 The authentication header can be used for two purposes:
 
   o Verification that changes to a session description or deletion
     of a session are permitted.
 
   o Authentication of the identity of the session creator.
 
 In some circumstances only verification is possible because a certificate
 signed by a mutually trusted person or authority is not available.
@@ -528,41 +480,41 @@
 be sufficient depending on the purpose of the session and the people
 involved.
 
 Clearly the key used for the authentication should not be trusted
 to belong to the session originator unless it has been separately
 authenticated by some other means, such as being certified by a trusted
 third party.  Such certificates are not normally included in an SAP
 header because they take more space than can normally be afforded
 in an SAP packet, and such verification must therefore take place
 by some other mechanism.  However, as certified public keys are normally
-locally cached, authentication of a particular key only has to take
-place once, rather than every time the session directory retransmits
-the announcement.
-
-SAP is not tied to any single authentication mechanism.  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 given in figure 3.  The structure of the format
-specific authentication subheader, using both the PGP and the CMS
-formats, is discussed in sections 9.1 and 9.2 respectively.
-
                      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 3:  Format of the authentication data in the SAP header
+ Figure 2:  Format of the authentication data in the SAP header
+
+locally cached, authentication of a particular key only has to take
+place once, rather than every time the session directory retransmits
+the announcement.
+
+SAP is not tied to any single authentication mechanism.  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 given 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.
 
 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.
 
@@ -574,56 +526,56 @@
     format.  All other values are undefined and SHOULD be ignored.
 
 If a SAP packet is to be compressed or encrypted, this 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 excluded when
 calculating the digitial signature.
 
-9.1 PGP Authentication
+8.1 PGP Authentication
 
 Implementations which support authentication MUST support this format.
 
 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.
 
-9.2 CMS Authentication
+8.2 CMS Authentication
 
 Support for this format is OPTIONAL.
 
 A full description of the Cryptographic Message Syntax can be found
 in [6].  The format specific authentication subheader will, in the
 CMS case, have an ASN.1 ContentInfo type with the ContentType being
 signedData.
 
 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
 the packet.  Inclusion of it within the SignedData type would duplicate
 this data and increase the packet length unnecessarily.  In addition
 this allows recipients with either no interest in the authentication,
-or with no mechanism for checking it, to more easily skip the authentication
-information.
+or with no mechanism for checking it, to more easily skip the
+authentication information.
 
 There SHOULD be only one signerInfo and related fields corresponding
 to the originator of the SAP announcement.  The signingTime SHOUD
 be present as a signedAttribute.  However, due to the strict size
 limitations on the size of SAP packets, certificates and CRLs SHOULD
 NOT be included in the signedData structure.  It is expected that
 users of the protocol will have other methods for certificate and
 CRL distribution.
 
-10 Scalability  and caching
+9  Scalability and caching
 
 SAP is intended 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 no enhanced reliability over UDP. This leads
 to a long startup delay before a complete set of announcements is
 heard by a listener.  This delay is clearly undesirable for interactive
 browsing of announced sessions.
 
 In order to reduce the delays inherent in SAP, it is recommended
@@ -631,26 +583,25 @@
 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 listeners starts, it should contact
 its local proxy to download this information, which is then sufficient
 for it to process future announcements directly, as if it has been
 continually listening.
 
 The protocol by which a SAP listener contacts its local proxy cache
 is not specified here.
 
-11 Security  Considerations
+10 Security  Considerations
 
 SAP contains mechanisms for ensuring integrity of session announcements,
 for authenticating the origin of an announcement and for encrypting
-such announcements (sections 8 and 9).  These mechanisms have not
-
+such announcements (sections 7 and 8).  These mechanisms have not
 yet been subject to suitable peer-review, and this memo should not
 be considered authoritative in this area at this time.
 
 As stated in section 5, if a session modification announcement is
 received that contains a valid authentication header, but which is
 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
 with the same SDP origin information unless the originator of one
 of the session descriptions can be authenticated using a certificate
 signed by a trusted third party.  If this were not done, there would
@@ -730,34 +682,30 @@
 
   o SAPv1 specified gzip compression.  SAPv2 uses zlib (the only
     known implementation of SAP compression used zlib, and gzip compression
     was a mistake).
 
   o SAPv2 provides a more complete specification for authentication.
 
   o SAPv2 allows for non-SDP payloads to be transported.  SAPv1 required
     that the payload was SDP.
 
-  o SAPv2 makes the concept of directory session explicit.
-
 C  Acknowledgments
 
 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.  The idea of using SAP to announce other SAP sessions
-is due to Ross Finlayson.
+and Colin Perkins.
 
 D  Authors' Addresses
 
 Mark Handley <mjh@aciri.org>
 AT&T Center for Internet Research at ICSI,
 International Computer Science Institute,
 1947 Center Street, Suite 600,
 Berkeley, CA 94704, USA
 
 Colin Perkins <c.perkins@cs.ucl.ac.uk>
@@ -779,19 +727,20 @@
 
 [2] J. Callas,  L. Donnerhacke, H. Finney, and R. Thayer.  OpenPGP message
     format, November 1998. RFC2440.
 
 [3] P. Deutsch  and J.-L. Gailly. Zlib compressed data format specification
     version  3.3, May 1996. RFC1950.
 
 [4] M. Handley  and V. Jacobson. SDP: Session Description Protocol, April
     1998. RFC2327.
 
-[5] M. Handley,  D. Thaler, and R. Kermode. Multicast-scope zone
-    announcement  protocol (MZAP)(, February 1999.   Work in progress.
+[5] M. Handley, D. Thaler, and R. Kermode. Multicast-scope zone announcement
+    protocol (MZAP), February 1999.   Work in progress.
 
-[6] R. Housley.  Cryptographic message syntax.  Work in progress,
-    April 1999.  draft-ietf-smime-cms-13.txt.
+[6] R. Housley.  Cryptographic message syntax.  Work in progress, April
+1999.
+    draft-ietf-smime-cms-13.txt.
 
 [7] D. Mayer. Administratively scoped IP multicast, July 1998. RFC2365.
 
 [8] D. Mills. Network time protocol version 3, March 1992.  RFC1305.