Subject: RE: [SIP] Proposal for ogranizing WG efforts

From: "Arnoud van Wijk (ELN)" <[email-masked]>
Date: Fri, 2 Mar 2001 13:59:36 +0100

Where would SIP-AAA fit in?
For the rest...if we do want the split..we need to make it very clear what is in which WG then.
Anyway.. I will stay in both.

greetz

Arnoud van Wijk

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: woensdag 28 feb 2001 17:39
To: IETF SIP (E-mail)
Subject: [SIP] Proposal for ogranizing WG efforts

The WG chairs and the ADs were talking this morning about how to make the
working group more effective.One idea that came up sounds interesting, and
I'd like to share it with you.

There are really two sorts of tasks that happen in the WG today:

1) Defining the protocol: SIP and extensions to SIP using its extension
mechanisms.

2) Describing the mechanisms and requirements of doing useful things with
SIP.

Many of the discussions over the past years have started as
application-specific extensions that have pointed toward general-purpose
reusable solutions. For example, Message Waiting Indicator proposals led to
our understanding of the general usefulness of Subscribe/Notify (Events)
mechanisms. We sometimes didn't notice the generalizability of a mechanism
until several iterations into implementation discussions (Refer). We've
started to learn to differentiate our drafts between protocol specifics and
usage rationales. Unfortunately, sometimes the "how could we" discussions
have distracted from the immediate goals of completing the base
specifications. Even the core protocol draft has drawn criticism for
intermixing usage and specification, and the authors have proposed a rewrite
to separate those components.

So here's the idea: What if we were to split the SIP WG into two pieces?
Maybe two WGs?

The first part would handle the actual protocol specifications -- things
like 2543bis, and would deal with new methods, new headers, new response
codes, and other things in response to requirements generated by the second
part. Hard standards-track stuff, tightly controlled charter.

The second part would deal with using SIP, primarily from a
rationale-and-requirements perspective. This would include call flows,
application of SIP mechanisms (like using Events for Message Waiting), and
with things like RFCs to register new  MIME types and DHCP options and the
like. I believe Allison suggested calling such a group the "SIPPING" effort.
Such a group would of course do a lot of discussios and would be likely to
generate several informational  and BCP track documents as well as
standards-track documents where appropriate.

This might let us get a little more clarity in the discussions and
discipline in the process -- and separate some of the topics on the rather
busy mailing list.

So, what do you think?

--
Dean Willis
SIP WG CoChair

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 2 Mar 2001 11:09:21 -0600

Discussion on how to use AAA with SIP and development of requirements would
be in the SIPPING group. Changes to SIP so that it can be used with AAA
would be in the SIP group.

--
Dean

----- Original Message -----
From: "Arnoud van Wijk (ELN)" <[email-masked]>
To: "'Dean Willis'" <[email-masked]>; "IETF SIP (E-mail)"
<[email-masked]>
Sent: Friday, March 02, 2001 6:59 AM
Subject: RE: [SIP] Proposal for ogranizing WG efforts

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 2 Mar 2001 09:08:12 -0800 (PST)

It think the proposal is a great idea, and fully support such a change.

PatC

---

From: Michael Thomas <[email-masked]>
Date: Fri, 2 Mar 2001 09:17:35 -0800 (PST)

> would be in the SIP group.

   Frankly, I think that this one particular area is something
   that should be moved onto the sip security list since it's
   just one piece of the larger problem of what to do for
   security in SIP.

	       Mike