[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RAI] SIPCore Charter - draft B

:-)

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)
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" <john.elwell at siemens.com 
>
To: "Spencer Dawkins" <spencer at wonderhamster.org>; "Cullen Jennings" <FLUFFY at cisco.com> 
Cc: <rai at ietf.org>
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: rai-bounces at ietf.org [mailto:rai-bounces at ietf.org] On
Behalf Of Spencer Dawkins
Sent: 28 February 2009 03:18
To: Cullen Jennings
Cc: rai at ietf.org
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
> RAI at ietf.org
> https://www.ietf.org/mailman/listinfo/rai
>


_______________________________________________
RAI mailing list
RAI at ietf.org
https://www.ietf.org/mailman/listinfo/rai




_______________________________________________
RAI mailing list
RAI at ietf.org
https://www.ietf.org/mailman/listinfo/rai