Some issues just never go away. :-(
This seems to be a resurection of issues that first surfaced during the
initial discussions of extended presence status many years ago. And it
also harks back to discussions last year or the year before about
communication service identifiers and application service identifiers.
The problem is one of openness. Specifically, do you have to be "part of
the club" in order to properly interoperate with a device that uses
these identifiers to identify its preferences or capabilities.
On one side were those who wanted capabilities and preferences to be
stated in terms of feature tags that are well known and orthogonal. On
the other side were those who prefer to associate arbitrary names to
collections of features and then negotiate on the basis of the names of
those collections.
Using the latter approach its possible that interoperation will fail
because the parties don't share a common name for a collection of
features even though they both possess the necessary features to
interoperate.
I don't have a problem with independent groups defining new feature
tags, as long as they are primitive and orthogonal to existing ones. But
I do have a problem with defining feature tags that identify collections
of features, especially when the mapping from the identifier to the
collection of features is not public.
The bottom line is that I think this sort of thing needs to be thrashed
out within the sip community. So I think the RFC process is the right
process.
Thanks,
Paul
Gonzalo Camarillo wrote:
Folks,
as you know, RFC 3840 specifies how to indicate UA's capabilities using
media feature tags. Section 12.1 of RFC 3840 creates the SIP Media
Feature Tag Registration Tree. Media feature tags applicable to SIP are
registered in this tree.
http://www.ietf.org/rfc/rfc3840.txt
RFC 2506 defines the global tree to register feature tags. Section 3.1.2
of RFC 2506 says: "A registration may be proposed for the global tree by
anyone who has the need to allow for communication on a particular
capability or preference".
http://www.ietf.org/rfc/rfc2506.txt
The currently registered feature tags in both the SIP and the global
trees can be found at:
http://www.iana.org/assignments/media-feature-tags
As you can see, the only three feature tags registered in the global
tree come from 3GPP.
The issue we are facing is that the SIP and the global trees have
different registration policies. The SIP registry requires an RFC
defining the feature tag while the global tree only requires an expert
review.
Now, 3GPP would like to register two new feature tags: g.3gpp.icsi-ref,
g.3gpp.iari-ref
This is the description of how these feature tags will be used:
"Each value of the Application Reference media feature-tag indicates the
software applications supported by the agent. The values for this tag
equal the IMS communication Service Identifier (ICSI) and IMS
Application Reference Identifier (IARI) values supported by
the agent. The Application Reference media feature tag is
defined to fulfil the requirements for forking to an appropriate UE when
multiple UEs are registered and dispatch to an appropriate application
within the UE based upon the IMS communication Service Identifier
(ICSI) and IMS Application Reference Identifier (IARI) values as
stated in 3GPP TS 23.228. Multiple tag-values can be included in the
Application Reference media feature-tag."
The expert reviewer indicated that this tags will not contain simple
features but rather more complex services, or feature sets, or
application logic (pick your favorite term). Therefore, he did not find
it appropriate to register them in the global tree. He suggested that
RFC 2506 is amended so that it covers this type of more complex features.
However, before going down that path, I would like to get comments from
the SIP community. The underlying issue is that we need to decide which
policy we want to apply to these types of registrations in SIP.
1) We decide that an RFC is always needed. Then, we can just use the SIP
registry. We would probably need to clarify or to stress somewhere that
the global tree is not appropriate for SIP tags.
2) We decide that an expert review is good enough. Then we would
probably need to amend RFC 2506 or RFC 3840 to reflect this.
Comments are welcome.
Thanks,
Gonzalo
_______________________________________________
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
