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

[Keith Drage <[e-mail]>]

To answer your question from my perspective (and others may have further 
reasons)

1)    Maintainability. Every new header field and every new message 
would require some representation of the table, which either needs to 
reproduce the entire table, or explain the extension part relates to the 
existing table. If the entire table is not reproduced, then obviously 
there is not just the RFC 3261 table, but every other table in every 
other specification. If the tables were also made normative, this would 
also raise the question of how many other specifications would need to 
be updated by creating a new specification with a table.

2)    Double specification. The tables are in themselves insufficient. 
In RFC 3261 we have tables, the notes to the tables, and the main text 
all providing data on the use of the headers. I hate double 
specification; right of the start of my standardisation career, in order 
to obtain consensus on a specification, we were forced to change the 
normative part of a specification to align with an incorrect informative 
annex. It is far better to state something clearly only once.

3)    Incomplete specification. The tables are insufficient to 
adequately define the usage. Reliance on the tables therefore encourages 
incomplete specification.

Keith

On 12/05/2020 11:54, Samir Srivastava wrote:
> 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.
>
>  Thanks
> Samir Srivastava
> https://samirsrivastava.typepad.com/
>
> On 5/11/2020 at 9:32 PM, "Keith Drage" 
> <drageke=[e-mail]> 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"
>         <drageke=[e-mail]> 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
>