Keith,
I'm in the process of trying to revise this before the cutoff on Monday.
I don't agree with one of your points below:
DRAGE, Keith (Keith) wrote:
I guess I got this wrong.
My starting point was a misinterpretation of Jonathan's indication
way back that we were waiting for outbound, gruu and ice before we
pushed this forward.
Right, which I meant as, we won't send this off to IESG until those
drafts are done.
Having thought about this some more:
- Yes we should include internet drafts, but with some sort of
explanation that they are included to encourage early implementation
and demonstrations of interoperability of the protocol, and thus aid
in the standards setting process; also that they identify were the WG
is targetting a solution at a particular problem space and thus aid
work towards a common solution. Additionally a warning that final
IANA assignment of codepoints does not take place until shortly
before publication, and thus codepoint assignments may change.
I will add such a warning.
- No we should not automatically include all WG drafts, but should
assert some form of expert review. We seem to have somewhere up to
25% of working group documents that never make it to completion, and
another fair average that still are not going to be there in the the
next 3 years, judging by past performance. We are never obviously
going to get this 100% right, and I don't think we should spill any
blood arguing about the inclusion or exclusion of any draft, but I do
think we should attempt to preguess this and miss some of these out.
We want the market to try out the drafts in the document, but not get
put off by us marketing to them something that will never fulfil
their product timescales.
I disagree here. Pretty much the only thing in this draft that got
discussed, and agreed upon, was the criteria for draft inclusion. I
really want that criteria to be objective, so we don't need to debate
and whine on every single document. This criteria we spelled out is
captured in the document and it says:
<list style="symbols">
<t>Any specification that defines an extension to SIP
itself, where an extension is a mechanism that changes or updates in
some way a behavior specified in RFC 3261
</t>
<t>Any specification that defines an extension to SDP whose primary
purpose is to support SIP
</t>
<t>Any specification that defines a MIME object whose primary purpose
is to support SIP
</t>
</list>
<t>
Excluded from this list are
requirements, architectures, registry definitions, non-normative
frameworks, and processes. Best Current Practices are included when
they normatively define mechanisms for accomplishing a task.
</t>
I really do not want to revisit this. Based on these rules, I have been
adding every working group document that meets the criteria above. Period.
- Yes we should include some author drafts, probably on the basis
that an AD has sponsored them, or is about to sponsor them, through
the IESG, and certainly if they have reached the RFC editor's queue.
As long as they are AD-sponsored and meet the criteria above, they
should be included. However I am not aware of a single author draft that
meets the above criteria which is AD-sponsored. Indeed I believe the SIP
change process would require a SIP WG item for anything that extends
SIP. If you are aware of any author drafts that meet the criteria above
please let me know.
Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Cisco Fellow Parsippany, NJ 07054-2711
Cisco Systems
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
