Session Initiation Protocol (SIP) INFO Method and Package Framework
draft-ietf-sipcore-info-events-10

[Ballot comment]
I support Lars' DISCUSS position.

Sec 6.1: Define "Mandatory".  If its meaning is taken from RFC 3291 add something like "Mandatory (as defined in RFC3261) ...."

[Ballot comment]
4.2.2.  UA Procedures

  For backward compatibility purpose, even if a UA indicates support of
  the Info Package mechanism, it is still allowed to enable legacy INFO
  usages Appendix A.

Did you mean to reference Appendix A or Section 9 here?


Suggested change in Section 4.2.3:

OLD:

  Similar to SDP answers, the receiver can include the same Recv-Info
  header field value in multiple responses (18x/2xx) for the same
  INVITE/re-INVITE transaction,
  but the receiver MUST NOT include a
  Recv-Info header field value which is different from a
  value that the receiver has already included in a response for the same
  transaction.

NEW:
  Similar to SDP answers, the receiver can include the same Recv-Info
  header field value in multiple responses (18x/2xx) for the same
  INVITE/re-INVITE transaction,
  but the receiver MUST use the same
  Recv-Info header field value (if included) in all responses for the
  same transaction.

[Ballot discuss]
I've reviewed the document and have a small list of issues I would like to discuss before recommending approval of this document:

1) 10.6.  SIP Option Tags

  The Info Package specification MAY define SIP option tags, which can
  be used as described in [RFC3261].

  The registration requirements for option tags are defined in
  [I-D.peterson-rai-rfc3427bis].

This reference looks Normative, because an INFO package designer might have to comply with it.

2) 10.5.  Info Package Parameters

  NOTE: Info Package parameters defined for specific Info Packages can
  share the name with parameters defined for other Info Packages, but
  the parameter semantics are specific to the Info Package for which
  they are defined.

DISCUSS DISCUSS (will most likely clear once discussed with IESG): Is this actually a good idea?

3) 11.4.  Creation of the Info Packages Registry

  The following data elements populate the Info Package Registry.
  o  Info Package Name: The Info Package Name is a case insensitive
      token.

This is in contradiction with a statement in section 6.2:

That is, the Info Package name is case sensitive.

      In addition, IANA shall not register multiple Info Package
      names that have identical case-insensitive values.

[Ballot comment]
Please consider the Gen-ART Review comments from Brian Carpenter:

  As a newcomer to the topic, I found the guidance on when to choose the
  Info-Package mechanism and when to choose an alternative (Section 7) a
  little weak. I didn't get a strong sense of when it would be clearly
  idiotic to choose Info-Package (except for bulk data transfer). Maybe
  an Informational document on this would be helpful. Otherwise, the
  mechanism seems at some risk of becoming a catch-all for proprietary
  extensions.

[Ballot comment]
In Section 4.2.4, we find the following text:

  If the receiver of a request which contains a Recv-Info header field
  rejects the request, both the sender and receiver of the request MUST
  roll back to the set of Info Packages which was used before the
  request was sent.

This implies that an application must cache the previous Recv-Info data rather than overwriting the old data when it receives the new data. Was this intentional?

In Appendix A, please spell out the acronyms on first use -- I doubt that many people know the identity of technologies like ISUP, QSIG, MSCML, or MSML. Also, does the DTMF usage belong here? (See DISCUSS about putting this information together in one section to motivate the discussion.)

[Ballot discuss]
This is a "discuss-discuss" to air some issues that I'm sure have already been part of the long conversation within the WG.

This document has a dysfunctional relationship with what it labels legacy INFO usage. Given that legacy INFO usage is so widely considered harmful, it would help motivate advancement to Proposed Standard if this document provided a more detailed description of legacy INFO usage and how the WG came to the conclusion that some uses of INFO for exchange of application data are in fact not abusive. The WG summary is quite helpful in this regard and similar text could be included in this document. I would also recommend Appendix A and Section 9 to that same area of the document because right now the discussion is quite fragmented.

I realize that the foregoing is somewhat vague. More specifically, I am concerned about two interrelated issues : (1) interoperability and (2) migration.

1. Regarding interoperability...

1a. In Section 9.2, the following text is potentially misleading:

  Since legacy INFO usages do not have associated Info Packages, it is
  not possible to use the Recv-Info and Info-Package header fields with
  legacy INFO usages.  That is, a UA cannot use the Recv-Info header
  field to indicate for which legacy INFO usages it is willing to
  receive INFO requests, and a UA cannot use the Info-Package header
  field to indicate for which legacy INFO usage an INFO request is
  associated with.

