Re: Draft MMUSIC minutes

Dave Thaler <dthaler@dthaler.microsoft.com> Thu, 27 April 2000 18:27 UTC

Return-Path: <owner-confctrl>
Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id LAA00955 for confctrl-outgoing; Thu, 27 Apr 2000 11:27:19 -0700 (PDT)
Received: from venera.isi.edu (venera.isi.edu [128.9.176.32]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA00950 for <confctrl@zephyr.isi.edu>; Thu, 27 Apr 2000 11:27:18 -0700 (PDT)
Received: from dthaler.microsoft.com ([131.107.152.20]) by venera.isi.edu (8.9.3/8.9.3) with ESMTP id LAA28250 for <confctrl@ISI.EDU>; Thu, 27 Apr 2000 11:27:22 -0700 (PDT)
Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id MAA00539; Thu, 27 Apr 2000 12:58:43 -0700 (PDT) (envelope-from dthaler)
From: Dave Thaler <dthaler@dthaler.microsoft.com>
Message-Id: <200004271958.MAA00539@dthaler.microsoft.com>
Subject: Re: Draft MMUSIC minutes
In-Reply-To: <200004271435.QAA15646@bettina.informatik.uni-bremen.de> from Joerg Ott at "Apr 27, 2000 4:34:34 pm"
To: jo@tzi.uni-bremen.de
Date: Thu, 27 Apr 2000 12:58:43 -0700
Cc: confctrl@ISI.EDU
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

> please find below a draft of the minutes of the MMUSIC meeting in Adelaide.

See corrections below.

> 3. SAPv2 (Colin Perkins) 
> ========================
> (draft-ietf-mmusic-sap-v2-06.txt) 
[...]
> The meeting agreed that payload authentication is acceptable, although
> transport authentication is preferable.

Not quite (at least from my recollection).  I thought we agreed that
they were BOTH useful, but serve quite different purposes.  ("Preferable" 
implies either/or.)

> 6. Expressing Source Filters In SDP (Dave Thaler)
> =================================================
> 
> Source filters are needed for single-source sessions in 232/8.  They
> are also needed for other Include-mode sessions.
> 
> Basically the authors want applications getting SDP to be able to
> translate two options: 

Not quite, these are the two choices, and we needed to choose only one.

> * a new addrtype 
> * a new attribute name 
> 
> a warning on the latter: it must be possible to ignore it if it is not

re "must be possible" this is mandated by the SDP specification, it's
not a new requirement.
The note is just a reminder that unrecognized attribute names are ignored.

> understood.   c= and a= lines cannot be intermixed.
> 
> There is a question whether the filter should be a session-level
> attribute.
> 
> Dave presented an example showing the proposed new addrtype.  It was

s/proposed new addrtype/new addrtype alternative/

(We weren't "proposing" both.  We actually proposed only the option, 
but described the alternative of an addrtype for completeness.)

> noted that because this is not backwards compatible, it won't work for
> the exclude mode.
[...]
> SAP is limited to 1 kilobyte payload, which translates to around 15
> IPv6 or 39 IPv4 addresses without compression.  There was a
> suggestion: remove the limit from the specification.  It was noted
> that he knows of no implementation which enforces the limit.
       ^^
s/he/???/
(it wasn't me the presenter, Mark maybe?)

-Dave