On The Essentialness of Corrections

Keith has been kind enough to define a process for rolling
up all the  
updates/corrections/revisions to RFC 3261 we might process
in a given  
year into a single document. This process is documented in
draft- 
drage-sip-essential-correction-02. We hope to apply this
same process  
to other RFCs in the core set.

We've recently been having some discussion on what, if any,
drafts  
should be steered into this process vs. conventional
standards and  
BCP tracks.

Let's revisit the rationale for the "essential
corrections" process:  
the idea is to reduce the number of documents that an
implementer  
will have to read in order to produce a correct
implementation of our  
RFCs. Problems and their corrections belong not in a
bug-tracking  
system, but need to be resolved in IETF-published
documents.

I believe that Jonathan sees
draft-ietf-sip-hitchhikers-guide-04 as  
the place where all of the core RFCs, their extensions, and 

corrections thereto are put into a usable order and given
the  
perspective needed to make them work. That's certainly one
way to  
track the relationships between various documents, and I
think we  
need it. But I think we need something else.

There are two primal approaches to updating RFCs. In one,
every  
change is an optional extension to the RFC that might or
might not be  
used. Negotiation mechanisms like option tags are required
for every  
extension, as is fallback behavior to operation without that
 
extension. The nature of the core protocol remains unchanged
--  
perhaps certain modalities are never exercised, but they
remain in  
the specifications as paths that need to be tested for when 

considering compliance against the specifications.

The second approach is to issue revisions that actually
change the  
specification, potentially eliminating or replacing entire
blocks of  
functionality that need no longer be tested, and potentially
 
inserting new behavior that becomes "the standard"
against which  
implementations are judged. The most obvious way to make
these sort  
of changes to an RFC is to issue a new RFC that replaces
(and makes  
obsolete) an older one. IETF also allows new RFCs to
"revise" older  
ones, essentially including them by reference into a new  
specification. The problem with this approach is that it
might be  
possible for many such revisions to be made to a large spec
such as  
RFC 3261, and it then becomes very difficult to effectively
"merge"  
all these changes into a working specification against which
one can  
implement (and test) correctly.

Out "essential corrections" process is an attempt
to manage the  
complexity of many revisions by collecting those revisions
into  
periodic batches and issuing each batch as an RFC that
revises a core  
specification.

The question is: Which, if any, changes need to be processed
as  
extensions and which as revisions?

Here's a test I'd like to propose: If the change is such
that if we  
were re-writing the affected RFC we'd include the new
behavior as  
normative behavior, then we track it as a revision. This
allows us to  
fully deprecate the behavior that it replaces, such that we
no longer  
have to consider the old behavior when compliance testing.
If we  
can't deprecate the replaced behavior, then we really do
have an  
extension (not a revision), and we need an extension
negotiation  
mechanism to know when it can be used or is being used.

I'd actually like to see us go beyond the batching of
"essential  
corrections" and start maintaining complete and
fully-revised  
versions of the normative behaviors as internet drafts,
perhaps  
occasionally publishing them as RFCs that replace the older
versions.  
So for example with RFC 3261, we'd maintain a
"draft-ietf-sip-rfc3261- 
bis" that would start as a copy of RFC 3261 (with
current  
boilerplate, of course) and then be edited to reflect the
changes  
documented in each "essential correction" we agree
to. Then instead  
of telling implementors to go read RFC 3261 plus a dozen
more  
potentially conflicting revision documents, we could just
say "see  
draft-ietf-sip-rfc3261-bis-xx".

--
Dean


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Dean Willis writes:

 > Then instead  
 > of telling implementors to go read RFC 3261 plus a
dozen more  
 > potentially conflicting revision documents, we could
just say "see  
 > draft-ietf-sip-rfc3261-bis-xx".

that sounds like a good idea.  would only corrections go to
the bis
documents or would also clarifications be allowed?

-- juha


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Dean Willis wrote:
> I'd actually like to see us go beyond the batching of
"essential 
> corrections" and start maintaining complete and
fully-revised
> versions of the normative behaviors as internet drafts,
perhaps
> occasionally publishing them as RFCs that replace the
older versions.

We are still talking the sip-essential-correction model
here, right?
Or is what you propose above a new model?

> So for example with RFC 3261, we'd maintain a
> "draft-ietf-sip-rfc3261-bis" that would start
as a copy of RFC 3261
> (with current boilerplate, of course) and then be
edited to reflect
> the changes documented in each "essential
correction" we agree to.
> Then instead of telling implementors to go read RFC
3261 plus a dozen
> more potentially conflicting revision documents, we
could just say
> "see draft-ietf-sip-rfc3261-bis-xx".