As explained in Section 3.2.2, that is not quite true:

  If a UA receives an INFO request associated with an Info Package that
  the UA has not indicated willingness to receive, the UA MUST send a
  469 (Bad INFO Package) response (see Section 11.6), which contains a
  Recv-Info header field with Info Packages for which the UA is willing
  to receive INFO requests.

It would be clearer to also say in Section 9.2 that UAs can indicate which packages they support by sending a Recv-Info header in error responses and in invites.

1b. In Section 9.2, the following text does not clearly describe how the use of Info-Package overcomes the interoperability problems with legacy INFO:

  Due to the problems described above, legacy INFO usages often require
  static configuration about for what type of applications and contexts
  UAs support the INFO method, and the way they handle application
  information transported in INFO messages.  That has caused
  interoperability problems in the industry.  Therefore, a need for a
  well defined and documented description of what the information sent
  in the INFO is used for has been identified.

Describing how Info-Package solves the interop issues might help motivate migration away from legacy INFO, which I take to be the main reason we're considering this spec in the first place.

2. Regarding migration...

2a. In Section 9.1, the following text is not particulately helpful:

  For backward compatibility purpose, this document does not deprecate
  such usages, and does not mandate users to define Info Packages for
  such usages.  However, any new usage of INFO SHALL use the Info
  Package mechanism defined in this specification.

Unfortunately, we cannot legislate that any new usage of INFO must, shall, will, or ought to use Info-Package.

2b. In Section 9.3, the following text is not strong enough:

  UAs are allowed to enable both legacy INFO usages and Info Package
  usages as part of the same invite dialog usage.

This document needs to more strongly encourage user agents to prefer Info-Package usage over legacy INFO usage (e.g., if you receive Info-Package and legacy in an invite, prefer Info-Package). In general, this document provides few incentives for applications using legacy INFO to migrate toward Info-Package; preferring Info-Package over legacy might help.

[Ballot discuss]
Section 7.3., paragraph 2:
>    Some applications, like sending of DTMF tones, can generate a burst
>    of up to 20 messages per second.  Other applications, like constant
>    GPS location updates, could generate a high rate of INFO requests
>    during the lifetime of the invite dialog usage.
>
>    Furthermore, SIP messages tend to be relatively small, on the order
>    of 500 Bytes to 32K Bytes.  SIP is a poor mechanism for direct
>    exchange of bulk data beyond these limits, especially if the headers
>    plus body exceed the UDP MTU [RFC0768].  Appropriate mechanisms for
>    such traffic include HTTP [RFC2616], MSRP [RFC4975], or other media
>    plane data transport mechanisms.

  DISCUSS: I'd argue that SIP is a poor mechanism for exchanging data
  starting with much less than 32KB of data... But the issue I was going
  to raise is broader: I'm really missing a statement in this document
  that more strongly discourages the sending of frequent or large (and
  especially frequent and large) INFO requests/responses. Folks simply
  need to understand that the reliability and timeliness of SIP
  exchanges can go down in the real world with the size and the rate of
  the messages, if UDP is used, and depending on the path. I thought for
  a while whether I really want to make this a discuss instead of a
  comment, since this issue is a general SIP problem. I decided to make
  this a discuss, because unlike other SIP extensions, this one is
  completely under the control of the applications, and the application
  writers do need to understand the tradeoffs here.

[Ballot comment]
4.2.2.  UA Procedures

  For backward compatibility purpose, even if a UA indicates support of
  the Info Package mechanism, it is still allowed to enable legacy INFO
  usages Appendix A.

Did you mean to reference Appendix A or Section 9 here?

[Ballot discuss]
I've reviewed the document and have a small list of issues I would like to discuss before recommending approval of this document:

1) In Section 4.2.3:

  Similar to SDP answers, the receiver can include the same Recv-Info
  header field value in multiple responses (18x/2xx) for the same
  INVITE/re-INVITE transaction, but the receiver MUST NOT include a
  Recv-Info header field value which is different from a value that the
  receiver has already included in a response for the same transaction.

I admit I might be confused here. Does this contradict the requirement
that the list of Info Packages can be changed by any endpoint (in 4.2.2):

  Once a UA has sent a message with a Recv-Info header field containing
  a set of Info Packages, the set is valid until the UA sends a new
  Recv-Info header field containing a new, or empty, set of Info
  Packages.

