Re: Review of draft-ietf-mmusic-sap-v2-01.txt
Colin Perkins <c.perkins@cs.ucl.ac.uk> Wed, 02 February 2000 00:36 UTC
Return-Path: <owner-confctrl>
Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id QAA03843 for confctrl-outgoing; Tue, 1 Feb 2000 16:36:18 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id QAA03838 for <confctrl@zephyr.isi.edu>; Tue, 1 Feb 2000 16:36:17 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by tnt.isi.edu (8.8.7/8.8.6) with SMTP id QAA10364 for <confctrl@isi.edu>; Tue, 1 Feb 2000 16:36:38 -0800 (PST)
Received: from cperkins-d.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id <g.13443-0@bells.cs.ucl.ac.uk>; Wed, 2 Feb 2000 00:36:05 +0000
Received: from cperkins-d.cs.ucl.ac.uk (localhost [127.0.0.1]) by cperkins-d.cs.ucl.ac.uk (8.9.3/8.8.7) with ESMTP id AAA27347; Wed, 2 Feb 2000 00:21:49 GMT
Message-Id: <200002020021.AAA27347@cperkins-d.cs.ucl.ac.uk>
To: Dave Thaler <dthaler@dthaler.microsoft.com>
cc: confctrl@ISI.EDU
Subject: Re: Review of draft-ietf-mmusic-sap-v2-01.txt
In-Reply-To: Message from Dave Thaler <dthaler@dthaler.microsoft.com> of "Tue, 01 Feb 2000 11:38:30 PST." <200002011938.LAA27292@dthaler.microsoft.com>
Date: Wed, 02 Feb 2000 00:21:49 +0000
From: Colin Perkins <c.perkins@cs.ucl.ac.uk>
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk
--> Dave Thaler writes: >The abstract and introduction specifically say that SAP is >implemented by _clients_. My understanding is that in the >original framework, and in what the authors envision as a "good" solution, >SAP is actually implemented by _servers_, and you have a separate >mechanism to communicate between clients and servers (if they >are implemented as separate processes, unlike sdr). > >If we support SAP, it will likely be on servers not clients (there's >already a diagram in MSDN showing this), and I know there's been talk among >the spec authors that sdr ought to change to do this as well. Hence, >I would like to see both the abstract and the introduction changed to >reflect that current practice is not best practice, and that SAP is >actually intended for server-server communication. Section 10 is >not sufficient to address my concern. The current protoocol is intended to be agnostic in this regard, hence the use of the announcer/listener terminology. Section 9 "Scalability and caching" is to encourage the deployment of servers, and I'd expect another draft to be produced eventually which would describe how those servers can be accessed (which may be a new protocol, or simply a set of recommendations on how to use existing protocols). I'll fix the wording to make this clearer. Colin
- Review of draft-ietf-mmusic-sap-v2-01.txt Dave Thaler
- Re: Review of draft-ietf-mmusic-sap-v2-01.txt Mark Handley
- Re: Review of draft-ietf-mmusic-sap-v2-01.txt Colin Perkins
- Re: Revised SAP draft submitted Colin Perkins
- Re: Revised SAP draft submitted Colin Perkins