Isn't that what we essentially did with rfc2543-bis set of
drafts?
Of course, the domain of influence of SIP back then was a
bit more
limited than it is now.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.al
catel-lucent.com/bell-labs


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

inline:

Dean Willis wrote:

> Here's a test I'd like to propose: If the change is
such that if we were 
> re-writing the affected RFC we'd include the new
behavior as normative 
> behavior, then we track it as a revision. This allows
us to fully 
> deprecate the behavior that it replaces, such that we
no longer have to 
> consider the old behavior when compliance testing. If
we can't deprecate 
> the replaced behavior, then we really do have an
extension (not a 
> revision), and we need an extension negotiation
mechanism to know when 
> it can be used or is being used.

I'm not sure I agree with this. I think we have some
extensions which 
we'd arguably include as, 'things we'd make as new normative
behavior 
that is core to sip'. I personally would have wished that
nat traversal 
were an integral part of sip and if I could do it over,
would not have 
it split out. But clearly ICE and outbound and all that are
not 
essential corrections.

In my mind, the right litmus test is that the new behavior:

   1. cannot be negotiated using the standardized
techniques, AND
   2. represents a change that impacts interoperability with
other 
implementations which might not implement this new behavior

THEN its an essential correction.

THings like BNF bugs are clearly in scope. Something like
record-route 
fix doesn't meet this litmus test because of the second
item. I can 
implement this and fully interoperate with existing
implementations.


> 
> I'd actually like to see us go beyond the batching of
"essential 
> corrections" and start maintaining complete and
fully-revised versions 
> of the normative behaviors as internet drafts, perhaps
occasionally 
> publishing them as RFCs that replace the older
versions. So for example 
> with RFC 3261, we'd maintain a
"draft-ietf-sip-rfc3261-bis" that would 
> start as a copy of RFC 3261 (with current boilerplate,
of course) and 
> then be edited to reflect the changes documented in
each "essential 
> correction" we agree to. Then instead of telling
implementors to go read 
> RFC 3261 plus a dozen more potentially conflicting
revision documents, 
> we could just say "see
draft-ietf-sip-rfc3261-bis-xx".

I thought the idea is that there is just one revision
document 
(essential corrections) and not seven.

I promise you that once you open the floodgates to an
rfc3261 revision 
spec, the temptation to do LOTS of other things to the
document will be 
too great. Clarify this while we're at it? OK. Maybe we
should pull that 
extension in. ANd so on. I don't want to do that. Segmenting
this into 
an essential corrections document keeps pandoras box from
opening.

The amount of work that went into rfc2543 -> rfc3261 was
astoundingly 
large, as any of the editors who basically did this as a
full time job 
for like 6 months will tell you (my boss would ask me when I
was coming 
back to work...). I do not think we as a working group have
or want to 
spend the cycles on such a monumentally large task at this
time.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall
St.
Cisco Fellow                                   Edison, NJ
08837
Cisco, Voice Technology Group
jdrosencisco.com
http://www.jdrosen.net 
                       PHONE: (408) 902-3084
http://www.cisco.com


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

On Dec 14, 2007, at 3:11 PM, Vijay K. Gurbani wrote:

> Dean Willis wrote:
>> I'd actually like to see us go beyond the batching
of "essential  
>> corrections" and start maintaining complete
and fully-revised
>> versions of the normative behaviors as internet
drafts, perhaps
>> occasionally publishing them as RFCs that replace
the older versions.
>
> We are still talking the sip-essential-correction model
here, right?
> Or is what you propose above a new model?

It's the "logical product" of the essential
corrections process.

Each draft in the essential corrections process has to
specify line- 
by-line changes to the RFC it is correcting. If we were to
extract  
those changes and apply them to the source, we would get the
 
"tracking draft" I'm talking about.

>> So for example with RFC 3261, we'd maintain a
>> "draft-ietf-sip-rfc3261-bis" that would
start as a copy of RFC 3261
>> (with current boilerplate, of course) and then be
edited to reflect
>> the changes documented in each "essential
correction" we agree to.
>> Then instead of telling implementors to go read RFC
3261 plus a dozen
>> more potentially conflicting revision documents, we
could just say
>> "see draft-ietf-sip-rfc3261-bis-xx".
>
> Isn't that what we essentially did with rfc2543-bis set
of drafts?
> Of course, the domain of influence of SIP back then was
a bit more
> limited than it is now.
>

