RE: Initial draft of mux WG charter
From: Jim Whitehead (ejw@ics.uci.edu)
Date: Mon, Feb 08 1999
From: Jim Whitehead <ejw@ics.uci.edu>
To: Mike Spreitzer <spreitze@parc.xerox.com>
Cc: jg@pa.dec.com, frystyk@w3.org, ietf-http-ng@w3.org
Date: Mon, 8 Feb 1999 13:43:19 -0800
Message-ID: <002801be53ac$0af10300$d115c380@galileo.ics.uci.edu>
Subject: RE: Initial draft of mux WG charter
> > Some items which were missing... A discussion of what is in
> scope, and out of scope.
>
> I had a hard time thinking of scope questions that weren't
> already answered (well, at least, quesitons that I *thought*
> weren't already answered) by the existing text. In particular,
> can you suggest items for an "out of scope" list?
No, but I attributed this to my lack of deep understanding of mux. I don't
know muxing well enough to know how someone could twist the meaning of
muxing to be something other than what you intended. But, for example, I
suspect that one out-of-scope item is muxing across multiple simultaneous
TCP connections between the same endpoints.
> > A list of deliverables.
>
> Ah, interesting. I was thinking of a 1-item list, containing the
> protocol. I had thought that goals documents were not always
> involved in IETF work; that they were needed when the scope was
> sufficiently large and/or contentious that a separate document
> was warranted. For the mux WG, I thought that it had been
> sufficiently thrashed out and agreed upon at IETF-43 that the
> goals statement in the charter would be sufficient. Before
> IETF-43 I heard enough uncertainty about the desirability of a
> mux layer that we were thinking of a separate Applicability
> Statement (or something like that). If the Transport people say
> they still want it, I'd be quite amenable to adding that.
A goals document still makes sense to me, even if it is a thin document. If
the goals are well-understood, then the goals document will be easy to
write, and will be non-contentious. If the goals aren't as well understood
as people thought, then the goals document will expose this, and save time.
It seems to me the existing WebMUX I-D has a good start on the goals
document -- you'd just need to add rationale for each of the goals items.
It also looks like the existing WebMUX I-D has, near the end, a good start
towards a design rationale document. Hopefully this design rationale will
be captured, either in the protocol document, or in a separate document. A
description of the MEMUX specification deliverable would help me know ahead
of time what to expect to find within the protocol specification.
- Jim