Re: [RAI] RAI reorganization

["DRAGE, Keith (Keith)" <[e-mail]>]

This is part of the discussion that Robert was tring to get going at the last SIP meeting, with no real consensus. I suggest not having this thread on RAI.

James said

> Also... IMO -- as useful as 3265 is, I'm not sure SUB/NOT 
> should be mandated for any and every implementation that 
> wants to claim to be *this new (merged) RFC number* 
> compliant, and have some customer ask for proof.
> 
> now, I could be wrong here...
>

If I follow tha argument, we should also pull INVITE into a separate document. There is no reason why all UAs need to support it.

Keith 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of James M. Polk
> Sent: Thursday, February 05, 2009 3:31 AM
> To: Henry Sinnreich; Jon Peterson; [e-mail]
> Subject: Re: [RAI] RAI reorganization
> 
> At 09:06 PM 2/4/2009, Henry Sinnreich wrote:
> >Content-Language: en
> >Content-Type: multipart/alternative;
> >         boundary="_000_C5AFB3D5B32Dhsinnreiadobecom_"
> >
> >This proposal looks very timely and can solve most problems 
> experienced 
> >with SIP today (unless my hopeless optimism is out of place):
> >
> >    * Internet-centric Core SIP – happy to see the IETF 
> works for the 
> > Internet and not for closed networks, legacy emulation, etc.
> >    * Mention of “running code” (is there a way to limit the 
> I-Ds that 
> > don’t have running code and test results?)
> >    * Most of all: Only 5 (five) core SIP RFCs 3261-3265.
> >
> >So  please forgive my naïve question: Why not consolidate the 5 core 
> >SIP RFCs into one single document?
> 
> This seems like the discussion about whether or not to bis 
> 3261, or progress 3261 to DS.  And -- that brings up the idea 
> of just how many other RFCs ought to be folded back into this 
> grand-unifying-doc RFC.
> 
> Also... IMO -- as useful as 3265 is, I'm not sure SUB/NOT 
> should be mandated for any and every implementation that 
> wants to claim to be *this new (merged) RFC number* 
> compliant, and have some customer ask for proof.
> 
> now, I could be wrong here...
> 
> 
> >Here is an example why a single SIP RFC would be beneficial:
> >Metadata on the web enables powerful new services, but requires 
> >reference to a URI, such as a SIP RFC. See 
> ><http://metadata-stds.org/>http://metadata-stds.org/
> >http://en.wikipedia.org/wiki/Extensible_Metadata_Platform
> >SIP referencing in metadata is only one of many problems 
> caused by not 
> >having a single SIP standard document.
> >There are plenty of other.
> >
> >How about having a deliverable a single SIP standard document?
> >
> >Henry
> >
> >
> >On 2/4/09 4:00 PM, "Jon Peterson" 
> ><<[e-mail]>[e-mail]> wrote:
> >
> >
> >
> >Since the open area meeting in Minneapolis, Cullen and I have given 
> >some thought to the best way to try to act on the discussion and 
> >suggested changes. As a continuing part of that process, though 
> >certainly not the last step, we'd like some input from the 
> community on 
> >the following proposal and accompanying draft.
> >
> >We have long heard concerns about the perennially overworked SIP and 
> >SIPPING WGs, to say nothing of the general structure of long-lived 
> >working groups that serve as a standing army to attack 
> problems as they 
> >arise. The main drawback of this structure is that these 
> groups assume 
> >responsibility for rosters of known "hard" problems which seemingly 
> >never complete, while easier and more tactical work struggles for 
> >attention and participate energy gradually depletes. One 
> wouldn't have 
> >to look hard in either of those groups for evidence of this 
> phenomenon.
> >
> >Our proposal is therefore to end the current SIP and SIPPING working 
> >groups and replace them with a different structure. This 
> will include 
> >one continuing long-lived working group called SIPCORE, but 
> unlike SIP, 
> >SIPCORE will have a more narrow mandate of handling only updates or 
> >revisions to the core SIP specifications (which we define here, 
> >somewhat arbitrarily, as RFC3261 through RFC3265). This 
> means that work 
> >previously tied to SIP, such as ongoing security work, would 
> find a new 
> >home in this structure. In this proposal the SIPPING working 
> group will 
> >be replaced by a more radical departure, a working group called 
> >DISPATCH. DISPATCH will function much more like the "open 
> area" groups 
> >one sees in other areas - a forum where new issues and ideas can be 
> >presented. DISPATCH will be tasked with identifying the 
> right venue for 
> >new work in the RAI area; the deliverables of the group 
> might be a BoF 
> >charter or an initial problem statement document, but no 
> protocol work 
> >as such. We hope to use the DISPATCH WG as an incubator for 
> >narrowly-scoped, short duration BoF or working group efforts 
> to solve 
> >particular problems. Ideally, we could emulate structures like the 
> >RTPSEC BoF or the recent P2Pi workshop, both of which were far 
> >lighter-weight than a traditional WG, to address specific 
> issues a more 
> >timely manner than we might have with our previous structure.
> >
> >Since this proposal would require a revision to RFC3427, we 
> have begun 
> >work on one, which can now be found here:
> >
> ><http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-pete
> rson-rai-r
> >fc3427bis-01a.txt>http://svn.resiprocate.org/rep/ietf-drafts/
> fluffy/dra
> >ft-peterson-rai-rfc3427bis-01a.txt
> >
> >(Sorry, we can't submit this yet due to new RFC 5378 rules but will 
> >submit as soon as that gets fixed)
> >
> >In addition to describing the new role of the SIPCORE and 
> DISPATCH WG, 
> >this document also makes a significant change to the header 
> >registration policies, as was recommended in Jonathan's 
> modest-proposal 
> >document. The "P-" header process is deprecated in 
> RFC3427bis in favor 
> >of a more open IANA policy requiring only expert review for 
> >Informational headers - in a nutshell, this means that new proposals 
> >for headers that would have used the "P-" prefix are 
> directed to omit 
> >it, and that these headers can be registered with the IANA 
> without an 
> >Internet-Draft if desired. Note that this does not mean that we will 
> >rename PAID to AID - existing headers will continue as they 
> are, only 
> >the process for new registrations would change. It is hoped 
> that this 
> >change will enable more work to be done at the "edges" of 
> the RAI area 
> >without depending on winning the approval of everyone at the core.
> >
> >Before we undertake any change this radical, however, we'd like some 
> >input from the community about the overall direction. 
> Comments on the 
> >document are also welcome, though do not consider this a last call 
> >review, but more of an overall conceptual read. We do aim to 
> implement 
> >some changes before the end of March, however, to facilitate the 
> >transition to the new Area Director.
> >
> >Cullen & Jon
> >_______________________________________________
> >RAI mailing list
> ><[e-mail]>[e-mail]
> >https://www.ietf.org/mailman/listinfo/rai
> >
> >_______________________________________________
> >RAI mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/rai
> 
> _______________________________________________
> RAI mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rai
>