Not really. The 2543-bis work was more traditional draft
editing. The  
various editors would get input, make changes to the draft,
then we'd  
review the changes and maybe accept them or back them out or
change  
them again.

In the extended essential corrections process, we'd formally
review  
and reach consensus on each change before committing the
change into  
the -bis document. So every -bis document would reflect WG
consensus  
on the changes at any given time.

--
Dean


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

On Dec 14, 2007, at 4:36 PM, Jonathan Rosenberg wrote:

> inline:
>
> Dean Willis wrote:
>
>> Here's a test I'd like to propose: If the change is
such that if  
>> we were re-writing the affected RFC we'd include
the new behavior  
>> as normative behavior, then we track it as a
revision. This allows  
>> us to fully deprecate the behavior that it
replaces, such that we  
>> no longer have to consider the old behavior when
compliance  
>> testing. If we can't deprecate the replaced
behavior, then we  
>> really do have an extension (not a revision), and
we need an  
>> extension negotiation mechanism to know when it can
be used or is  
>> being used.
>
> I'm not sure I agree with this. I think we have some
extensions  
> which we'd arguably include as, 'things we'd make as
new normative  
> behavior that is core to sip'. I personally would have
wished that  
> nat traversal were an integral part of sip and if I
could do it  
> over, would not have it split out. But clearly ICE and
outbound and  
> all that are not essential corrections.
>
> In my mind, the right litmus test is that the new
behavior:
>
>   1. cannot be negotiated using the standardized
techniques, AND
>   2. represents a change that impacts interoperability
with other  
> implementations which might not implement this new
behavior
>
> THEN its an essential correction.
>
> THings like BNF bugs are clearly in scope. Something
like record- 
> route fix doesn't meet this litmus test because of the
second item.  
> I can implement this and fully interoperate with
existing  
> implementations.

Ok, there's probably a valid argument here. It's important
to note  
also that if something is an "essential
correction", we'd be willing  
to say that an implementation that does not conform to the
correction  
is in violation of the specification and needs to be fixed.
In other  
words, there is the same sort of justification for fixing it
as there  
is for "MUST" in RFC 2119 -- failure to conform
creates a failure to  
interoperate or function correctly.

Now, it's arguable whether the record-route-fix falls into
this  
category or not. Route rewriting, as opposed to double
recording,  
prevents route signing. Is the ability to use route-signing
important  
enough that we'd say that any implementation that precludes
its use  
is "broken"? I'd say that this is the test.


>> I'd actually like to see us go beyond the batching
of "essential  
>> corrections" and start maintaining complete
and fully-revised  
>> versions of the normative behaviors as internet
drafts, perhaps  
>> occasionally publishing them as RFCs that replace
the older  
>> versions. So for example with RFC 3261, we'd
maintain a "draft- 
>> ietf-sip-rfc3261-bis" that would start as a
copy of RFC 3261 (with  
>> current boilerplate, of course) and then be edited
to reflect the  
>> changes documented in each "essential
correction" we agree to.  
>> Then instead of telling implementors to go read RFC
3261 plus a  
>> dozen more potentially conflicting revision
documents, we could  
>> just say "see
draft-ietf-sip-rfc3261-bis-xx".
>
> I thought the idea is that there is just one revision
document  
> (essential corrections) and not seven.

Let's say we roll the 7 changes (I just made that number up,
there  
may be more or less) for 2008 into the 2008 essential
corrections  
RFC. What do we do in 2009? Copy all of the 2008 changes
into the  
2009 RFC? What happens when we've had overlapping changes,
such that  
the same part of the spec has been touched twice? Does the
second  
change need to write step-by-step edits against the base
RFC, or  
against the base RFC as amended by the first change? This
gets hairy,  
and it is made a lot easier if we write the first change
against the  
RFC, apply the first change to the RFC to generate the -bis
spec, and  
then make subsequent corrections bundles against the -bis
spec. This  
gives us a "fully assembled" spec to work against.
Reverse deltas as  
opposed to forward deltas, from a source-code-control
perspective.

> I promise you that once you open the floodgates to an
rfc3261  
> revision spec, the temptation to do LOTS of other
things to the  
> document will be too great. Clarify this while we're at
it? OK.  
> Maybe we should pull that extension in. ANd so on. I
don't want to  
> do that. Segmenting this into an essential corrections
document  
> keeps pandoras box from opening.

