Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

From: [email-masked] (Dale R. Worley)
Date: Wed, 6 Nov 2013 21:42:52 -0500 (EST)

I think the concept of this draft is useful but not enough thought has
been put into the details of the proposed feature codes.

RFC 6809 says:

   The procedure by which features and capabilities are invoked
   are outside the scope of this specification and MUST be described by
   individual feature-capability indicator specifications.

This implies that we have to make sure we make clear the functional
significance of each FCI.  That sounds obvious, but there is always
the tendency to assume that the meaning of something is obvious and
that "The experienced user will know what is meant."

   For a given fc-value, as defined in Section 6.2.1, the order in which
   feature-capability indicators are listed has no significance.  For
   example, "foo;bar" and "bar;foo" have the same meaning (i.e., that
   the SIP entity that inserted the feature-capability indicator
   supports the features and capabilities associated with the "foo" and
   "bar" feature-capability indicators).

This shows that the implicit (but not stated) conceptual model of FCIs
is that they are independent of each other; there is no significance
to "foo" and "bar" appearing together beyond the semantics of "foo"
and "bar" taken individually.

It appears to me from a brief look that nothing will break if we allow
to be significant whether two FCIs appear together in the same
fc-value (comma-separated clause), but given that was *not* envisioned
in RFC 6809, we should avoid it if we can.

In regard to the draft itself and peoples' comments on it:

    My proposal is that I modify my draft to define that the sip tree
    FCIs are scoped to the entity that inserts them.

Unfortunately, this is un-implementable because the bytes in the SIP
header are not labeled as to which entity inserts them.  The scope
could be "to the fc-value in which it appears", or the "Feature-Cap
header in which it appears".  But the latter violates the rule in RFC
3261:

   Specifically, any SIP header whose grammar is of the form

      header  =  "header-name" HCOLON header-value *(COMMA header-value)

   allows for combining header fields of the same name into a comma-
   separated list.

And the former violates the spirit of RFC 6809 as discussed above.

But at this point in the discussion there is no sign that we need some
sort of scoping.

   RFC 6809 [1] provides that addresses of intermediaries can be
   communicated as a value of an associated feature-capability indicator
   so it would be appropriate to define feature capability indicators as
   part of the global tree to communicate the GRUU of the intermediary
   and hence this is outside the scope of this document.  The feature-
   capability indicators for communicating SIP related capabilities (e.g
   supported SIP Methods and extensions) though need to be registered in
   the SIP tree.

The import of this paragraph is unclear to me.  It appears that the
concept is that an FCI in the sip tree MAY NOT have a value which is
a URI via which the relevant intermediary can be contacted.  But I
know of no such rule.

As far as I can see, feature-capability indicators (RFC 6809) are a
different namespace from media feature tags (RFC 3840).  FCIs have a
different registry
(https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-72),
and the SIP tree part of that registry is empty.  So this draft should
not say "Feature-capability indicator specification reference: RFC
3840", as RFC 3840 defines media feature tags, not feature-capability
indicators.  Indeed, this difference is recognized in the following
paragraph:

   The following media feature tags from RFC 3840 [2], RFC 4235 [10] and
   RFC 5626 [11] are NOT considered to be useful to be defined as
   Feature-Capability indicators:

This assertion may or may not be true, but it seems to me to be
inviting controversy without adding value to the draft.  It would as
effective to simply note that this document does not define the listed
media tags as FCIs -- or even to omit their mention entirely.  If it
turns out to be useful to define them as FCIs, we can do so in another
document.

Getting to the meat of the issue, I think we need to do a more careful
analysis of the functional meaning of the proposed FCIs.  Let us start
by considering +sip.methods.  What can

    Feature-Caps: *;+sip.methods="invite"

mean?  We intuitively say "This intermediary supports/implements
INVITE."  But that isn't really actionable, since we don't send INVITE
*to* the intermediary.  And the statement is actually contrary to the
concept that the default SIP intermediary is a proxy which passes
through *all* methods -- does omitting +sip.methods mean that the
intermediary passes *no* methods?

