Re: [Sip] WGLC on draft-ietf-sip-info-events

[Bob Penfield <BPenfield at acmepacket.com>]

Here are some comments on the INFO draft:

Section 2 says:

   Each UA enumerates which Info Packages it can receive.  If the far
   end indicates it can receive a package offered by the near end, the
   near end can send INFO methods containing the payload for that
   package.

"offered" needs to changed to "supported" since an INFO sender does
not indicate what packages it can send.

Section 3 is called "Info Package Negotiation", but since we removed
Send-Info, it is not a negotiation since there is no feedback from the
peer UA. It is simply a declaration of receive capability. At first
read, I was totally confused by section 3.1 because I was expecting
some actual negotiation given the above statement in Section 2. There
are a few other places in the document that mentions "negotiation"
that also might need to be changed.

I think the usage of UAC/UAS terminology in Section 3.1 is still
confusing. I would prefer to see something like:

   A UA supporting this document MUST advertise the set of Info
   Packages it is willing to receive in Recv-Info header(s) in all
   "INVITE dialog usage" requests and responses (101-199 and 2xx only)
   for dialog establishment or target refresh. This includes INVITE,
   UPDATE, PRACK and ACK and their non-failure responses.

   A UA MUST NOT send INFO requests for a given INFO package until the
   UA has received an "INVITE dialog usage" request or response (for
   dialog establishment or target refresh) with a Recv-Info header
   listing the given Info Package.

   A UA MUST cease sending INFO requests for a given INFO package when
   the UA receives an "INVITE dialog usage" request or response (for
   dialog establishment or target refresh) that does not contain a
   Recv-Info header listing the given Info Package.

Section 3.1 - "the target UA may not send form package P"

   s/form/from/

Section 3.1 - "... the other UA in the dial will assume the ..."

  s/dial/dialog/

Section 3.1 - "server MAY terminate the session with a CANCEL or BYE"

  When the "server" is the UAS of the request, CANCEL is not
  appropriate, and BYE would not be appropriate if it is an initial
  INVITE. In this case, the request would need to be rejected. When
  the "server" is the UAC, I don't think CANCEL is appropriate since
  it is the far-end UA of a specific dialog that the UAC has an issue
  with, not all possible UAs in the case of an initial INVITE.

Section 7 - Can Info Packages strengthen "MAY" to "SHOULD"?

Section 8 - Why is the separator between Info-package-name and
Info-package-param a DOT? Shouldn't it be a SEMI? I don't think that
Info-package-param is similar to event-template in 3265. Its more like
event-param.