I'll certainly agree that a substantial amount of discipline
is  
required in either case.

The question is: Do we want one document an implementor can
go to, or  
do we want a base document plus many "diff"
deltas?

Looking at the bug tracker for RFC 3261, I can see that
there have  
been 85 different bugs filed. While some may not meet the
criteria of  
"essential" (is confusing "excepting"
and "accepting" essential?),  
I'll bet you there are still a lot of things that need
fixing in the  
doc. And RFC 3261 isn't the only spec that needs polishing
-- there  
are over 200 bugs in that tracker.

> The amount of work that went into rfc2543 -> rfc3261
was  
> astoundingly large, as any of the editors who basically
did this as  
> a full time job for like 6 months will tell you (my
boss would ask  
> me when I was coming back to work...). I do not think
we as a  
> working group have or want to spend the cycles on such
a  
> monumentally large task at this time.

I'm not proposing SIP 3.0 here -- just proposing ways to
correct the  
known bugs in our RFCs that produces a result usable by
developers,  
students, other SDOs, and other readers of those RFCs. What
we're  
doing now IS NOT WORKING.

--
Dean




_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Dean Willis writes:

 > The question is: Do we want one document an
implementor can go to, or  
 > do we want a base document plus many "diff"
deltas?

there should be one document that implementor needs to read,
not a base
plus corrections docs.

-- juha


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

On Dec 15, 2007, at 4:03 PM, Juha Heinanen wrote:

> Dean Willis writes:
>
>> The question is: Do we want one document an
implementor can go to, or
>> do we want a base document plus many
"diff" deltas?
>
> there should be one document that implementor needs to
read, not a  
> base
> plus corrections docs.
>
>

Thanks! I know when you agree with something that it's
probably  
technically right. However, it's also usually a sign that
I'm going  
to have a hard time convincing the other folks in the WG
about it!

Have a happy holiday season and new year.

--
dean



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Here's another indication.  I think it should be one
document too.

FM


On Sat, 2007-12-15 at 18:11 -0600, Dean Willis wrote:
> On Dec 15, 2007, at 4:03 PM, Juha Heinanen wrote:
> 
> > Dean Willis writes:
> >
> >> The question is: Do we want one document an
implementor can go to, or
> >> do we want a base document plus many
"diff" deltas?
> >
> > there should be one document that implementor
needs to read, not a  
> > base
> > plus corrections docs.
> >
> >
> 
> Thanks! I know when you agree with something that it's
probably  
> technically right. However, it's also usually a sign
that I'm going  
> to have a hard time convincing the other folks in the
WG about it!
> 
> Have a happy holiday season and new year.
> 
> --
> dean
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

As a further consideration, MMUSIC already seems to be
taking an
approach for SDP similar to Dean's proposal for SIP:
http://www.ietf.org/internet-drafts/draft
-ietf-mmusic-rfc4566bis-00.txt

John

