Subject: [Sipping] FW: draft-drage-rai-sip-header-process

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 7 Jul 2008 12:48:43 +0200

I have submitted the following draft and would welcome comments. Please
address any comments to the RAI list at

[email-masked]

And not to these lists.

Regards

Keith 

-----Original Message-----
From: DRAGE, Keith (Keith) 
Sent: Monday, July 07, 2008 11:47 AM
To: [email-masked]
Subject: draft-drage-rai-sip-header-process

I have submitted the following draft:

http://www.ietf.org/internet-drafts/draft-drage-rai-sip-header-process-0
0.txt

I would welcome comments on the proposal.

A new version of I-D, draft-drage-rai-sip-header-process-00.txt has been
successfuly submitted by Keith Drage and posted to the IETF repository.

Filename:	 draft-drage-rai-sip-header-process
Revision:	 00
Title:		 Suggested process changes for handling new SIP headers
and SIP responses
Creation_date:	 2008-07-07
WG ID:		 Independent Submission
Number_of_pages: 12

Abstract:
RFC 3427 currently defines the process for defining and registering new
SIP header fields.  This document proposes that prefixs to header field
names should be discontinued, and that an additional category of
experimental header field should be created.  This document also relaxes
the requirement that response codes are defined by standards track RFCs,
also allowing them to be defined by experimental RFCs.

Regards

Keith
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Jul 2008 16:47:05 -0400

Keith,

I agree with the direction you are going here. The use of P- headers was 
always a problem due to the inability to turn them into standards.

It appears that the portion of your doc related to allowing response 
codes to be defined in experimental RFCs was added as an afterthought. 
Most of the text is about headers, not responses. As a result, there are 
a few inconsistencies in the document:

First: the rules for defining an experimental header in section 3 (which 
will become section 4.2 of the revised document) includes

    2.  The proposed extension MUST NOT define SIP option tags, response
        codes, or methods.

So I guess you can define both headers and response codes in 
experimental documents, but not in the *same* document. :-(

Also: while there is a new column for labeling headers as experimental, 
there seems to be no new column for labeling responses as experimental.

This starts to tie into something that has been bothering me for quite 
awhile:

It is the transition to RFC that causes IANA to update these registries. 
But we know the documents often stay in WG draft stage for extended 
periods of time. During that time it is very difficult for people who 
aren't intimately following the processes to discover these things. And 
with response codes we have ended up with multiple uses of the same value.

Is there some way that we could get these entries made in the IANA 
registries when these are published as WG drafts, with some status code 
that indicates their provisional state?

	Thanks,
	Paul