Subject: [Sip] INFO Package (Argh - missed the deadline)

From: Eric Burger <[email-masked]>
Date: Mon, 3 Nov 2008 18:39:54 -0500

Updated INFO Framework draft is here:

http://www.standardstrack.com/ietf/sip/draft-ietf-sip-info-events-01.txt

It will get to the I-D archives when it gets there.

_______________________________________________
Sip mailing list  https://www.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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Nov 2008 20:49:46 -0500

Feedback on the new version. It has addressed most of the problems I had 
with the last one, but introduced some new ones. (But the net progress 
is quite positive.)

I suppose I should split this up into multiple topics. But I want to go 
home.

--------------

Why the introduction of the 'nil' info package?
What was wrong with no token?

--------------

In section 4.1:

    The UAC MUST include the Info-Package header field when it sends an
    INFO request carrying an Info Package.  The Info-Package header field
    value in an INFO request contains a single Info Package token.  If
    the UAC is sending multiple Info Packages in the INFO request, the
    UAC MUST include the appropriate Info-Package headers, one header per
    package, as described below.

So far so good.

                                  If the UAS indicated support for the
    INFO method and Info Packages as described in this document by the
    presence of a Recv-Info header field during negotiation, the token in
    the Info-Package header field value MUST match one of the Info
    Package tokens received in the Recv-Info header field value in the
    received INVITE or dialog modification transaction for the UAS in
    response to the UAC.

The above doesn't quite say all that you mean. It doesn't say that if 
the UAS *did not* indicate support for Info Packages then the UAC MUST 
NOT include an Info-Package header.

                          In other words, one can only send what the
    other end is willing to receive.

The "in other words" recaps a normative statement that isn't made.

                                      The SOLE exception to this rule is
    if the UAC wishes to send an INFO in a legacy usage context.  In this
    case, if the UAS has never offered a Recv-Info header or never
    offered a Recv-Info header with a package of a similar function to
    the legacy INFO usage, the UAC MAY send an INFO without an Info-
    Package header field and a body appropriate to the said legacy usage.

After the other stuff is cleared up, I don't think the above is an 
*exception*, since that stuff has to do with Info-Packages. This is 
really in-addition-to all that other stuff.

The following is an attempt to fix all that:

    The UAC MUST include the Info-Package header field when it sends an
    INFO request carrying an Info Package.  The Info-Package header field
    value in an INFO request contains a single Info Package token.  If
    the UAC is sending multiple Info Packages in the INFO request, the
    UAC MUST include the appropriate Info-Package headers, one header per
    package, as described below. The token in each Info-Package header
    field MUST match one of the Info
    Package tokens received in the Recv-Info header field value in the
    received INVITE or dialog modification transaction for the UAS in
    response to the UAC.  In other words, one can only send what the
    other end is willing to receive.

    The UAC MAY send an INFO in a legacy usage context, that is,
    an INFO without an Info-Package header field, if and only if
    it has never offered a Recv-Info header field naming a package
    of equivalent function within the current dialog. The function
    of the legacy usage context is determined by the Content-Type of
    the INFO message body.

--------------

I'm troubled by the following:

    If the UAS receives an INFO request with a Info-Package the UAC
    advertised with a Send-Info in the last dialog state update and the
    UAS advertised with a Recv-Info and the body of the INFO request is
    an appropriate MIME type for the Info Package, the UAS MUST send a
    200 OK response.

This means that the UAS must support *all* the mime types associated 
with an info package type. That may not be a reasonable assumption for 
all package types. Even if we grant that it should be, another 
versioning issue appears: Version 1 of a package definition specifies 
only mime type X. Version 2 of the package specifies mime types X and Y. 
A UAS that only supports version 1 will have trouble with a version 2 UAC.

I think it would be better to simply permit the UAS to return a 415 error.

--------------

IMO the following isn't quite strong enough:

    The UAS MUST send a 481 Call Leg/Transaction Does Not Exist message
    if the INFO request does not match any existing dialog.

Its also a problem if there is such a dialog, but no 
invite-dialog-usage. How about:

    The UAS MUST send a 481 Call Leg/Transaction Does Not Exist message
    if the INFO request does not match any existing dialog, or if it
    matches an existing dialog that has no INVITE dialog usage.

--------------

In the following:

    For the purposes of matching Info Package types indicated in Send-
    Info or Recv-Info with those in the Info-Package header field value,
    one compares the Info-package-name portion of the Info-package-type
    portion of the "Info-Package" header byte-by-byte with that of the
    same in the "Send-Info" or "Recv-Info" header values.

Is it intended that the comparison be case-sensitive? That is the way it 
reads. But elsewhere the Info-package-type is referred to as a 'token', 
and tokens are case-insensitive. IMO a case-insensitive comparison would 
be more appropriate. Most things in contexts like this are case 
insensitive, so it might be more trouble to parse if its case sensitive 
here.

--------------

    The Info Package MAY allow overlapping (outstanding) INFO requests.
    If the package does not allow overlapping INFO requests, the Info
    Package MUST disclose this in the section describing UA generation of
    INFO requests.

Allowing this on a per-package basis is problematic if multiple info 
packages may be in use within the dialog. If one package doesn't allow 
overlap, then even infos of other types must not be sent so as to 
overlap with it.

--------------

    Each Info Package MUST define a requirement of SHOULD or MUST
    strength which defines an absolute maximum on the rate at which an
    Info Package can generate INFO messages by a UA in a dialog.

Since multiple packages may be in use, and because multiple packages may 
share the same INFO, I think this limit must be the rate at which info 
*packages of this type* are sent.

--------------

    Info-Package        =  "Info-Package" HCOLON Info-package-type
                           [ ";" "cid" "=" token ]

Should be: [ SEMI "cid" "=" token ]

--------------

    Send-Info           =  "Send-Info" HCOLON "nil"
                        /  Info-package-type
                           *( COMMA Info-package-type )
    Recv-Info           =  "Recv-Info" HCOLON "nil"
                        /  Info-package-type
                           *( COMMA Info-package-type )

I'm pretty sure the above doesn't get the precedence right. I think you 
need:

    Send-Info           =  "Send-Info" HCOLON package-list
    Recv-Info           =  "Recv-Info" HCOLON package-list
    package-list        =  nil
                        /  Info-package-type *( COMMInfo-package-type )

Even the above is problematic, because the following is still legal:

    Send-Info: nil
    Send-Info: foo

--------------

Example 10.1 doesn't show body, so doesn't show that cid is needed even 
with a single body.

--------------

That's all for now folks!

	Thanks,
	Paul

Eric Burger wrote:
> ------------------------------------------------------------------------
>