What we really mean is "This intermediary passes *only* INVITE
requests; all request methods not listed will be rejected."

And that definition has clear functional semantics:  The UA knows that
the set of methods that it can use in the dialog can be determined by
intersecting the values of all of the +sip.methods FCIs and the value
of the Allow header (all of these values taken from any incoming
message).

A similar analysis can be done with +sip.extensions, +sip.events,
+sip.extensions, and +sip.schemes:  If such an FCI is specified, it
means that items of the given type but not in the list in the value
will be removed from SIP requests or will cause the requests to be
rejected.

We can extend this approach to the media feature tags which designate
mime types:

      sip.application
      sip.audio
      sip.text
      sip.video

      sip.control (grandfathered for SIP despite being removed by RFC 4566 sec 8.2.1)
      sip.data    (ditto)

What is needed is a +sip.types FCI which lists the *only* media types
that the intermediary is willing to support.  (And so if the
intermediary media-agnostic, it can simply omit +sip.types.)

If we do not handle all the MIME types as a group, we are stuck with
saying:

    Feature-Cap: *;+sip.audio;+sip.video

and interpreting that grouping to mean "one intermediary admits audio
and video (but nothing else)", which violates the spirit of RFC 6809.

So we want to use:

    Feature-Cap: *;+sip.types="audio,video"

+sip.app-subtype should be defined to list the *only* subtypes of
"application" that the intermediary is willing to pass.

The proposal for +sip.duplex already uses this approach.

+sip.description is curious.  I can see the usefulness of describing
an intermediary, but since each FCI is independent, that may not be
particularly useful information; it is not connected with any other
FCI.

The proposal for +sip.priority already uses this approach, since the
value of the FCI is the minimum priority that will be accepted, i.e.,
it states that all priorities below a given value will be rejected.
But the text does not consistently state this; e.g.

            non-urgent: Integral value of 10.  The device supports non-
            urgent calls.

            normal: Integral value of 20.  The device supports normal
            calls.

            urgent: Integral value of 30.  The device supports urgent
            calls.

            emergency: Integral value of 40.  The device supports calls
            in the case of an emergency situation.

These should be "The device admits calls of non-urgent priority and
above.", etc.

In regard to +sip.isfocus, the definition "This Feature-capability
indicator indicates that the intermediary is a conference server, also
known as a focus, and is capable of mixing together the media for all
calls to the same URI." is what we want, but the term "the
intermediary" is unbound.  What we need to require is that the FCI
contain a string value, "<URI-at-which-to-contact-focus>", which tells
what "the intermediary" is.

In regard to +sip.ice, this functionality is useful, but using it as
an FCI is probably not useful.  If an intermediary terminates media or
filters SDP, it should manipulate the +sip.ice media feature tag in
the Contact header and/or the "ice" option tag in the Supports header
to indicate ICE support.  The reason is that whether the UA can use
ICE is probably determined solely by whichever device exchanges RTP
with it, and for backward compatibility of UAs, UAs should be able to
rely on the previous indicators of whether ICE is supported.

(Although a similar argument could be made that the effect of the
+sip.methods FCI can be implemented by manipulating the Allows header,
and similarly for +sip.types (Content-Type header), +sip.app-subtype
(+sip.app-subtype media feature tag on Contact), and +sip.events
(Allow-Events header).)

In regard to +sip.fax, it seems that although the media feature tag
allows only the values "t38" and "passthrough", the FCI should allow a
list of values, because most or all intermediaries that support fax
will probably support both modes.

More subtly, there probably needs to be a "none" value for +sip.fax to
indicate that fax is not supported (and will be screened out) -- the
token-list value format (tag-value-list in RFC 3840) does not admit a
list of zero tokens.

(And at least in theory, there needs to be a "none" value for
+sip.events.)

Dale