Re: Status of SAP - particularly compression + authentication

[Colin Perkins <[e-mail]>]

--> Bill Fenner writes:
>
>Is there anyone working on the SAP specification?  I have two issues
>that are not addressed by the November 1996 draft-ietf-mmusic-sap-00.ps,
>which is the most recent specification for SAPv1 that I know of.

I volunteered to act as editor at the last IETF, and hope to get a revised
draft out before the next meeting.

>1) Compression algorithm.  The spec says to use the gzip format
>(RFC 1952).  The gzip format is simply a wrapper for the DEFLATE
>algorithm (RFC 1951), and contains a fairly large header with
>data that's not useful in the context of SAP.  The zlib format
>(RFC 1950) is another wrapper around the DEFLATE algorithm which
>has the following advantages:
>- Smaller header
>- Easier to implement (there's a reference zlib implementation)
>
>In addition, the only program that creates compressed SAP that I know
>of (Real's G2 server) sends zlib format.
>
>Does anyone have any objection to changing the specification to use
>zlib format instead of gzip format?

Seems sensible to me...

>2) Compression + authentication order.  The spec does not explicitly
>say in what order compression and authentication should be performed.
>Since authentication information can be large, it makes sense to
>me to allow it to be part of the compressed payload, but it's
>possible that implementations could choose a different order.
>
>Does anyone have any objections to specifying that the order of
>operations for transmission is authenticate, compress, encrypt,
>and the order for reception is decrypt, uncompress, authenticate?

Again, seems okay.

>On the larger issue of the SAP spec itself, is it appropriate to
>try to make these changes in the 2.5 year old SAPv1 spec and
>maybe advance it, or should we incorporate all of the missing
>info into the SAPv2 spec and focus efforts there?

I was aiming for a merger of the two documents, since the v2 spec is
backwards compatible anyway.

Cheers,
Colin