Subject: [sipcore] Requesting assist with expert review of media feature tag

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Oct 2015 10:35:46 -0400

I'm the designated expert reviewer for IANA registration of new media 
feature tag values. (Often for use as sip caller capabilities.)

I have a recent request that concerns me. I am inclined to reject it, 
but the decision is subjective, so I would like to have some discussion 
on it first.

The request comes from 3gpp - it has had no action in ietf. It is for 
the media feature tag g.3gpp.nw-init-ussi, with semantics defined in 
3GPP TS 24.390 ("Unstructured Supplementary Service Data (USSD) using IP 
Multimedia (IM) Core Network (CN) subsystem IMS; Stage 3”)

It is the details of how this service is signaled in SIP that troubles 
me. I wrote this up in my initial response. A copy of that message is 
attached. (Including details of the request.) My key concerns from that are:

- it establishes a media-less INVITE dialog, for the purpose of 
exchanging messages in the signaling, primarily using INFO. IMO this is 
inappropriate, for the same reason session-mode messaging via MESSAGE 
was rejected, in favor of MSRP. As I understand the service being 
provided, it is a specialized application of session mode instant messaging.

- a new mechanism is introduced for passing alert indications, rather 
than reusing the defined mechanism of Alert-Info. (RFC3261 and RFC7462)

My feeling is that these conflict with ietf standards and so the 
registration should be rejected. I would like to hear other thoughts on 
this, and in general on the appropriateness of the proposed mechanism as 
a SIP usage.

	Thanks,
	Paul

