Re: INFO Package (Argh - missed the deadline)
Paul Kyzivat <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
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:
> 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 protected] for questions on current sip
> Use [email protected] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip