Atle Monrad wrote:
Paul
For you information, the tags that 3gpp have specified and registered
are described in publicly available 3GPP specifications which are
referenced from the IANA registration. The same apply for the three tags
that are in the pipeline. The reason for this is to secure openness and
operability for vendors that want to support certain 3gpp-specific
capabilities.
3GPP would like to get all tags registered by IANA in order to secure
that the tags are public and thereby the reference to the specifications
where this particular 3GPP-functionality is specified is publicly
available.
I agree that is a good thing.
To communicate these tags e-2-e is needed to support certain
3gpp-capabilities, and I do not really see the linkage towards you
statement "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."
I will take that statement back as being based only on old impressions,
not on real facts.
BUT, I still think there is reason to have *some* process to determine
when something is a new independent feature, orthogonal to existing
features, vs. one that turns out to overlap or conflict with existing
features.
For instance, I went and looked up the 3gpp tags that have already been
registered. I found the following in the registration:
g.3gpp.smsip:
This feature-tag indicates that the device is capable of accepting
SMS messages via SIP as specified by ETSI TS 124 341.
Then I went and looked at ETSI TS 124 341, and found:
5.3.3.4 Delivering a short message in a SIP MESSAGE request
If a short message is received from the SMS-GMSC, the IP-SM-GW shall
extract the IMSI of the SM-over-IP receiver from the received message.
Then the IP-SM-GW shall obtain a corresponding public user identity and
deliver a SIP MESSAGE request with the following information:
a) the Request-URI, which shall contain a public user identity of the
SM-over-IP receiver;
b) the Accept-Contact header, which shall contain a "+g.3gpp.smsip"
parameter and the "explicit" and "require" tags according to RFC 3841
[17];
Editor's Note: It is FFS whether the media feature tag value will be
hard coded or it will be an operator specific value distributed as part
of the service provisioning process.
c) the Request-Disposition header which shall contain the "no-fork"
directive;
d) the Content-Type header which shall contain
"application/vnd.3gpp.sms"; and
e) the body of the request which shall contain an RP-DATA message as
defined in 3GPP TS 24.011 [8], including the SMS headers and the SMS
user information encoded as specified in 3GPP TS 23.040 [3].
From a practical perspective, an SMS is pretty much equivalent to a
MESSAGE message. Normally it contains *text*, and could be delivered in
a basic MESSAGE with a body type of text/plain. In that form it could be
received by anything that can handle a basic MESSAGE message.
Yet the above turns the SMS into a *different* feature, that will *only*
be delivered to UAs that support that unique, but non-orthogonal, feature.
Even if SMS's aren't always just text, there are models to handle that
more openly. For instance, multipart/alternative can be used to
represent the message as text for those who only understand text, and as
something richer for those who are capable of understanding that.
My point is not to harp on this feature in particular, but only to use
it as an example. If there were some discussion about new feature tags,
of whether they are unique or could be factored some other way in order
to coexist better with existing features, then the potential for interop
would be improved.
Thanks,
Paul
Hope this clarifies
Regards
/atle
______
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
Paul Kyzivat
Sent: 20. mars 2009 14:42
To: Gonzalo Camarillo
Cc: sip
Subject: Re: [Sip] Policy to register media feature tags
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
_______________________________________________
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
