[sipcore] Deprecation of tabular format of header fields || Was Re: Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined

[Samir Srivastava <[e-mail]>]

Hi Keith Drage,
  The below does not answer reason for deprecating tabular format i.e.
what are things which cannot be captured in tabular format.
 ThanksSamir Srivastavahttps://samirsrivastava.typepad.com/
On 5/11/2020 at 9:32 PM, "Keith Drage"  wrote:                   

	Most header fields are included for a specific purpose entirely      
unassociated with what mesage it is in.     

	i.e. things like 
	-    included because this message creates a dialog     

	-    included because this message ends a dialog     

	-    included becases this message is the request in a      
transaction     

	-    included because this message responds to a transaction     

	-    included because I can include it in any request     

	etc.     

	Those concepts have existed since RFC 3261.
	The exceptions tend to be header fields that are defined along      
with a MESSAGE to carry them, i.e. in the same RFC.     

	I am not suggesting the definers of new messages should not give     
 due consideration, only that in most cases they will not need to     
 add any extra requirements to their new RFC, because all the      
considerations could already be in the header field defining RFC.
	Keith     

	P.S. I would note that you cannot go on the date of publication -    
  many RFCs take years to get through publication request to      
published while others proceed quicker.     
          On 11/05/2020 16:39, Samir Srivastava       wrote:
                                 Hi,         
                    Please find my replies Inline below prefixed with
SS>>         
                  Thanks         Samir Srivastava 
           https://samirsrivastava.typepad.com/         
           On 5/11/2020 at 2:59 AM, "Keith Drage"            wrote:   
       I dont know             whether we reached something we can
formally describe as a 
             decision, but the overall opion was that it should be the
            text that 
             should normatively describe what the requirements were
for             the actions 
             in respect of inclusion in messages. If these tables were
            included, they 
             should be clearly described as informative.
             SS>> I am of the opinion that we need header, message    
        etc in the tabulated form. SIP Parser developers cannot be    
        expected to know the minute details of applicability of the   
         messages and headers etc. SIP architect in the vendor        
    comapnies might be required to give the headers and messages      
      in the tabulated form to SIP Parser developers. If we all       
     agree in the tabulated form as SPEC Writers, it will be good     
       service to the community. What are the difficulties            
considered which made us to deprecate the table format?
             Further, the normative text should be adequately worded
to             encompass the 
             understanding what happened when new messages were
invented             - so rather 
             than specifically listing messages, it should probably
talk             about 
             messages that create a dialog, etc.
             SS>> PUBLISH RFC https://tools.ietf.org/html/rfc3903
                      REFER RFC https://tools.ietf.org/html/rfc3515
                       MESSAGE RFC https://tools.ietf.org/html/rfc3428
               They all were invented before RFC 4028.. They were NOT 
           developed after Session Timers. So it is left because of   
         mistake. 4028bis and RFC does not mention PUBLISH, REFER,    
        MESSAGE in the text anywhere. SUBSCRIBE, NOTIFY, PRACK,       
     CANCEL, REGISTER, OPTIONS are only defined in the table          
  nowhere in text. If the added headers (MIN-SE,            
SEssion-Expires are found in these message should be reject           
 the REQUEST or accept the by following "be lenient what one          
  accepts". Some guideline needs to be specified. 
               Developer of new method need to look each header,
message             etc in their respective RFC. What one can specify
for method             foo for header foobar in advance? 
             Keith
             On 10/05/2020 17:59, Paul Kyzivat wrote:
             > On 5/10/20 9:12 AM, Samir Srivastava wrote:
             >> Hi,
             >>
             >>    The table mentioned in Section 4 in RFC 4028       
     does not contain 
             >> entries for REFER, PUBLISH and MESSAGE methods        
    Below is the table 
             >> from Section 4
             >>
             >>
             >>            
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
             >>     |     Header            
|where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT|
             >>            
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
             >>     |Session-Expires|  R  | amr | - | - | - | o | -   
         | - | - | o | - | 
             >> - |
             >>     |               |     |     |   |   |   |   |     
         |   |   | |   |   |
             >>     |Session-Expires| 2xx | ar  | - | - | - | o | -   
         | - | - | o | - | 
             >> - |
             >>     |               |     |     |   |   |   |   |     
         |   |   | |   |   |
             >>     |Min-SE         |  R  | amr | - | - | - | o | -   
         | - | - | o | - | 
             >> - |
             >>     |               |     |     |   |   |   |   |     
         |   |   | |   |   |
             >>     |Min-SE         | 422 |     | - | - | - | m | -   
         | - | - | m | - | 
             >> - |
             >>            
+---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
             >>
             >>    They are not applicable for these, but it would    
        have been better 
             >> if it is said categorically.
             >
             > IIRC, quite a long time ago it was decided that this   
         table in 3261 was 
             > a bad idea, because it is essentially a summary of     
       normative language 
             > in other sections of the document and is necessarily an
            approximation.
             >
             > After that, other work that updates and extends 3261   
         has been 
             > inconsistent it whether it updates the table or not.
             >
             > What we should be careful of is that the in progress   
         update to session 
             > timers is clear, normatively and expositively,  one way
            or another.
             >
             >     Thanks,
             >     Paul
             >
             > _______________________________________________
             > sipcore mailing list
             > [e-mail]
             > https://www.ietf.org/mailman/listinfo/sipcore
             _______________________________________________
             sipcore mailing list
             [e-mail]
             https://www.ietf.org/mailman/listinfo/sipcore            
          
	_______________________________________________ sipcore mailing list
[e-mail] https://www.ietf.org/mailman/listinfo/sipcore