Subject: Re: [IANA #838391] Registration of media feature tag g.3gpp.nw-init-ussi
From: Paul Kyzivat <[email-masked]>
To: [email-masked]
Date: Tue, 11 Aug 2015 14:49:09 -0400

I have some concerns about this registration. I would like to hear from 
the submitter about these:

The overall mechanism is to establish a media-less dialog, and use it as 
a signalng channel, using bodies in INVITE and BYE as well as INFO 
messages. This is dubious usage. Back when instant messaging was being 
defined for SIP there was a decision not to allow establishing a dialog 
where an IM session is conducted using SIP signaling messages. Instead, 
MSRP was defined to carry session-oriented messages. The MESSAGE method 
was still allowed, but only for "page mode" messaging.

RFC 6086, defining INFO, doesn't consider the use of media-less dialogs 
established solely for exchanging INFO messages. But similar thinking 
would imply the inadvisability of doing so.

What was the rationale for choosing this approach rather than say using 
MSRP?

Then, in addition to using INFO, data is also being exchanged in the 
body of INVITE and BYE. What is the rationale for that, rather than 
simply using INFO? (I guess this is an optimization. Is it "worth it"?)

Finally, I note that the message bodys can contain an <alertingPattern> 
element carrying an unsigned byte identifying the pattern, and that this 
is intended to determine how the receiving UE alerts the user. This 
seems to be a bypass of Alert-Info as the way of indicating alerting 
behavior. It is generally inappropriate to define a new proprietary 
mechanism when a standard mechanism can provide the same functionality. 
Notably RFC7462 provides a way to request a particular well known alert 
type, and it is extensible to any sort of special alert that 3GPP might 
have in mind.

I'd like to hear back on these things before deciding whether this 
registration is valid.

	Thanks,
	Paul Kyzivat

On 8/6/15 6:16 PM, Amanda Baber via RT wrote:
> Hi Paul,
>
> This is the last of five requests from Frederic Firmin. We didn't receive a corresponding global feature-capability indicator request.
>
> thanks,
>
> Amanda Baber
> IANA Senior Specialist
> ICANN
>
> =====
>
> Hi Amanda,
>
> Last one for today
>
> BR// Frederic
>
>
> Media feature tag name: g.3gpp.nw-init-ussi
>
> ASN.1 identifier associated with feature tag:
>
> New assignment by IANA
>
> Summary of the media feature indicated by this feature tag:
>
> This feature-tag indicates support of user equipment procedures for the network initiated USSD over IMS.
>
> Values appropriate for use with this feature tag:
>
>
>    [X] 1. The feature tag is Boolean and may have values of
>
>         TRUE or FALSE.   A value of TRUE indicates an available
>
>         capability.  A value of FALSE indicates the capability
>
>         is not available.
>
>
> The feature tag is intended primarily for use in the following
>
> applications, protocols, services, or negotiation mechanisms:
>
> This feature-tag is most useful in a communications application, for describing the capabilities of a device, such as a phone or PDA
>
> Examples of typical use:
>
> Indicating that a mobile phone supports the network initiated USSD over IMS.
>
> Related standards or documents:
>
> 3GPP TS 24.390: "Unstructured Supplementary Service Data (USSD) using IP Multimedia (IM) Core Network (CN) subsystem IMS; Stage 3” V12.2.0 http://www.3gpp.org/dynareport/24390.htm
>
> Security considerations:
>
> Security considerations for this media feature-tag are discussed in subclause 12.1 of IETF RFC 3840
>
> Name(s) & email address(es) of person(s) to contact for
>
> further information: Frederic Firmin [email-masked]
>
> Intended usage: COMMON
>
> Author/Change controller: Frederic Firmin
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 20 Oct 2015 05:54:41 +0000

Hello Paul,

> - it establishes a media-less INVITE dialog, for the purpose of exchanging messages in the signaling, primarily using INFO. IMO this is inappropriate, for the same reason session-mode 
> messaging via MESSAGE was rejected, in favor of MSRP. As I understand the service being provided, it is a specialized application of session mode instant messaging.

the INFO package has already been registered by IANA so I wonder how why that is questioned now. It has nothing to do with the media feature tag.

> - a new mechanism is introduced for passing alert indications, rather than reusing the defined mechanism of Alert-Info. (RFC3261 and RFC7462)

The alertingPattern is an application level indication.

The alertingPattern can potentially be included in any USSI message, including those sent in INFO messages while Alert-Info cannot be in INFO request.

Kind regards

Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Monday, October 19, 2015 4:36 PM
To: SIPCORE
Subject: [sipcore] Requesting assist with expert review of media feature tag

I'm the designated expert reviewer for IANA registration of new media feature tag values. (Often for use as sip caller capabilities.)

I have a recent request that concerns me. I am inclined to reject it, but the decision is subjective, so I would like to have some discussion on it first.

The request comes from 3gpp - it has had no action in ietf. It is for the media feature tag g.3gpp.nw-init-ussi, with semantics defined in 3GPP TS 24.390 ("Unstructured Supplementary Service Data (USSD) using IP Multimedia (IM) Core Network (CN) subsystem IMS; Stage 3”)

It is the details of how this service is signaled in SIP that troubles me. I wrote this up in my initial response. A copy of that message is attached. (Including details of the request.) My key concerns from that are:

- it establishes a media-less INVITE dialog, for the purpose of exchanging messages in the signaling, primarily using INFO. IMO this is inappropriate, for the same reason session-mode messaging via MESSAGE was rejected, in favor of MSRP. As I understand the service being provided, it is a specialized application of session mode instant messaging.

- a new mechanism is introduced for passing alert indications, rather than reusing the defined mechanism of Alert-Info. (RFC3261 and RFC7462)

My feeling is that these conflict with ietf standards and so the registration should be rejected. I would like to hear other thoughts on this, and in general on the appropriateness of the proposed mechanism as a SIP usage.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Oct 2015 11:48:41 -0400

> the INFO package has already been registered by IANA so I wonder how why that is questioned now. It has nothing to do with the media feature tag.

I"m not questioning the general use of info packages. I'm questioning 
establishing an invite dialog usage with no intent to include media, 
with the sole intent of exchanging INFO messages as a form of session 
mode messaging. Way back during the time of SIMPLE, we decided that it 
was bad to establish a messaging *session* over the sip signaling 
channel. At the time that alternative was via MESSAGE, but using INFO 
doesn't change the argument. It is still bad.

> The alertingPattern can potentially be included in any USSI message, including those sent in INFO messages while Alert-Info cannot be in INFO request.

I still don't understand. Is this alerting, in concept, any different 
from that which Alert-Info is intended for?

Is it that you want to alert for individual messages within a messaging 
session?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 20 Oct 2015 18:16:52 +0000

Hi,

>>> exchanging messages in the signaling, primarily using INFO. IMO this is inappropriate, for the same reason 
>>> session-mode messaging via MESSAGE was rejected, in favor of MSRP. As I understand the service being provided, it is a specialized application of session mode instant messaging.
>>
> I"m not questioning the general use of info packages. I'm questioning establishing an invite dialog usage with no intent to include
> media, with the sole intent of exchanging INFO messages as a form of session mode messaging. Way back during the time of SIMPLE, we 
> decided that it was bad to establish a messaging *session* over the sip signaling channel. At the time that alternative was via MESSAGE, but 
> using INFO doesn't change the argument. It is still bad.

I think this issue should have been raised when the Info package was registered. That's when one should look at how the Info Package is going to be used etc. I don't think it's fair to reject the media feature tag registration on such grounds at this point.

In my opinion it's about whether the media feature tag semantics is aligned with the rules for a media feature tag. In my opinion it is, as it only indicates support of a feature. It does NOT indicate do-what-I-mean, it does NOT assume anything from the remote party etc.

Regards,

Christer

> The alertingPattern can potentially be included in any USSI message, including those sent in INFO messages while Alert-Info cannot be in INFO request.

I still don't understand. Is this alerting, in concept, any different from that which Alert-Info is intended for?

Is it that you want to alert for individual messages within a messaging session?

	Thanks,
	Paul

> Kind regards
>
> Ivo Sedlacek
>
> This Communication is Confidential. We only send and receive email on 
> the basis of the terms set out at www.ericsson.com/email_disclaimer
>
> 3GPP TS 24.390 ("Unstructured Supplementary Service Data (USSD) using 
> IP Multimedia (IM) Core Network (CN) subsystem IMS; Stage 3”)
>

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Oct 2015 20:51:57 -0400

> I think this issue should have been raised when the Info package was registered. That's when one should look at how the Info Package is going to be used etc. I don't think it's fair to reject the m…

Well, the info package registry is only "specification required". I just 
looked and found that the package in question was registered by 
reference to a 3gpp specification. There is no expert reviewer for it. 
So I at least wasn't aware that it happened in order to raise an objection.

In any case, I doubt one can tell from the definition of the package 
that it will be used in sessions set up exclusively for its use.

> In my opinion it's about whether the media feature tag semantics is aligned with the rules for a media feature tag. In my opinion it is, as it only indicates support of a feature. It does NOT indic…

The guidance to the expert is minimal.
That is why I'm bringing it up here.

	Thanks,
	Paul

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 21 Oct 2015 07:02:27 +0000

> Is it that you want to alert for individual messages within a messaging session?

Yes, alerting for individual USSI messages within a USSI (messaging) session is possible.

USSI (USSD over IMS) emulates the existing USSD over circuit switched domain of 3GPP networks and needs to provide the same feature set.

Kind regards

Ivo Sedlacek

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 21 Oct 2015 12:36:16 +0000

I'd like to add to what Ivo has said.

In general in 3GPP we have tried to separate the general use of the additional parameter, and put that in or around a section entitled IANA registration, from the material where it is used specifically in support of a particular 3GPP application.

So generally, this is a media feature tag. It is defined as a medial feature tag in the IANA registration clause of the underlying 3GPP specification, and operates as, and can be used as, a media feature tag in full compliance with the IETF RFCs covering media feature tags.

3GPP TS 24.390 obviously uses this feature tag in support of a service or capability using the INFO package. Now whether that is correct or not is nothing to do with the use of the media feature tag. Further the alerting definition has nothing to do with the semantics of the media feature tag.

So the request from 3GPP was for this media feature tag to be registered.

The request to register the media feature tag has apparently been rejected for reasons that are nothing to do with the media feature tag definition.

Regards

Keith

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: 20 October 2015 06:55
To: Paul Kyzivat; SIPCORE
Subject: Re: [sipcore] Requesting assist with expert review of media feature tag

Hello Paul,

> exchanging messages in the signaling, primarily using INFO. IMO this is inappropriate, for the same reason session-mode messaging via MESSAGE was rejected, in favor of MSRP. As I understand the service being provided, it is a specialized application of session mode instant messaging.

Kind regards

Ivo Sedlacek

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Monday, October 19, 2015 4:36 PM
To: SIPCORE
Subject: [sipcore] Requesting assist with expert review of media feature tag

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Oct 2015 09:41:40 -0400

I acknowledge that the fundamental question here is what the criteria 
should be for the expert to approve a media feature tag request.

I indeed am taking the position that if the tag is used to enable a 
feature, then the consistency of that feature with SIP is a valid 
criterion. I recognize that not everyone agrees with that position.

I take that position because it is the leverage that we have.

It would be better if the guidance to the expert were clearer. It may be 
that the right answer is to take some action to clarify that.

Absent that, I *think* I am free to ask for advice from a pertinent wg, 
and then take that as I see fit. And the iesg is free to assign a new 
expert if they wish.

	Thanks,
	Paul