We have agreed on the issue of co-author.
But from the mail, you just mentioned "draft-camarillo-sipping-reinvite-00"
as correction of RFC3261.
I'd like to confirm:
whether you want making your two drafts("draft-camarillo-sipping-precons-00"
and "draft-camarillo-sipping-reinvite-00") and mine("draft-gaoyang-sipping-session-state-criterion-03")
as one or making "draft-camarillo-sipping-precons-00"
and "draft-gaoyang-sipping-session-state-criterion-03" as one,
I think making them a whole is better
for the correlation of the two topics. It is just my suggestion, you can
Zip : 210012
Tel : 87211
e_mail : gao.yang2 <at> zte.com.cn
|Gonzalo Camarillo <Gonzalo.Camarillo <at> ericsson.com>
发件人: sipcore-bounces <at> ietf.org
|SIPCORE <sipcore <at> ietf.org>
|[sipcore] Input requested on how to
proceed with the essential corrections to RFC 3261
as you can see in our charter, we have the following milestone:
Sep 2009 - Essential corrections to RFC 3261 (1st batch) to IESG (PS)
The reason why the milestone talks about the "first batch" can
in the following draft:
The draft above talks about RFCs that are updated by tens of RFCs. The
draft claims that having a lot of RFCs updating a given RFC would be
confusing for implementers. At the time of writing the draft above,
there was a belief that RFC 3261 was going to be an example of an RFC
updated by tens of RFCs. The idea in the draft is that instead of
issuing a number of RFCs updating the original one, the WG would put all
those updates together into a batch and publish the batch as a single RFC.
Analyzing the current situation, RFC 3261 has already been updated by
the following RFCs: 3265, 3853, 4320, 4916, 5393
Additionally, there are a few drafts that will, if approved, update RFC
3261 as well:
Draft already with the IESG:
Draft that could be included in the essential corrections process when
their contents are approved:
It turns out that the total number of RFCs updating RFC 3261 has not
grown as much as expected. The number of RFCs documenting essential
corrections (a subset of all the RFCs updating RFC 3261) is also lower
than expected. (From Section 3 of the essential corrections draft, an
essential change is one where in the absence of the correction, it will
not be possible to implement the specification contained in the original
RFC in a manner to ensure interoperability or correct operation.)
The general decision we have to make at this point, given the small
number of drafts documenting essential corrections, is whether we want
to document essential corrections in batches, per the essential
corrections process, or in individual drafts, as it has been done in the
The concrete decision we have to make is whether it makes sense to merge
the following drafts in a batch, per the essential corrections process,
or whether we advance these drafts independently.
We would appreciate the feedback of the WG on this issue so that we can
make progress updating RFC 3261.
sipcore mailing list
sipcore <at> ietf.org
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.