[SIPForum-techwg] SIP UA feature set recommendations - refined proposal
Dale R. Worley
dworley at pingtel.com
Tue Jan 10 15:20:02 EST 2006
I just did a first read of Markus' document, and it's very sweet indeed.
The system of putting features into groups, and then dividing groups
into levels of compliance/functionality is a good way of controlling the
complexity of the situation.
I would make the following changes to the way the levels are named:
- Change the names of the groups from "mandatory", "recommended", and
"advanced" to "level 1", "level 2", and "level 3". This gives us room
to add "level 4", etc., if it should turn out to be useful.
- Add a "level 0" into each group, meaning no functionality at all.
This allows us to use this scheme not only for specifying compliance,
but also classifying existing implementations -- e.g., many UAs will be
at level 0 for Instant Messaging. So we could say that the absolute
minimum implementation is level 1 of Core and Real-Time Media, and level
0 for all other areas. But I expect it to be common that Instant
Messaging, Presence, and Conferencing aren't implemented on many UAs.
In regard to the questions Markus asked, my opinions are:
- At this time, I see no reason to specify whether the UA supports a
given operational feature or not (e.g., attended transfer). The users
will see that directly. The critical thing is to specify that the phone
supports the protocol features needed to ensure that *other* UAs can
implement their features. (e.g., INVITE/Replaces is needed in a UA so
*other* UAs can implement attended transfer).
- It seems to me that IPv6 should be counted as another feature set,
with just two settings, "implemented" or "not implemented".
"Implemented" means that all other rated features fully support IPv6.
- RFC 3265 is a normative dependency for all the protocol features that
use subscriptions, but it does not deserve a position of its own, as it
does nothing without one of its dependents.
- Yes, the dependencies are hard to keep straight, but that's the nature
of the reality we are attempting to document.
Dale
More information about the techwg
mailing list