Subject: [Sip] sips: documentation plan

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Mar 2007 09:29:47 -0400

I left IETF unclear on what our plan was for moving forward on SIPS. I 
stated an opinion at the microphone, which I still firmly believe. That 
is, the current documentation plan, which has us:

1. produce an informational document updating sips
2. produce an extension that makes some normative changes to sips

Only makes a confusing mechanism even more confusing, since now an 
implementor needs to read RFC 3261, then the informative document, then 
the normative one, and somehow patch them all together to come up with 
what sips ACTUALLY does and why.

Given the existing confusion on this mechanism, I think that this would 
be a great disservice to the industry. I think that we are letting our 
process get us trapped in to doing the wrong thing. I think what 
implementors need is a SINGLE DOCUMENT that contains ALL of the text 
around sips, that documenting updating RFC 3261 and re-specifying SIPS 
exactly how we want it.

Our process exists to serve us, not the other way around.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Tue, 27 Mar 2007 18:28:10 +0200

(As WG chair)

The instruction to the editor is to update the document without removing
the information.

The new normative text, the informational stuff, and the bugfixes will
form separate sections in the document, and once we have the -03
version, and agreed that we have everything is in the right category, we
will then decide how to present the content in terms of the number of
documents. 

The split into separate sections is not forcing us down any path. For
the bugfixes, it reflects the need to have a section that reproduces
text from RFC 3261 and indicates that a section has changed. For the new
normative text it reflects the need to gather the UA requirements
together in a subsection separate from the proxy requirements in
accordance with RFC 4485.

Regards

Keith

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Tuesday, March 27, 2007 2:30 PM
> To: IETF SIP List
> Subject: [Sip] sips: documentation plan
> 
> I left IETF unclear on what our plan was for moving forward 
> on SIPS. I stated an opinion at the microphone, which I still 
> firmly believe. That is, the current documentation plan, which has us:
> 
> 1. produce an informational document updating sips 2. produce 
> an extension that makes some normative changes to sips
> 
> Only makes a confusing mechanism even more confusing, since 
> now an implementor needs to read RFC 3261, then the 
> informative document, then the normative one, and somehow 
> patch them all together to come up with what sips ACTUALLY 
> does and why.
> 
> Given the existing confusion on this mechanism, I think that 
> this would be a great disservice to the industry. I think 
> that we are letting our process get us trapped in to doing 
> the wrong thing. I think what implementors need is a SINGLE 
> DOCUMENT that contains ALL of the text around sips, that 
> documenting updating RFC 3261 and re-specifying SIPS exactly 
> how we want it.
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip