Subject: [sipcore] 3265bis and Call-Info

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Feb 2010 07:36:44 +0100

Hi Adam,

The Call-Info header field is missing from the table in section 8.1.

RFC 5367 allows Call-Info in NOTIFY, so I guess we also in the 3265bis table can indicate that it is allowed for NOTIFY. I also think it should be allowed for SUBSCRIBE, because I assume it could be used for similar purposes as in an INVITE.

In addition, I guess we should also see what other headers are not listed.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Fri, 19 Feb 2010 10:42:57 -0600

On 2/2/10 12:36 AM, Christer Holmberg wrote:
> RFC 5367 allows Call-Info in NOTIFY, so I guess we also in the 3265bis 
> table can indicate that it is allowed for NOTIFY. I also think it 
> should be allowed for SUBSCRIBE, because I assume it could be used for 
> similar purposes as in an INVITE.

Okay; I've indicated it as optional for SUBSCRIBE and NOTIFY requests.

>  In addition, I guess we should also see what other headers are not 

That's a pretty herculean task. Here are the header fields we'd need to 
come up with answers for:

Accept-Contact
Accept-Resource-Priority
Answer-Mode
Flow-Timer
History-Info
Identity
Identity-Info
Join
Max-Breadth
Min-SE
P-Access-Network-Info
P-Answer-State
P-Asserted-Identity
P-Associated-URI
P-Called-Party-ID
P-Charging-Function-Addresses
P-Charging-Vector
P-DCS-Trace-Party-ID
P-DCS-OSPS
P-DCS-Billing-Info
P-DCS-LAES
P-DCS-Redirect
P-Early-Media
P-Media-Authorization
P-Preferred-Identity
P-Profile-Key
P-Refused-URI-List
P-Served-User
P-User-Database
P-Visited-Network-ID
Path
Permission-Missing
Priv-Answer-Mode
Privacy
Reason
Refer-Sub
Refer-To
Referred-By
Reject-Contact
Replaces
Request-Disposition
Resource-Priority
Security-Client
Security-Server
Security-Verify
Service-Route
Session-Expires
SIP-ETag
SIP-If-Match
Suppress-If-Match
Target-Dialog
Trigger-Consent

If someone wants to embark on that effort and send text, I'm happy to 
include it in the document. At this point, I'm inclined to remove the 
table 2 stuff altogether as being more harmful than educational.

If we're serious about keeping Table 2 up to date, then we need to 
change IANA procedures to require an update to table 2 every time a new 
method or header field is added. Whoever is adding the new header field 
or method would be required to define its relationship to all the 
defined header fields or methods currently registered. If we don't 
commit to do this, I vote that we abandon the Table 2 approach altogether.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 21 Feb 2010 20:54:07 +0100

Hi, 

>That's a pretty herculean task. Here are the header fields we'd need to come up with answers 
>for:
>
><list of headers>
>
>If someone wants to embark on that effort and send text, I'm happy to include it in the 
>document. At this point, I'm inclined to remove the table 2 stuff altogether as being more 
>harmful than educational.
>
>If we're serious about keeping Table 2 up to date, then we need to change IANA procedures to 
>require an update to table 2 every time a new method or header field is added. Whoever is 
>adding the new header field or method would be required to define its relationship to all the 
>defined header fields or methods currently registered. If we don't commit to do this, I vote 
>that we abandon the Table 2 approach altogether.

We had this discussion a while ago, and it may be good to start it again. I think at least Dean mentioned abandoning Table 2. I talked about having a website instead, which would be easier to keep up to date, but I think the IETF proceures didn't allow that.

For example, I was requested to add a number of missing headers to the INFO draft. However, the INFO draft does not contain all the headers you listed in your reply.

So, I totally agree with you that we need to agree on what to do with Table 2. Maybe something to discuss in Anaheim?

Until then, I guess we could at least make sure that we have the 3261 headers included, and whatever other headers are defined/used in a particular specification.

Regards,

Christer

/a

---

From: Dean Willis <[email-masked]>
Date: Sun, 21 Feb 2010 22:29:48 -0600

On Feb 21, 2010, at 1:54 PM, Christer Holmberg wrote:

