Subject: [Sip] RE: Table 2 and INFO Packaging -- draft-willis-sip-infopackage- 00

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 14 Jan 2003 19:17:00 -0000

The problem is that these tables are the only place where some of this information appears. By all means find some other mechanism, but the information is still in general necessary.

For example, my comment 5) that the header only applies to a request could quite easily be written in text, but is normally shown only by an "R" in the tables. However it is specified, it still seems to me to be a fairly important bit of information, and if it is not followed could lead to a number of incompatibilities wehre one side provides the information and the other side says it is unnecessary to follow it.

In general, there is a very common pattern to the entries in the tables. One possible solution would be to replace the existing method columns by a set of columns that relate to

-	initial method of dialog
-	target refresh for a dialog
-	subsequent method of dialog
-	method outside dialog

unfortunately ACK and CANCEL seem to have their own special set of inconsistencies with regard to the use of various headers, but this can probably be dealt with entirely in RFC 3261. Similarly REGISTER creates its own problems, but could be dealt with by saying that new headers are handled as "method outside dialog" unless explicit requirements are stated elsewhere.

Such a change would get rid of the 2nd dimension, where the table extends further to the right as new methods are added, and may actually introduce a bit more consistency into the usages.

Note that the where and proxy columns should continue to be used as is.

[Aside - alternatively we could just stop adding new methods and use INFO for everything :-) ]

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: 14 January 2003 18:58
> To: 'Drage, Keith (Keith)'; [email-masked]
> Subject: Table 2 and INFO Packaging -- draft-willis-sip-infopackage-00
> 
> 
> Keith said:
> > 3)	Figure 1 and figure 2 should really be tables rather 
> > than figures, and should show all the methods currently 
> > defined - see RFC 3455 for an example.
> . . . 
> > 5)	In figure 2, surely the Info-Type header only applies 
> > to requests and this should be indicated appropriately, as 
> > only the INFO request can carry the data.
> 
> We have SO got to stop trying to to update these tables. It's a cubic
> expansion problem, and I don't think it's actually possible 
> to get right, as
> new stuff appears between the writing and the publishing.
> 
> Any ideas on alternatives? Can we simply stop tracking this? 
> Does it need to
> be turned into some kind of IANA registry? How could we 
> approach the problem
> if we made it a registry?
> 
> 
> --
> Dean
> 
_______________________________________________
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