Subject: Re: [RAI] SIPCore Charter - draft B

From: Robert Sparks <[email-masked]>
Date: Sun, 5 Apr 2009 12:39:50 -0500

(Going back through the comments so far - didn't see a response to  
this yet)

One of the goals of this effort is to help clear some of the  
bottleneck-like issues we've been having with SIP.
The SIPCORE charter is scoped to focus on the care of the core SIP  
protocol, allowing more work to move to other working groups while  
ensuring architectural consistency of the base protocol itself.

The Hitchhiker's Guide classification was addressing a different and  
more expansive question - the core it talks about includes, for  
instance, SDP and ICE.

RjS

On Mar 25, 2009, at 12:43 AM, Spencer Dawkins wrote:

> Since Jon asked for feedback on the proposed charters, I wanted to  
> say that I was mostly OK with the SIPCORE charter, but I haven't  
> seen a reply to John Elwell's question, which seemed very reasonable.
>
> Why DON'T we use the same definition of "core SIP" in SIPCORE as we  
> did in the Hitchhikers' Guide?
>
> Thanks,
>
> Spencer
>
> ----- Original Message ----- From: "Elwell, John" <[email-masked] 
> >
> To: "Spencer Dawkins" <[email-masked]>; "Cullen Jennings"  
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, March 02, 2009 12:23 PM
> Subject: RE: [RAI] SIPCore Charter - draft B
>
>
> Interestingly, in RFC 5411, RFC 3262 is not considered a core SIP
> specification, but some others are, e.g., RFC 3325, RFC 3327, RFC  
> 3581,
> even RFC 3840! Is it wise to use a definition that differs from what  
> we
> have already published?
>
> John
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Spencer Dawkins
>> Sent: 28 February 2009 03:18
>> To: Cullen Jennings
>> Cc: [email-masked]
>> Subject: Re: [RAI] SIPCore Charter - draft B
>>
>> Hi, Cullen,
>>
>> I was actually thrilled when the Hitchhiker's Guide was approved for
>> publication. Is there an obvious place for work on updates?
>> It sounds like
>> the whole point of SIPCORE is that SIPCORE doesn't (and
>> doesn't need to)
>> know about the rest of the universe. Does ANYONE?
>>
>> (signed) Curious...
>>
>>
>> >
>> > Updated draft for comments,
>> >
>> > Thanks, Cullen & Jon
>> >
>> >
>> > ---------------------------------------
>> > Rev B - Feb 27
>> >
>> >
>> >   The Session Initiation Protocol Core (SIPCore) working group is
>> > chartered to
>> >   maintain and continue the development of the core SIP
>> specifications,
>> > currently
>> >   defined as proposed standard RFCs 3261, 3262, 3263, 3264,
>> and 3265.
>> >
>> >   The SIPCore working group will concentrate on specifications that
>> >   update or replace the core SIP specifications. In this context,
>> >   "update" means replacing or modifying protocol elements
>> in the above
>> >   listed RFCs in ways that would affect most or all
>> implementations of
>> >   those RFCs alone.  Extensions to SIP that add new
>> functionality that
>> >   would not be required of all implementations will be done
>> outside of
>> >   this WG. The process and requirements for such extensions are
>> >   documented in RFC 3427bis, "Change Process for the
>> Session Initiation
>> >   Protocol".
>> >
>> >   The SIPCore working group will concentrate on specifications that
>> >   update or replace the core SIP specifications. In this context,
>> >   "update" means replacing or modifying protocol elements
>> in the above
>> >   listed RFCs in ways that would affect most or all
>> implementations of
>> >   those RFCs alone.  Extensions to SIP that add new
>> functionality that
>> >   would not be required of all implementations will be done
>> outside of
>> >   this WG. The process and requirements for such extensions are
>> >   documented in RFC 3427bis, "Change Process for the
>> Session Initiation
>> >   Protocol".
>> >
>> >   Throughout its work, the group will strive to maintain
>> the basic  model
>> > and
>> >   architecture defined by SIP.  In particular:
>> >
>> >   1.  Services and features are provided end-to-end
>> whenever possible.
>> >
>> >   2.  Reuse of existing Internet protocols and architectures and
>> > integrating
>> >       with other Internet applications is crucial.
>> >
>> >   The primary source of change requirements will be a)
>> interoperability
>> >   problems that stem from ambiguous or under-defined
>> specification,  and
>> > b)
>> >   requirements from other working groups in the RAI Area.
>> >
>> >   Although in general the WG will not work on extensions to SIP, it
>> >   may take on some previous work items from the SIP working group
>> >   to allow for a smooth transition.
>> >
>> >
>> > Goals and Milestones:
>> >
>> >  Feb 2009  Location Conveyance with SIP to IESG (PS)
>> >  Mar 2009  Identify requirements for test matrix to move
>> SIP to Draft
>> > Standard
>> >  Mar 2009  Essential corrections to RFC 3261 (1st batch) to
>> IESG (PS)
>> >  May 2009  Delivering request-URI and parameters to UAS via
>> proxy to  IESG
>> > (PS)
>> >  May 2009  INFO package framework to IESG (PS)
>> >
>> > _______________________________________________
>> > RAI mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/rai
>> >
>>
>>
>> _______________________________________________
>> RAI mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rai
>>
>
>
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 5 Apr 2009 14:52:47 -0500

:-)

This is a very reasonable response.

The reason I posted is that SIP Forum is trying to characterize what we 
actually expect people to support from SIP in SIPconnect/1.1. I was hoping 
that we would be able to use either the definition of "core" from the 
Hitchhiker's Guide or the definition of "core" from the SIPCORE charter, and 
it looks like neither one of those are actually going to work for us. Color 
me surprised :-/

Not IETF's problem to solve, of course.

Spencer

> (Going back through the comments so far - didn't see a response to  this 
> yet)
>
> The Hitchhiker's Guide classification was addressing a different and  more 
> expansive question - the core it talks about includes, for  instance, SDP 
> and ICE.
>
> RjS
>
>> Since Jon asked for feedback on the proposed charters, I wanted to  say 
>> that I was mostly OK with the SIPCORE charter, but I haven't  seen a 
>> reply to John Elwell's question, which seemed very reasonable.
>>
>> Why DON'T we use the same definition of "core SIP" in SIPCORE as we  did 
>> in the Hitchhikers' Guide?
>>
>> Thanks,
>>
>> Spencer
>>
>> specification, but some others are, e.g., RFC 3325, RFC 3327, RFC  3581,
>> even RFC 3840! Is it wise to use a definition that differs from what  we
>> have already published?
>>
>> John
>>