>> change IANA procedures to
>> commit to do this, I vote
> We had this discussion a while ago, and it may be good to start it  
> again. I think at least Dean mentioned abandoning Table 2. I talked  
> about having a website instead, which would be easier to keep up to  
> date, but I think the IETF proceures didn't allow that.

Right. for things that one might use a website for, we have IANA  
registries.

One could replace Table 2 with a registry, and have new RFCs update  
that registry.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Feb 2010 08:21:16 -0500

Dean Willis wrote:

> One could replace Table 2 with a registry, and have new RFCs update that 
> registry.

I support this approach.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Feb 2010 19:34:55 +0100

Hi,

I think that idea sounds good also.

What about the table that shows for which methods (requests and/or response types) a header is applicable? Would it be possible to do something similar for that? It would need to be updated whenever a new method is defined (which isn't that often).

Regards,

Christer 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 22. helmikuuta 2010 15:21
To: Dean Willis
Cc: Christer Holmberg; SIPCORE
Subject: Re: [sipcore] 3265bis and Call-Info

I support this approach.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Feb 2010 21:46:49 -0600

[as a participant]

>> One could replace Table 2 with a registry, and have new RFCs update 

Okay. If we go down this path -- and I think it's a little bit crazy -- 
then we'll need to ferret out the correct values for the current header 
fields and methods to set up the initial registry.

Because of the haphazard way we've handled this, the table contains 
substantial gaps. I wrote a script to parse out all the formal Table 2 
expansions from the RFCs that define SIP header fields and SIP methods, 
and merge them into a single view of what has been defined to date. With 
the caveat that this is a lot of data, and something might have been 
missed, here's what it looks like:

Header Field 	Where 	Proxy 	ACK 	BYE 	CAN 	INF 	INV 	MES 	NOT 	OPT 
PRA 	PUB 	REF 	REG 	SUB 	UPD
Accept 	2xx 	
	- 	- 	- 	? 	o 	- 	- 	m* 	- 	- 	- 	o 	- 	o
Accept 	415 	
	- 	c 	- 	? 	c 	m* 	o 	c 	c 	m* 	c 	c 	o 	c
Accept 	R 	
	- 	o 	- 	o 	o 	- 	o 	m* 	o 	o 	o 	o 	o 	o
Accept-Contact 	R 	ar 	o 	o 	o 	o 	o 	o 	o 	o 	o 	? 	o 	- 	o 	o
Accept-Encoding 	2xx 	
	- 	- 	- 	? 	o 	- 	- 	m* 	- 	- 	- 	o 	- 	o
Accept-Encoding 	415 	
	- 	c 	- 	? 	c 	m* 	o 	c 	c 	m* 	c 	c 	o 	c
Accept-Encoding 	R 	
	- 	o 	- 	o 	o 	- 	o 	o 	o 	o 	o 	o 	o 	o
Accept-Language 	2xx 	
	- 	- 	- 	? 	o 	- 	- 	m* 	- 	- 	- 	o 	- 	o
Accept-Language 	415 	
	- 	c 	- 	? 	c 	m* 	o 	c 	c 	m* 	c 	c 	o 	c
Accept-Language 	R 	
	- 	o 	- 	o 	o 	- 	o 	o 	o 	o 	o 	o 	o 	o
Accept-Resource-Priority 	200 	amdr 	- 	o 	o 	o 	o 	o 	o 	o 	o 
o 	o 	o 	o 	o
Accept-Resource-Priority 	417 	amdr 	- 	o 	o 	o 	o 	o 	o 	o 	o 
o 	o 	o 	o 	o
Alert-Info 	180 	
	- 	- 	- 	? 	o 	- 	- 	- 	- 	? 	? 	- 	- 	?
Alert-Info 	R 	
	- 	- 	- 	? 	o 	- 	- 	- 	- 	- 	- 	- 	- 	-
Alert-Info 	r 	
	? 	? 	? 	? 	? 	? 	? 	? 	? 	- 	- 	? 	? 	-
Allow 	2xx 	
	- 	o 	- 	? 	m* 	o 	o 	m* 	o 	? 	? 	o 	o 	o
Allow 	405 	
	- 	m 	- 	o 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m
Allow 	R 	
	- 	o 	- 	? 	o 	o 	o 	o 	o 	o 	? 	o 	o 	o
Allow 	r 	
	- 	o 	- 	? 	o 	o 	o 	o 	o 	o 	? 	o 	o 	o
Allow-Events 	2xx 	
	- 	o 	- 	? 	o 	? 	o 	o 	o 	? 	? 	o 	o 	?
Allow-Events 	489 	
	- 	- 	- 	? 	- 	? 	m 	- 	- 	m 	? 	- 	m 	?
Allow-Events 	R 	
	o 	o 	- 	? 	o 	? 	o 	o 	o 	o 	? 	o 	o 	-
Allow-Events 	r 	
	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	-
Answer-Mode 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	?
Authentication-Info 	2xx 	
	- 	o 	- 	? 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o
Authorization 	R 	
	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o
Call-ID 	c 	r 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m
Call-Info 	R 	ar 	- 	- 	- 	? 	o 	o 	? 	o 	- 	o 	- 	o 	? 	o
Call-Info 	r 	ar 	- 	- 	- 	? 	o 	o 	? 	o 	- 	o 	- 	o 	? 	o
Contact 	1xx 	
	- 	- 	- 	- 	o 	- 	o 	- 	- 	- 	- 	- 	o 	o
Contact 	2xx 	
	- 	- 	- 	- 	m 	- 	o 	o 	- 	- 	m 	o 	m 	m
Contact 	3xx 	
	- 	o 	- 	- 	o 	o 	m 	o 	o 	o 	? 	o 	m 	o
Contact 	485 	
	- 	o 	- 	- 	o 	o 	o 	o 	o 	o 	? 	o 	o 	o
Contact 	R 	
	o 	- 	- 	o 	m 	- 	m 	o 	- 	- 	m 	o 	m 	m
Content-Disposition 	R 	
	o 	o 	- 	? 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o
Content-Disposition 	r 	
	o 	o 	- 	? 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o
Content-Encoding 	R 	
	o 	o 	- 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o
Content-Encoding 	r 	
	o 	o 	- 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o
Content-Language 	R 	
	o 	o 	- 	? 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o
Content-Language 	r 	
	o 	o 	- 	? 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o
Content-Length 	R 	ar 	t 	t 	t 	o 	t 	t 	t 	t 	t 	t 	o 	t 	t 	t
Content-Length 	r 	ar 	t 	t 	t 	o 	t 	t 	t 	t 	t 	t 	o 	t 	t 	t
Content-Type 	R 	
	* 	* 	- 	* 	* 	* 	* 	* 	* 	* 	* 	* 	* 	*
Content-Type 	r 	
	* 	* 	- 	* 	* 	* 	* 	* 	* 	* 	* 	* 	* 	*
CSeq 	c 	r 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m
Date 	R 	a 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o
Date 	r 	a 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o
Encryption 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	?
Error-Info 	300-699 	a 	- 	o 	o 	? 	o 	o 	o 	o 	o 	o 	? 	o 	o 	o
Event 	R 	
	- 	- 	- 	? 	- 	? 	m 	- 	- 	m 	? 	- 	m 	-
Event 	r 	
	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	-
Expires 	R 	
	- 	- 	- 	o 	o 	o 	- 	- 	- 	o 	o 	o 	o 	-
Expires 	r 	
	- 	- 	- 	o 	o 	o 	- 	- 	- 	o 	? 	o 	o 	-
Flow-Timer 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	?
>From 	c 	r 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m
History-Info 	R 	amdr 	- 	- 	- 	- 	o 	o 	o 	o 	- 	o 	o 	o 	o 	-
History-Info 	r 	amdr 	- 	- 	- 	- 	o 	o 	o 	o 	- 	o 	o 	o 	o 	-
Identity 	R 	a 	o 	o 	- 	? 	o 	? 	? 	o 	? 	? 	? 	o 	? 	?
Identity-Info 	R 	a 	o 	o 	- 	? 	o 	? 	? 	o 	? 	? 	? 	o 	? 	?
In-Reply-To 	R 	
	- 	- 	- 	? 	o 	o 	- 	- 	- 	- 	- 	- 	- 	-
In-Reply-To 	r 	
	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	- 	? 	? 	-
Join 	R 	
	- 	- 	- 	- 	o 	- 	- 	- 	- 	- 	- 	- 	- 	-
Max-Breadth 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	?
Max-Forwards 	R 	amr 	m 	m 	m 	o 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m
MIME-Version 	R 	
	o 	o 	- 	? 	o 	? 	o 	o 	o 	o 	o 	o 	o 	o
MIME-Version 	r 	
	o 	o 	- 	? 	o 	? 	o 	o 	o 	o 	o 	o 	o 	o
Min-Expires 	423 	
	- 	- 	- 	? 	- 	? 	- 	- 	- 	m 	? 	m 	m 	?
Min-Expires 	R 	
	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	- 	? 	? 	-
Min-Expires 	r 	
	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	- 	? 	? 	-
Min-SE 	422 	
	- 	- 	- 	? 	m 	? 	- 	- 	- 	? 	? 	- 	- 	m
Min-SE 	R 	amr 	- 	- 	- 	? 	o 	? 	- 	- 	- 	? 	? 	- 	- 	o
Organization 	R 	ar 	- 	- 	- 	o 	o 	o 	- 	o 	- 	o 	o 	o 	o 	o
Organization 	r 	ar 	- 	- 	- 	o 	o 	o 	- 	o 	- 	o 	o 	o 	o 	o
P-Access-Network-Info 	R 	dr 	- 	o 	- 	o 	o 	o 	o 	o 	o 	? 	o 	o 	o 	o
P-Access-Network-Info 	r 	dr 	- 	o 	- 	o 	o 	o 	o 	o 	o 	? 	o 	o 	o 	o
P-Answer-State 	18x 	ar 	- 	- 	- 	? 	o 	? 	? 	- 	? 	? 	? 	- 	- 	?
P-Answer-State 	2xx 	ar 	- 	- 	- 	? 	o 	? 	? 	- 	? 	? 	? 	- 	- 	?
P-Asserted-Identity 	R 	adr 	- 	o 	- 	? 	o 	? 	? 	o 	? 	? 	? 	- 	? 	?
P-Asserted-Identity 	r 	adr 	- 	o 	- 	? 	o 	? 	? 	o 	? 	? 	? 	- 	? 	?
P-Associated-URI 	2xx 	
	- 	- 	- 	? 	- 	? 	? 	- 	? 	? 	? 	o 	? 	?
P-Called-Party-ID 	R 	amr 	- 	- 	- 	- 	o 	o 	- 	o 	- 	? 	o 	- 	o 	-
P-Charging-Function-Addresses 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 
? 	? 	? 	? 	?
P-Charging-Vector 	R 	admr 	- 	o 	- 	o 	o 	o 	o 	o 	o 	? 	o 	o 	o 	o
P-Charging-Vector 	r 	admr 	- 	o 	- 	o 	o 	o 	o 	o 	o 	? 	o 	o 	o 	o
P-DCS-Trace-Party-ID 	R 	dmr 	- 	- 	- 	? 	o 	? 	? 	- 	? 	- 	? 	- 	? 	?
P-DCS-OSPS 	R 	dr 	- 	- 	- 	? 	o 	? 	? 	- 	? 	- 	? 	- 	? 	?
P-DCS-Billing-Info 	R 	admr 	- 	- 	- 	? 	o 	? 	? 	- 	? 	- 	? 	- 	? 	?
P-DCS-Billing-Info 	r 	admr 	- 	- 	- 	? 	o 	? 	? 	- 	? 	- 	? 	- 	? 	?
P-DCS-LAES 	R 	adr 	- 	- 	- 	? 	o 	? 	? 	- 	? 	- 	? 	- 	? 	?
P-DCS-LAES 	r 	adr 	- 	- 	- 	? 	o 	? 	? 	- 	? 	- 	? 	- 	? 	?
P-DCS-Redirect 	R 	adr 	- 	- 	- 	? 	o 	? 	? 	- 	? 	- 	? 	- 	? 	?
P-DCS-Redirect 	r 	adr 	- 	- 	- 	? 	o 	? 	? 	- 	? 	- 	? 	- 	? 	?
P-Early-Media 	18x 	amr 	- 	- 	- 	? 	o 	? 	? 	- 	- 	? 	? 	- 	? 	-
P-Early-Media 	2xx 	amr 	- 	- 	- 	? 	- 	? 	? 	- 	o 	? 	? 	- 	? 	o
P-Early-Media 	R 	amr 	- 	- 	- 	? 	o 	? 	? 	- 	o 	? 	? 	- 	? 	o
P-Media-Authorization 	101-199 	ad 	- 	- 	- 	? 	o 	? 	? 	- 	? 	? 
? 	- 	? 	?
P-Media-Authorization 	2xx 	ad 	- 	- 	- 	- 	o 	? 	- 	- 	o 	? 	? 	- 	- 	o
P-Media-Authorization 	R 	ad 	o 	- 	- 	- 	o 	? 	- 	- 	o 	? 	? 	- 	- 	o
P-Preferred-Identity 	R 	adr 	- 	o 	- 	? 	o 	? 	? 	o 	? 	? 	? 	- 	? 	?
P-Preferred-Identity 	r 	adr 	- 	o 	- 	? 	o 	? 	? 	o 	? 	? 	? 	- 	? 	?
P-Profile-Key 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	?
P-Refused-URI-List 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	?
P-Served-User 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	?
P-User-Database 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	?
P-Visited-Network-ID 	R 	ad 	- 	- 	- 	- 	o 	o 	- 	o 	- 	? 	o 	o 	o 	-
Path 	2xx 	- 	- 	- 	- 	? 	- 	? 	? 	- 	? 	? 	? 	o 	? 	?
Path 	R 	ar 	- 	- 	- 	? 	- 	? 	? 	- 	? 	? 	? 	o 	? 	?
Permission-Missing 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	?
Priority 	R 	ar 	- 	- 	- 	o 	o 	o 	- 	- 	- 	o 	- 	- 	o 	-
Priority 	r 	
	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	-
Priv-Answer-Mode 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	?
Privacy 	R 	amrd 	o 	o 	o 	? 	o 	o 	o 	o 	? 	? 	? 	o 	o 	o
Privacy 	r 	amrd 	o 	o 	o 	? 	o 	o 	o 	o 	? 	? 	? 	o 	o 	o
Proxy-Authenticate 	401 	ar 	- 	o 	o 	? 	o 	o 	? 	o 	o 	o 	o 	o 	? 	o
Proxy-Authenticate 	407 	ar 	- 	m 	- 	o 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m
Proxy-Authorization 	R 	dr 	o 	o 	- 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o
RAck 	R 	
	- 	- 	- 	? 	- 	? 	- 	- 	m 	? 	? 	- 	- 	-
Reason 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	?
Record-Route 	18x 	mr 	- 	o 	o 	? 	o 	? 	? 	o 	o 	? 	o 	- 	? 	o
Record-Route 	2xx 	mr 	- 	o 	o 	o 	o 	? 	o 	o 	o 	? 	o 	- 	o 	o
Record-Route 	R 	ar 	o 	o 	o 	o 	o 	- 	o 	o 	o 	- 	o 	- 	o 	o
Record-Route 	r 	ar 	? 	? 	? 	? 	? 	- 	? 	? 	? 	- 	? 	? 	? 	?
Refer-Sub 	2xx 	
	- 	- 	- 	- 	- 	- 	- 	- 	- 	- 	o 	- 	- 	-
Refer-Sub 	R 	
	- 	- 	- 	- 	- 	- 	- 	- 	- 	- 	o 	- 	- 	-
Refer-To 	R 	
	- 	- 	- 	? 	- 	? 	? 	- 	? 	? 	? 	- 	? 	?
Referred-By 	R 	
	- 	o 	- 	? 	o 	? 	? 	o 	? 	? 	? 	o 	? 	?
Reject-Contact 	R 	ar 	o 	o 	o 	o 	o 	o 	o 	o 	o 	? 	o 	- 	o 	o
Replaces 	R 	
	- 	- 	- 	- 	o 	- 	- 	- 	- 	- 	- 	- 	- 	-
Reply-To 	R 	
	- 	- 	- 	? 	o 	o 	- 	- 	- 	- 	- 	- 	- 	-
Reply-To 	r 	
	- 	- 	- 	? 	o 	o 	- 	- 	- 	- 	- 	- 	- 	-
Request-Disposition 	R 	ar 	o 	o 	o 	o 	o 	o 	o 	o 	o 	? 	o 	o 	o 	o
Require 	R 	ar 	- 	c 	- 	o 	c 	c 	o 	c 	c 	o 	c 	c 	o 	c
Require 	r 	ar 	- 	c 	- 	? 	c 	c 	o 	c 	c 	o 	c 	c 	o 	c
Resource-Priority 	R 	amdr 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o
Response-Key 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	?
Retry-After 	404 	
	- 	o 	o 	o 	o 	? 	o 	o 	o 	o 	o 	o 	o 	o
Retry-After 	413 	
	- 	o 	o 	? 	o 	? 	o 	o 	o 	o 	o 	o 	o 	o
Retry-After 	480 	
	- 	o 	o 	o 	o 	? 	o 	o 	o 	o 	o 	o 	o 	o
Retry-After 	486 	
	- 	o 	o 	o 	o 	? 	o 	o 	o 	o 	o 	o 	o 	o
Retry-After 	4xx 	
	? 	? 	? 	? 	? 	o 	? 	? 	? 	? 	? 	? 	? 	?
Route 	R 	adr 	c 	c 	c 	o 	c 	o 	c 	c 	c 	c 	c 	c 	c 	c
RSeq 	1xx 	
	- 	- 	- 	? 	o 	? 	o 	- 	- 	? 	? 	- 	o 	?
RSeq 	R 	
	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	-
RSeq 	r 	
	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	-
Security-Client 	R 	ard 	- 	o 	- 	? 	o 	o 	o 	o 	? 	? 	? 	o 	o 	o
Security-Server 	421 	
	- 	o 	- 	? 	o 	o 	o 	o 	? 	? 	? 	o 	o 	o
Security-Server 	494 	
	- 	o 	- 	? 	o 	o 	o 	o 	? 	? 	? 	o 	o 	o
Security-Verify 	R 	ard 	- 	o 	- 	? 	o 	o 	o 	o 	? 	? 	? 	o 	o 	o
Server 	r 	
	- 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o
Service-Route 	2xx 	ar 	- 	- 	- 	? 	- 	? 	? 	- 	- 	? 	? 	o 	? 	?
Session-Expires 	2xx 	ar 	- 	- 	- 	? 	o 	? 	- 	- 	- 	? 	? 	- 	- 	o
Session-Expires 	R 	amr 	- 	- 	- 	? 	o 	? 	- 	- 	- 	? 	? 	- 	- 	o
SIP-ETag 	2xx 	
	- 	- 	- 	- 	- 	- 	- 	- 	- 	m 	- 	- 	- 	-
SIP-If-Match 	R 	
	- 	- 	- 	- 	- 	- 	- 	- 	- 	o 	- 	- 	- 	-
Subject 	R 	
	- 	- 	- 	o 	o 	o 	- 	- 	- 	o 	- 	- 	- 	-
Subject 	r 	
	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	-
Subscription-State 	R 	
	- 	- 	- 	? 	- 	? 	m 	- 	- 	? 	? 	- 	- 	-
Subscription-State 	r 	
	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	-
Supported 	2xx 	
	- 	o 	o 	? 	m* 	? 	o 	m* 	o 	o 	o 	o 	o 	o
Supported 	R 	
	- 	o 	o 	? 	m* 	? 	o 	o 	o 	o 	o 	o 	o 	o
Target-Dialog 	R 	- 	- 	- 	- 	- 	o 	- 	- 	- 	- 	- 	o 	- 	o 	-
Timestamp 	R 	
	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o
Timestamp 	r 	
	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o
To 	c 	r 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m
Trigger-Consent 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	? 	?
Unsupported 	420 	
	- 	m 	- 	o 	m 	o 	o 	m 	m 	o 	o 	m 	o 	m
User-Agent 	R 	
	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o
User-Agent 	r 	
	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o
Via 	R 	amr 	m 	m 	m 	? 	m 	m 	? 	m 	? 	m 	? 	m 	? 	m
Via 	rc 	dr 	m 	m 	m 	? 	m 	m 	? 	m 	? 	m 	? 	m 	? 	m
Warning 	r 	
	- 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o 	o
WWW-Authenticate 	401 	ar 	- 	m 	- 	o 	m 	m 	m 	m 	m 	m 	m 	m 	m 	m
WWW-Authenticate 	407 	ar 	- 	o 	- 	? 	o 	o 	? 	o 	? 	o 	o 	o 	? 	o

See all those question marks? Someone needs to come up with actual 
values for each of those cells. Some are going to be pretty easy to 
answer; others will require substantial research and/or debate.

It seems like a lot of effort to me. Are we certain the return on our 
investment of time will be worth it?

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Feb 2010 21:48:17 -0600

Re-sending with a new subject line, since this has almost nothing to do 
with 3265bis any longer. Sorry for the additional noise.

[as a participant]

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Feb 2010 09:48:23 -0500

> investment of time will be worth it?

Isn't it the case that every implementor also has to figure out those 
question marks? (And how consistent are the results when they do so?)

If the answers for each of those question marks aren't easy to find, 
then doesn't that make it even more important to find them? If they 
can't each be defined by citing a particular document and section, then 
I suspect some new normative document will be required to nail them down.

	Thanks,
	Paul

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 24 Feb 2010 11:46:12 -0600

Adam

Thanks for doing this script.  Is it posted anywhere (perhaps on the 
SIPCORE site)?

I use two mail apps, and it looked great in the first app, but not so 
great in the second app.

WRT the topic, I understand this will become something of an 
albatross (wrt the amount of work it'll take and arguments we'll have 
over some of the indications) -- but I believe it will ultimately be useful.

One point that will cause you a little more work in your script, when 
loading this on a webpage, if you could add the specific reference 
RFCs to the right of the columns where each header is defined 
(including updates perhaps) -- this would help. I know some are 
obvious, while others are not to readers/researchers.

James

At 09:48 PM 2/23/2010, Adam Roach wrote:
>Re-sending with a new subject line, since this has almost nothing to 
>do with 3265bis any longer. Sorry for the additional noise.
>
>[as a participant]
>
>>>>We had this discussion a while ago, and it may be good to start 
>>>>it again. I think at least Dean mentioned abandoning Table 2. I 
>>>>talked about having a website instead, which would be easier to 
>>>>keep up to date, but I think the IETF proceures didn't allow that.
>>>
>>>One could replace Table 2 with a registry, and have new RFCs 
>>>update that registry.
>>
>>I support this approach.
>
>Okay. If we go down this path -- and I think it's a little bit crazy 
>-- then we'll need to ferret out the correct values for the current 
>header fields and methods to set up the initial registry.
>
>substantial gaps. I wrote a script to parse out all the formal Table 
>2 expansions from the RFCs that define SIP header fields and SIP 
>methods, and merge them into a single view of what has been defined 
>to date. With the caveat that this is a lot of data, and something 
>might have been missed, here's what it looks like:
>
>Header Field Where Proxy ACK BYE CAN INF INV MES NOT OPT PRA PUB REF 
>REG SUB UPD
>Accept 2xx
>Accept-Resource-Priority 200 amdr - o o o o o o o o o o o o o
>Accept-Resource-Priority 417 amdr - o o o o o o o o o o o o o
>Alert-Info 180
>P-Charging-Function-Addresses ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>P-Media-Authorization 101-199 ad - - - ? o ? ? - ? ? ? - ? ?
>It seems like a lot of effort to me. Are we certain the return on 
>our investment of time will be worth it?
>
>/a
>
>_______________________________________________
>sipcore mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipcore

---

From: Adam Roach <[email-masked]>
Date: Wed, 24 Feb 2010 15:28:44 -0600

> Thanks for doing this script.  Is it posted anywhere (perhaps on the 

With the caveat that it is a completely unstructured mound of esoteric 
and hacked-together perl that I threw together in quite a hurry -- and 
is subsequently in the "write only" category of code readability -- you 
can grab a copy here:

https://svn.resiprocate.org/rep/ietf-drafts/adam/table2/table2.pl

You'll need to update the "$rfc_dir" variable at the top of the script 
to reflect your local copy of the RFC repository. If you don't have a 
local copy of the RFC repository, you can get one quite easily with 
rsync; on any Unix-like operating system (including Cygwin under Windows):

   mkdir -p rfcs; rsync -avz --exclude tar 
ftp.rfc-editor.org::rfcs-text-only rfcs

> obvious, while others are not to readers/researchers.

I've added title attributes to each data element. This allows you to 
hover your mouse over anything in the table to find out where it came 
from. The revised HTML table is here:

https://svn.resiprocate.org/rep/ietf-drafts/adam/table2/table2.html

If we decide to actually do this work, that probably won't be the final 
resting place -- but it's a convenient place for me to put it for now.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Feb 2010 23:09:12 +0100

Hi,

I think we should try to solve the question marks, and I am willing to help in such exercise. We would need to discuss how we set up and divide the work.

For some of the headers, I think the question marks can be solved by reading the specs where they are defined. For example, I think it is rather clear where RSeq and RAck can be used.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 24. helmikuuta 2010 16:48
To: Adam Roach
Cc: SIPCORE
Subject: Re: [sipcore] 3265bis and Call-Info

> investment of time will be worth it?

Isn't it the case that every implementor also has to figure out those question marks? (And how consistent are the results when they do so?)

If the answers for each of those question marks aren't easy to find, then doesn't that make it even more important to find them? If they can't each be defined by citing a particular document and section, then I suspect some new normative document will be required to nail them down.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Feb 2010 23:12:06 +0100

Sent the reply below using the old subject, so re-sending it here:

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 24. helmikuuta 2010 23:29
To: James M. Polk
Cc: SIPCORE
Subject: Re: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info)

> Thanks for doing this script.  Is it posted anywhere (perhaps on the 

With the caveat that it is a completely unstructured mound of esoteric and hacked-together perl that I threw together in quite a hurry -- and is subsequently in the "write only" category of code readability -- you can grab a copy here:

You'll need to update the "$rfc_dir" variable at the top of the script to reflect your local copy of the RFC repository. If you don't have a local copy of the RFC repository, you can get one quite easily with rsync; on any Unix-like operating system (including Cygwin under Windows):

   mkdir -p rfcs; rsync -avz --exclude tar ftp.rfc-editor.org::rfcs-text-only rfcs

> obvious, while others are not to readers/researchers.

I've added title attributes to each data element. This allows you to hover your mouse over anything in the table to find out where it came from. The revised HTML table is here:

If we decide to actually do this work, that probably won't be the final resting place -- but it's a convenient place for me to put it for now.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 24 Feb 2010 18:23:28 -0600

> For some of the headers, I think the question marks can be solved by reading the specs where they are defined. For example, I think it is rather clear where RSeq and RAck can be used.

Yep. I went through and updated the table for the ones that I could 
answer off the top of my head (I think I got them all correct), and the 
table looks a fair bit better now.

Now, we probably still want to audit the table -- I found some pretty 
egregious errors in the information extracted from the documents 
themselves, but the overall starting point doesn't look as bad as I 
thought it would at first.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 24 Feb 2010 18:32:39 -0600

By the way, the green entries are the ones I've entered manually (as 
opposed to extracting from RFCs).

/a

On 2/24/10 6:23 PM, Adam Roach wrote:
>> I think we should try to solve the question marks, and I am willing 
>> to help in such exercise. We would need to discuss how we set up and 
>> divide the work.
>>
>> For some of the headers, I think the question marks can be solved by 
>> reading the specs where they are defined. For example, I think it is 
>> rather clear where RSeq and RAck can be used.
>
> answer off the top of my head (I think I got them all correct), and 
> the table looks a fair bit better now.
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 25 Feb 2010 09:04:18 -0600

I realize that I'm replying to a reply to myself -- but it's been 
pointed out to me that most people don't have CAcert installed as a 
valid root certificate issuer. To avoid SSL warnings, you can get to the 
table here:

http://svn.resiprocate.org/rep/ietf-drafts/adam/table2/table2.html

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Feb 2010 11:05:03 -0500

Adam,

IMO Accept-Contact should be optional for PUBLISH, just as it is for 
virtually everything else except REGISTER. (It doesn't make sense on 
REGISTER because that isn't routed based on contacts.)

OTOH, it really doesn't make sense for in-dialog messages like PRACK, 
UPDATE, INFO, and NOTIFY. I don't know how it got specified as optional 
for those. (Not that it hurts much - it is irrelevant in those contexts.)

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Thu, 25 Feb 2010 10:34:47 -0600

> REGISTER because that isn't routed based on contacts.)

Yep, I think that was a typo. There are probably others. That's why I'm 
highlighting my overrides in green. :)

Fixed it.

/a