?

2) 10.6.  SIP Option Tags

  The Info Package specification MAY define SIP option tags, which can
  be used as described in [RFC3261].

  The registration requirements for option tags are defined in
  [I-D.peterson-rai-rfc3427bis].

This reference looks Normative, because an INFO package designer might have to comply with it.

3) 10.5.  Info Package Parameters

  NOTE: Info Package parameters defined for specific Info Packages can
  share the name with parameters defined for other Info Packages, but
  the parameter semantics are specific to the Info Package for which
  they are defined.

DISCUSS DISCUSS: Is this actually a good idea?

4) 11.4.  Creation of the Info Packages Registry

  The following data elements populate the Info Package Registry.
  o  Info Package Name: The Info Package Name is a case insensitive
      token.

This is in contradiction with a statement in section 6.2:

That is, the Info Package name is case sensitive.

      In addition, IANA shall not register multiple Info Package
      names that have identical case-insensitive values.

IANA comments:

Action #1:

Upon approval of this document, IANA will make the following changes
in the "Methods and Response Codes" registry at
http://www.iana.org/assignments/sip-parameters

OLD:
Methods Reference
------- ---------
INFO [RFC2976]

NEW:
Methods Reference
------- ---------
INFO [RFC-sipcore-info-events-07]


Action #2:

Upon approval of this document, IANA will make the following
assignments in the "Header Fields" registry at
http://www.iana.org/assignments/sip-parameters

Header Name compact Reference
----------------- ------- ---------
Info-Package [RFC-sipcore-info-events-07]
Recv-Info [RFC-sipcore-info-events-07]


Action #3:

Upon approval of this document, IANA will make the following assignment
in the "Response Codes" registry at
http://www.iana.org/assignments/sip-parameters

Response Code Reference
------------------------------------------ ---------
469 Bad INFO Package [RFC-sipcore-info-events-07]


Action #4:

Upon approval of this document, IANA will create the following registry
at http://www.iana.org/assignments/sip-parameters

Registry Name: Info Packages
Registration Procedure: Specification Required

Initial contents of this sub-registry will be:




We understand the above to be the only IANA Actions for this document.

(1.a) Who is the Document Shepherd for this document? Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?

>>>> Adam Roach is the document shepherd. He believes the current
      version of the document represents the consensus of the working
      group, and is ready for publication.

(1.b) Has the document had adequate review both from key WG members
      and from key non-WG members? Does the Document Shepherd have
      any concerns about the depth or breadth of the reviews that
      have been performed?

>>>> This document, in one form or another, has been the topic of
      significant discussion and debate since late 2007. It builds
      on the concepts introduced as early as January of 2003 by
      draft-willis-sip-infopackage, and incorporates many of the
      admonitions and bits of guidance from
      draft-rosenberg-sip-info-harmful and draft-burger-sip-info.
      Nearly 400 email messages have been exchanged on the topic
      since its acceptance into SIPCORE as a working group item
      last summer, on top of the 200+ discussing it in the now
      defunct SIP working group.

      In addition to several normal reviews, the document has
      received a detailed, dedicated review by Vijay Gurbani.

(1.c) Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML?

>>>> The shepherd has no such concerns.

(1.d) Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of? For example, perhaps he
      or she is uncomfortable with certain parts of the document, or
      has concerns whether there really is a need for it. In any
      event, if the WG has discussed those issues and has indicated
      that it still wishes to advance the document, detail those
      concerns here. Has an IPR disclosure related to this document
      been filed? If so, please include a reference to the
      disclosure and summarize the WG discussion and conclusion on
      this issue.

>>>> Please see the "Working Group Summary" provided under (1.k),
      below, for a summary of the discussions the working group
      has had regarding whether a package mechanism for INFO is
      useful.

      No IPR disclosure has been filed in relation to this document
      or any of its predecessor or input documents.


(1.e) How solid is the WG consensus behind this document? Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it?

>>>> The vast majority of active SIP and SIPCORE working group
      participants have been involved in the discussions around
      this document and its mechanisms. It is safe to say that
      this work represents a broad consensus of the working group.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
      discontent? If so, please summarise the areas of conflict in
      separate email messages to the Responsible Area Director. (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)

>>>> No appeal has been threatened, nor has any substantial
      discontent been registered.