> -----Original Message-----
> From: Dean Willis [mailto:dean.willissoftarmor.com] 
> Sent: 15 December 2007 18:53
> To: Jonathan Rosenberg
> Cc: IETF SIP List
> Subject: Re: [Sip] On The Essentialness of Corrections
> 
> 
> On Dec 14, 2007, at 4:36 PM, Jonathan Rosenberg wrote:
> 
> > inline:
> >
> > Dean Willis wrote:
> >
> >> Here's a test I'd like to propose: If the
change is such that if  
> >> we were re-writing the affected RFC we'd
include the new behavior  
> >> as normative behavior, then we track it as a
revision. 
> This allows  
> >> us to fully deprecate the behavior that it
replaces, such that we  
> >> no longer have to consider the old behavior
when compliance  
> >> testing. If we can't deprecate the replaced
behavior, then we  
> >> really do have an extension (not a revision),
and we need an  
> >> extension negotiation mechanism to know when
it can be used or is  
> >> being used.
> >
> > I'm not sure I agree with this. I think we have
some extensions  
> > which we'd arguably include as, 'things we'd make
as new normative  
> > behavior that is core to sip'. I personally would
have wished that  
> > nat traversal were an integral part of sip and if
I could do it  
> > over, would not have it split out. But clearly ICE
and 
> outbound and  
> > all that are not essential corrections.
> >
> > In my mind, the right litmus test is that the new
behavior:
> >
> >   1. cannot be negotiated using the standardized
techniques, AND
> >   2. represents a change that impacts
interoperability with other  
> > implementations which might not implement this new
behavior
> >
> > THEN its an essential correction.
> >
> > THings like BNF bugs are clearly in scope.
Something like record- 
> > route fix doesn't meet this litmus test because of
the 
> second item.  
> > I can implement this and fully interoperate with
existing  
> > implementations.
> 
> Ok, there's probably a valid argument here. It's
important to note  
> also that if something is an "essential
correction", we'd be willing  
> to say that an implementation that does not conform to
the 
> correction  
> is in violation of the specification and needs to be
fixed. In other  
> words, there is the same sort of justification for
fixing it 
> as there  
> is for "MUST" in RFC 2119 -- failure to
conform creates a failure to  
> interoperate or function correctly.
> 
> Now, it's arguable whether the record-route-fix falls
into this  
> category or not. Route rewriting, as opposed to double
recording,  
> prevents route signing. Is the ability to use
route-signing 
> important  
> enough that we'd say that any implementation that
precludes its use  
> is "broken"? I'd say that this is the test.
> 
> 
> >> I'd actually like to see us go beyond the
batching of "essential  
> >> corrections" and start maintaining
complete and fully-revised  
> >> versions of the normative behaviors as
internet drafts, perhaps  
> >> occasionally publishing them as RFCs that
replace the older  
> >> versions. So for example with RFC 3261, we'd
maintain a "draft- 
> >> ietf-sip-rfc3261-bis" that would start as
a copy of RFC 
> 3261 (with  
> >> current boilerplate, of course) and then be
edited to reflect the  
> >> changes documented in each "essential
correction" we agree to.  
> >> Then instead of telling implementors to go
read RFC 3261 plus a  
> >> dozen more potentially conflicting revision
documents, we could  
> >> just say "see
draft-ietf-sip-rfc3261-bis-xx".
> >
> > I thought the idea is that there is just one
revision document  
> > (essential corrections) and not seven.
> 
> Let's say we roll the 7 changes (I just made that
number up, there  
> may be more or less) for 2008 into the 2008 essential
corrections  
> RFC. What do we do in 2009? Copy all of the 2008
changes into the  
> 2009 RFC? What happens when we've had overlapping
changes, such that  
> the same part of the spec has been touched twice? Does
the second  
> change need to write step-by-step edits against the
base RFC, or  
> against the base RFC as amended by the first change?
This 
> gets hairy,  
> and it is made a lot easier if we write the first
change against the  
> RFC, apply the first change to the RFC to generate the
-bis 
> spec, and  
> then make subsequent corrections bundles against the
-bis spec. This  
> gives us a "fully assembled" spec to work
against. Reverse deltas as  
> opposed to forward deltas, from a source-code-control
perspective.
> 
> > I promise you that once you open the floodgates to
an rfc3261  
> > revision spec, the temptation to do LOTS of other
things to the  
> > document will be too great. Clarify this while
we're at it? OK.  
> > Maybe we should pull that extension in. ANd so on.
I don't want to  
> > do that. Segmenting this into an essential
corrections document  
> > keeps pandoras box from opening.
> 
> I'll certainly agree that a substantial amount of
discipline is  
> required in either case.
> 
> The question is: Do we want one document an implementor
can 
> go to, or  
> do we want a base document plus many "diff"
deltas?
> 
> Looking at the bug tracker for RFC 3261, I can see that
there have  
> been 85 different bugs filed. While some may not meet
the 
> criteria of  
> "essential" (is confusing
"excepting" and "accepting" essential?),
 
> I'll bet you there are still a lot of things that need
fixing in the  
> doc. And RFC 3261 isn't the only spec that needs
polishing -- there  
> are over 200 bugs in that tracker.
> 
> > The amount of work that went into rfc2543 ->
rfc3261 was  
> > astoundingly large, as any of the editors who
basically did 
> this as  
> > a full time job for like 6 months will tell you
(my boss would ask  
> > me when I was coming back to work...). I do not
think we as a  
> > working group have or want to spend the cycles on
such a  
> > monumentally large task at this time.
> 
> I'm not proposing SIP 3.0 here -- just proposing ways
to correct the  
> known bugs in our RFCs that produces a result usable by
developers,  
> students, other SDOs, and other readers of those RFCs.
What we're  
> doing now IS NOT WORKING.
> 
> --
> Dean
> 
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip