Subject: [Ecrit] draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall]

From: Christer Holmberg <[email-masked]>
Date: Wed, 8 Jun 2016 06:14:16 +0000

Hi,

Š

>The draft has limited scope: it is for emergency calls where the
>endpoints support the draft (and additional-data, which is a
>normative reference).  So, confirming endpoints would understand data
>transferred in accordance with the draft and additional-data.

I think it needs to be clear that an endpoint is not mandated to support
the additional-data XML schemas etc.

Regards,

Christer

---

From: Randall Gellens <[email-masked]>
Date: Wed, 8 Jun 2016 08:53:52 -0700

Hi Christer,

The additional-data document doesn't force UEs to add the structures. 
It says devices SHOULD add a Device Info block.  In NENA's view, it 
would be helpful if all UEs did so.

At 6:14 AM +0000 6/8/16, Christer Holmberg wrote:

>  S

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Inside every large problem is a small problem struggling to get out.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 8 Jun 2016 16:18:50 +0000

Hi,

My point was that draft-ecall shall not mandate UEs to support the additional-data structures: not explicitly, and not via a normative reference.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Randall Gellens<mailto:[email-masked]>
Sent: ‎08/‎06/‎2016 18:53
To: Christer Holmberg<mailto:[email-masked]>; Drage, Keith (Nokia - GB)<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ecall: Support of drafft-additional-data [was: Usage of INFO  by draft-ietf-ecrit-ecall]

Hi Christer,

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 8 Jun 2016 16:24:11 +0000

What has NENA to do with ecall?

Further this draft is not supported directly by 3GPP UEs. (Nothing prevents its implementation but it is not covered by any 3GPP specifications so will possibly be dropped at SBCs).

Keith

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: 08 June 2016 16:54
To: Christer Holmberg; Drage, Keith (Nokia - GB); [email-masked]
Subject: Re: draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall]

Hi Christer,

The additional-data document doesn't force UEs to add the structures. 
It says devices SHOULD add a Device Info block.  In NENA's view, it would be helpful if all UEs did so.

At 6:14 AM +0000 6/8/16, Christer Holmberg wrote:

>>endpoints support the draft (and additional-data, which is a normative 
>>reference).  So, confirming endpoints would understand data 
>  I think it needs to be clear that an endpoint is not mandated to 
> support  the additional-data XML schemas etc.
>
>  Regards,
>
>  Christer

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- Inside every large problem is a small problem struggling to get out.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 8 Jun 2016 10:54:06 -0700

Hi Christer,

We're not mandating that the UE support any of the additional-data 
blocks.  The normative reference brings in two SHOULDs that apply to 
the UE, with no MUSTs:

- 4.1: "Devices SHOULD use [the Data Provider Information] block to 
provide identifying information."
- 4.3: "[The Device Information block] SHOULD be provided ... by the 
device itself."

At 4:18 PM +0000 6/8/16, Christer Holmberg wrote:

>  Hi,
>
>  My point was that draft-ecall shall not mandate UEs to support the 
> additional-data structures: not explicitly, and not via a normative 
> reference.
>
>  Regards,
>
>  Christer
>
>  From: <mailto:[email-masked]>Randall Gellens
>  Sent: 08/06/2016 18:53
>  To: <mailto:[email-masked]>Christer Holmberg; 
> <mailto:[email-masked]>Drage, Keith (Nokia - GB); 
> <mailto:[email-masked]> [email-masked]

-------------- Randomly selected tag: ---------------
New Study of Obesity Looks for Larger Test Group
--Newspaper headline

---

From: Randall Gellens <[email-masked]>
Date: Wed, 8 Jun 2016 10:55:41 -0700

>  What has NENA to do with ecall?

NENA has a lot to do with the additional-data draft.

>
>  Further this draft is not supported directly by 3GPP UEs. (Nothing 
> prevents its implementation but it is not covered by any 3GPP 
> specifications so will possibly be dropped at SBCs).

The mechanisms in the additional-data draft are used in the ecall 
draft.  That does not mandate that UEs support any of the 
additional-data blocks.

>  -------------- Randomly selected tag: --------------- Inside every 
> large problem is a small problem struggling to get out.

-------------- Randomly selected tag: ---------------
You are wise, witty, and wonderful, but you spend too much time reading
this sort of trash.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 8 Jun 2016 19:56:03 +0000

Hi,

>We're not mandating that the UE support any of the additional-data blocks.  The normative reference >brings in two SHOULDs that apply to the UE, with no MUSTs:
>
>- 4.1: "Devices SHOULD use [the Data Provider Information] block to provide identifying information."
>- 4.3: "[The Device Information block] SHOULD be provided ... by the device itself."

I don't think we should bring in that, because that would mean support of the Data Provider XML schema and the associated MIME type.

IF we need to reference draft-additional-data to begin with, it should only be for the "mechanism" that will be used to carry the ecall information in the INVITE.

We may also need to be a little more clear on what we mean by "mechanism", but I'll comment more on that (if needed) once I've seen the next version of the ecall draft.

Regards,

Christer

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- New Study of Obesity Looks for Larger Test Group --Newspaper headline

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 8 Jun 2016 20:15:29 +0000

Can we turn the question around?

Can we identify what we still need from additional-data to support ecall?

Surely if the coding is now ASN.1 based directly from the CEN document, much disappears, and it would be nice to know what is now left.

Keith

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: 08 June 2016 20:56
To: Randall Gellens; Drage, Keith (Nokia - GB); [email-masked]
Subject: RE: draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall]

Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 8 Jun 2016 20:24:15 +0000

Hi,

As far as I understand, we need section 6, but I hope some can verify that.

Regards,

Christer

-----Original Message-----
From: Drage, Keith (Nokia - GB) [mailto:[email-masked]] 
Sent: 08 June 2016 23:15
To: Christer Holmberg <[email-masked]>; Randall Gellens <[email-masked]>; [email-masked]
Subject: RE: draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall]

Keith

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: 08 June 2016 20:56
To: Randall Gellens; Drage, Keith (Nokia - GB); [email-masked]
Subject: RE: draft-ecall: Support of drafft-additional-data [was: Usage of INFO by draft-ietf-ecrit-ecall]

Hi,

Regards,

Christer

---

From: Randall Gellens <[email-masked]>
Date: Wed, 8 Jun 2016 17:12:43 -0700

Hi Christer,

Since those are SHOULDs instead of MUSTs, it isn't a mandate.  A UE 
implementation can choose to not support those two SHOULDs and still 
be in compliance.

--Randy

At 7:56 PM +0000 6/8/16, Christer Holmberg wrote:

>> blocks.  The normative reference >brings in two SHOULDs that apply 
>> to the UE, with no MUSTs:
>>
>  I don't think we should bring in that, because that would mean 
> support of the Data Provider XML schema and the associated MIME 
> type.
>
>  IF we need to reference draft-additional-data to begin with, it 
> should only be for the "mechanism" that will be used to carry the 
> ecall information in the INVITE.
>
>  We may also need to be a little more clear on what we mean by 
> "mechanism", but I'll comment more on that (if needed) once I've 
> seen the next version of the ecall draft.
>
>  Regards,
>
>  Christer
>
>
>
>  -------------- Randomly selected tag: --------------- New Study of 
> Obesity Looks for Larger Test Group --Newspaper headline

-------------- Randomly selected tag: ---------------
I'm prepared for all emergencies but totally unprepared for
everyday life.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 8 Jun 2016 17:13:21 -0700

Hi Keith,

I don't see what ASN.1 versus XML has to do with it.

--Randy

At 8:15 PM +0000 6/8/16, Keith (Nokia - GB) Drage wrote:

>  Surely if the coding is now ASN.1 based directly from the CEN 
> document, much disappears, and it would be nice to know what is now 
> left.
>
>  Keith
>

-------------- Randomly selected tag: ---------------
One forgets words as one forgets names.  One's vocabulary needs
constant fertilization or it will die.      --Evelyn Waugh

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 9 Jun 2016 04:45:28 +0000

Hi,

The point is not whether it's MUST, SHOULD or MAY - those parts should not be incorporated into draft-ecall to begin with.

Just because you have a normative reference to a spec you can still scope what parts of the spec you incorporate, and I think we need to make that clear.

Regards,

Christer

Sent: ‎09/‎06/‎2016 03:12

Hi Christer,

--Randy