(1.g) Has the Document Shepherd personally verified that the
      document satisfies all ID nits? (See the Internet-Drafts Checklist
      and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
      not enough; this check needs to be thorough. Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type and URI type reviews?

>>>> With two exceptions, the document passes nits review. The one
      reference that should be updated at publication time is:

      == Outdated reference: draft-saleem-msml has been published
          as RFC 5707

      The other nits failure is the use of references in the Abstract
      (nits checklist 3.1.b); this issue can be addressed by an RFC
      Editor's note of the form:

        Remove the text "[RFC3265]" from the abstract. Replace
        the text "[RFC2976]" with "RFC 2976" both places it
        appears in the abstract.


(1.h) Has the document split its references into normative and
      informative? Are there normative references to documents that
      are not ready for advancement or are otherwise in an unclear
      state? If such normative references exist, what is the
      strategy for their completion? Are there normative references
      that are downward references, as described in [RFC3967]? If
      so, list these downward references to support the Area
      Director in the Last Call procedure for them [RFC3967].

>>>> Yes, no, N/A, and no.

(1.i) Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body
      of the document? If the document specifies protocol
      extensions, are reservations requested in appropriate IANA
      registries? Are the IANA registries clearly identified? If
      the document creates a new registry, does it define the
      proposed initial contents of the registry and an allocation
      procedure for future registrations? Does it suggest a
      reasonable name for the new registry? See [RFC5226]. If the
      document describes an Expert Review process has Shepherd
      conferred with the Responsible Area Director so that the IESG
      can appoint the needed Expert during the IESG Evaluation?

>>>> Yes, yes, yes, yes, yes, and N/A.

(1.j) Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?

>>>> The ABNF has been run through Bill Fenner's ABNF tool, and
      appears to be valid.

(1.k) The IESG approval announcement includes a Document
      Announcement Write-Up. Please provide such a Document
      Announcement Write-Up? Recent examples can be found in the
      "Action" announcements for approved documents. The approval
      announcement contains the following sections:

    Technical Summary

      This document defines a SIP method, INFO, along with a framework
      for the ways in which various applications can make use of
      this method. It obsoletes the previous definition of INFO,
      provided by RFC 2976, while including backwards-compatibility
      considerations that allow those applications based on RFC
      2976 to continue to operate.

    Working Group Summary

      One of the recurring topics over the course of the development
      of a package mechanism for INFO was whether such a mechanism
      provides any true value.

      RFC 2976 originally defined the SIP INFO method in a scant 9
      pages (including boilerplate). Over time, its use as a catch-all
      for non-standard user-to-user data became recognized as a key
      barrier to interoperability.  For example, many vendors have
      defined their own, proprietary INFO-based mechanism for
      conveying DTMF ("TouchTone") information. However, none of
      these mechanisms have been published (in the IETF, in other
      standards bodies, or even in non-SDO documents), leading to
      severe fragmentation in the ability to convey this type of
      information.

      At the same time, many of the uses of INFO were recognized
      as being shortcuts to more appropriate and flexible mechanisms.
      For example, the conveyance of DTMF cited above is better
      suited to the mechanism defined in RFC 4733 when treated as
      an audio component, while the problem of general key-press
      conveyance is better handled by the mechanisms of RFC 4730.

      As a result of the foregoing, the working group spent significant
      discussion time over many years coming to agreement on whether
      it was more appropriate to fix INFO (by defining a registration
      mechanism for the ways in which it was used) or to deprecate
      it altogether (with the usage described in RFC 3398 being
      grandfathered as the sole legitimate usage).

      Although it required substantial consensus building and
      concessions by those more inclined to completely deprecate
      INFO, the eventual direction of the working group was to
      publish a framework for registration of INFO packages -- if
      for no other reason than to finally conclude the seven-year
      long argument and move on to other issues.


    Document Quality

      The document has been reviewed for quality by several SIPCORE
      participants during the Working Group Last Call period; an
      earlier version of the document received a particularly
      thorough review by Vijay Gurbani.

      It should be noted that the document itself does not directly
      describe a mechanism that can be implemented. It defines a
      framework that requires additional specification before it
      can be implemented. At the time of this publication request,
      no such specifications are under development within the IETF
      (even as individual documents); and the document shepherd is
      not aware of any such specifications under development outside
      the IETF.

    RFC Editors' Note

      Remove the text "[RFC3265]" from the abstract. Replace the
      text "[RFC2976]" with "RFC 2976" both places it appears in
      the abstract.