Hello To use one registration policy for all kind of feature tags may be a "one size fits all" policy that in my view can lead to unnecessary bottlenecks and delays. Personally I find it useful how RFC 2506 describe various mechanisms for registration of feature tags, and think the current approach where a feature tag can be specified within one organization and subsequently registered by IANA works well and is a useful approach. At least it worked well for the first tags...
Similar ergistration is also performed for other parameters from IANA, and 3GPP has also "registration procedures" with other organizations as GSMA, TISPAN and OMA for various other parameters as well. In some cases the registration is made by 3GPP and in some cases the registration is made by other organisations. Who act as registrar depends on who "owns" the basic functionality of the parameter. Technical discussions are often held to find a solution, but when the technical discussions are held and a solution is chosen, the registration process is done to register and not to re-open the discussion. 3GPP has three feature tags described in 3GPP specifications and registered in the global tree and three more feature tags described in 3GPP specifications waiting for similar registrations by IANA. It might be useful to distinguish between the possible need for changing the process for registration of future tags and performing registration of tags that are in operation only missing the formal registration. I would assume that the current process is in operation until a new registration policy is available and agreed. Regards Atle Monrad 3GPP CT1 Chairman ______ Atle Monrad Standardisation ST-Ericsson Product Group Mobile Platforms Televeien 1 N-4820, Grimstad Norway www.stericsson.com Office: +47 37 29 30 40 Mobile: +47 45 41 06 65 Fax: +47 37 04 23 70 Email: [email protected] This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interception, unauthorized amendment, tampering and viruses, and we only send and receive emails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Gonzalo Camarillo Sent: 20. mars 2009 11:47 To: sip Subject: [Sip] Policy to register media feature tags 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
