Subject: [Ecrit] ECRIT Interim meeting - June

From: Roger Marshall <[email-masked]>
Date: Wed, 1 Jun 2016 23:03:55 +0000

ECRIT:
The work group needs to figure out how it can address some of the raised issues in order to make progress on draft-ietf-ecrit-ecall-07.

We've set up a doodle poll at the following link for next week:

http://doodle.com/poll/hnfhkvfgc7x6hesx

Please mark your best available times to discuss.  Bridge information will follow, once we have a timeslot identified.

Roger Marshall & Marc Linsner
ECRIT Chairs

NOTICE TO RECIPIENT: This email, including attachments, may contain information which is confidential, proprietary, attorney-client privileged and/or controlled under U.S. export laws and regulations and may be restricted from disclosure by applicable State and Federal law. Nothing in this email shall create any legal binding agreement between the parties unless expressly stated herein and provided by an authorized representative of Comtech Telecommunications Corp. or its subsidiaries. If you are not the intended recipient of this message, be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify us immediately by return email and permanently delete all copies of the original email and any attached documentation from any computer or other media.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 2 Jun 2016 11:35:02 -0700

Hi Everyone,

A few weeks ago, Brian and I had discussions with Paul Kyzivat and 
Robert Sparks, and came to the conclusion that the draft should be 
modified slightly so that the reply to a mid-call request for an 
updated MSD (ecall) or VEDS (car-crash) goes in a new INFO message, 
and that for consistency, the INFO package registration will say that 
no body type is associated with it, and it is restricted to be used 
only when emergency call data is being sent using the Call-Info 
header field mechanism per additional-data.  The result is that the 
draft will change so that all body parts are sent per the 
additional-data Call-Info header field mechanism, and if the PSAP 
sends a mid-call request for updated crash data, the vehicle sends a 
response message to that INFO and a new INFO request message 
containing the data (simultaneously).

Meanwhile, 3GPP recently agreed to use the ecall draft, but noted a 
preference by several representatives that when there is a mid-call 
request for an updated MSD, the updated MSD is sent in its own INFO 
rather than the response to the requesting INFO, so this is in 
alignment with the change the authors agreed with neutral SIP experts.

Further, 3GPP indicated they want the MSD to be encoded in ASN.1 
rather than XML (both encodings are specified by CEN in EN 15722). 
When this was previously discussed within the IETF, participants 
expressed concern over using ASN.1, but in light of 3GPP's 
preference, and because SIP can use binary content-transfer-encoding 
for body parts, I will make this change unless the group objects.

Because of this, I don't see a need to have an interim call.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
You never finish a program, you just stop working on it.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 Jun 2016 20:54:43 +0000

Hi,

>A few weeks ago, Brian and I had discussions with Paul Kyzivat and Robert Sparks, and came to the conclusion that the draft should be modified slightly so that the reply to a mid-call request for an >updated MSD (ecall) or VEDS (car-crash) goes in a new INFO message, and that for consistency, the INFO package registration will say that no body type is associated with it, and it is restricted to be used >only when emergency call data is being sent using the Call-Info header field mechanism per additional-data. 

I am not sure I understand. The main purpose of the INFO package is for carrying ecall information, and that ecall information is carried as a message body, so how can one claim that the message body is not associated with the INFO package???

If the INFO package is supposed to be able to carry additional data you need to fix draft-additional-data instead, and allow the information to be associated with an INFO package.

>The result is that the draft will change so that all body parts are sent per the additional-data Call-Info header field mechanism, and if the PSAP sends a mid-call request for updated crash data, the vehicle >sends a response message to that INFO and a new INFO request message containing the data (simultaneously).
>
>Meanwhile, 3GPP recently agreed to use the ecall draft, but noted a preference by several representatives that when there is a mid-call request for an updated MSD, the updated MSD is sent in its own >INFO rather than the response to the requesting INFO, so this is in alignment with the change the authors agreed with neutral SIP experts.

Note that this is related to the issue raised in ECRIT earlier, that you cannot not send *ANY* INFO package related information in an INFO response, as per RFC 6086.

>Further, 3GPP indicated they want the MSD to be encoded in ASN.1 rather than XML (both encodings are specified by CEN in EN 15722). 
>When this was previously discussed within the IETF, participants expressed concern over using ASN.1, but in light of 3GPP's preference, and because SIP can use binary content-transfer-encoding for 
> body parts, I will make this change unless the group objects.
>

I'll let others decide on that, but I don't agree with the Call-Info thing - unless I've misunderstood something.

Regards,

Christer

---

From: Randall Gellens <[email-masked]>
Date: Thu, 2 Jun 2016 20:50:36 -0700

Hi Christer,

At 8:54 PM +0000 6/2/16, Christer Holmberg wrote:

>> modified slightly so that the reply to a mid-call request for 
>> an >updated MSD (ecall) or VEDS (car-crash) goes in a new INFO 
>> message, and that for consistency, the INFO package registration 
>> will say that no body type is associated with it, and it is 
>> restricted to be used >only when emergency call data is being sent 
>> using the Call-Info header field mechanism per additional-data.
>
>  I am not sure I understand. The main purpose of the INFO package is 
> for carrying ecall information, and that ecall information is 
> carried as a message body, so how can one claim that the message 
> body is not associated with the INFO package???

As I understand it after the discussions with Paul and Robert, the 
INFO package registration provides a way to authorize sending body 
parts that are associated with the INFO package, but that means that 
the draft has two ways of authorizing sending the same body parts: 
the base way from additional-data / Call-Info, and the INFO package 
registration.  So, this is a very minor change that means that the 
authorization to send body parts is always per additional-data (using 
Call-Info), and the INFO package registration says that INFO can be 
used to send data per additional-data.

>
>  If the INFO package is supposed to be able to carry additional data 
> you need to fix draft-additional-data instead, and allow the 
> information to be associated with an INFO package.

Only the ecall draft (and by extension car-crash) needs to use INFO.

>
>>The result is that the draft will change so that all body parts are 
>> sent per the additional-data Call-Info header field mechanism, and 
>> if the PSAP sends a mid-call request for updated crash data, the 
>> vehicle >sends a response message to that INFO and a new INFO 
>> request message containing the data (simultaneously).
>>
>> preference by several representatives that when there is a 
>> mid-call request for an updated MSD, the updated MSD is sent in 
>> its own >INFO rather than the response to the requesting INFO, so 
>> this is in alignment with the change the authors agreed with 
>> neutral SIP experts.
>
>  Note that this is related to the issue raised in ECRIT earlier, 
> that you cannot not send *ANY* INFO package related information in 
> an INFO response, as per RFC 6086.

Yes, and the draft currently says that the info that is sent is not 
INFO package related, but additional-data related, however, the 
change will be that the data will be sent in a new INFO message, 
which is exactly what you have been asking for.

>> preference, and because SIP can use binary 
>> content-transfer-encoding for
>  I'll let others decide on that, but I don't agree with the 
> Call-Info thing - unless I've misunderstood something.
>
>  Regards,
>
>  Christer

-------------- Randomly selected tag: ---------------
The well-bred contradict other people.  The wise contradict themselves.
                                                         --Oscar Wilde

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Jun 2016 06:32:36 +0000

Hi,

>parts that are associated with the INFO package,

Correct.

> but that means that
>registration.

That is wrong. RFC 6086 says that any new INFO usage MUST use the INFO
package mechanism.

>So, this is a very minor change that means that the

Again, that is wrong. Information in INFO must be carried using the INFO
package mechanism.

Note, though, that I am only talking about INFO. How you carry information
in e.g. INVITE is a separate issue.

>Only the ecall draft (and by extension car-crash) needs to use INFO.

That makes me even more confused why you would want to use something else
than an INFO packageŠ

>which is exactly what you have been asking for.

And I appreciate that :)

Regards,

Christer

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 3 Jun 2016 10:59:33 +0000

Hello,

FYI  - 3GPP CT WG1 so far agreed the following eCall related CRs:

- http://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_98_Osaka/docs/C1-163032.zip

- http://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_98_Osaka/docs/C1-163060.zip

Kind regards

Ivo Sedlacek

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Fri, 3 Jun 2016 13:57:13 +0000

It would be nice to see some response to the extensive comments I have made before we fix such a meeting.

Regards

Keith

From: Ecrit [mailto:[email-masked]] On Behalf Of Roger Marshall
Sent: 02 June 2016 00:04
To: [email-masked]
Subject: [Ecrit] ECRIT Interim meeting - June

ECRIT:

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Fri, 3 Jun 2016 14:16:55 +0000

I would note that as one of the major commenters on this document, I have not been involved in this discussion, not has it appeared prior to this on the WG list.

I think you absolutely need to separate what goes in the INFO mechanism as an attached body, and what goes in other messages. The additional-data mechanism should not be used to regulate the transfer of INFO packages.

That comment also probably applies to other messages designed for transferring packages, e.g. SUBSCRIBE/NOTIFY as well.

Regards

Keith

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Randall Gellens
Sent: 03 June 2016 04:51
To: Christer Holmberg; [email-masked]
Subject: Re: [Ecrit] ECRIT Interim meeting - June

Hi Christer,

At 8:54 PM +0000 6/2/16, Christer Holmberg wrote:

>>header field mechanism per additional-data.
>
> for carrying ecall information, and that ecall information is carried 
> as a message body, so how can one claim that the message body is not 
> associated with the INFO package???

As I understand it after the discussions with Paul and Robert, the INFO package registration provides a way to authorize sending body parts that are associated with the INFO package, but that means that the draft has two ways of authorizing sending the same body parts: 
the base way from additional-data / Call-Info, and the INFO package registration.  So, this is a very minor change that means that the authorization to send body parts is always per additional-data (using Call-Info), and the INFO package registration says that INFO can be used to send data per additional-data.

>>sent per the additional-data Call-Info header field mechanism, and  if 
>>the PSAP sends a mid-call request for updated crash data, the  vehicle 
>>>sends a response message to that INFO and a new INFO  request message 
>>request for an updated MSD, the updated MSD is sent in  its own >INFO 
>  Note that this is related to the issue raised in ECRIT earlier, that 
> you cannot not send *ANY* INFO package related information in an INFO 
> response, as per RFC 6086.

Yes, and the draft currently says that the info that is sent is not INFO package related, but additional-data related, however, the change will be that the data will be sent in a new INFO message, which is exactly what you have been asking for.

>>for
>  I'll let others decide on that, but I don't agree with the Call-Info 
> thing - unless I've misunderstood something.
>
>  Regards,
>
>  Christer

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- The well-bred contradict other people.  The wise contradict themselves.
                                                         --Oscar Wilde

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 3 Jun 2016 11:10:45 -0400

My preferred approach to this was, after the completion of the initial 
INVITE, to carry the data in real INFO package bodies, using INFO as 
designed. I was ok with using additional-data call-info with a 
referenced body part to convey initial info in the INVITE. That *might* 
mean that some information might need to have two different 
representations - one via call-info and one via INFO. But some careful 
redesign could probably avoid the duplication.

In passing I mentioned that body parts *can* be attached to pretty much 
any message. So another way to do what was proposed would be to use 
additional-data call-info for all, and find some message to piggyback on 
when there is a need to send something. This could be another message 
that was going anyway. Or one could find a benign message to send, 
simply as a vehicle to attach the call-info. This could be a reINVITE or 
UPDATE, or it could even be an INFO.

To use INFO that way there would need to be some validly constructed 
INFO to send, and then the call-info and its additional-data body part 
attached to it. Somebody suggested defining an INFO package that has no 
body. (I was a bit dubious of that. Alternatively one could define a 
very tiny package body part of no significance.)

I think such an approach is *technically* valid. But I find it quite a 
hack. I think using INFO with a new package that conveys the required 
data to be a much cleaner, more elegant, approach.

	Thanks,
	Paul

---

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

I don't think there is anything such as a benign message in SIP.

All the methods are there for a defined purpose and carry semantics.

So I don't think attaching this to another message is appropriate, except for the proper use of that message, i.e. INFO to carry an INFO package, SUBSCRIBE/NOTIFY to carry an event package and so on. 

Keith

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 03 June 2016 16:11
To: [email-masked]
Subject: Re: [Ecrit] ECRIT Interim meeting - June

My preferred approach to this was, after the completion of the initial INVITE, to carry the data in real INFO package bodies, using INFO as designed. I was ok with using additional-data call-info with a referenced body part to convey initial info in the INVITE. That *might* mean that some information might need to have two different representations - one via call-info and one via INFO. But some careful redesign could probably avoid the duplication.

In passing I mentioned that body parts *can* be attached to pretty much any message. So another way to do what was proposed would be to use additional-data call-info for all, and find some message to piggyback on when there is a need to send something. This could be another message that was going anyway. Or one could find a benign message to send, simply as a vehicle to attach the call-info. This could be a reINVITE or UPDATE, or it could even be an INFO.

To use INFO that way there would need to be some validly constructed INFO to send, and then the call-info and its additional-data body part attached to it. Somebody suggested defining an INFO package that has no body. (I was a bit dubious of that. Alternatively one could define a very tiny package body part of no significance.)

I think such an approach is *technically* valid. But I find it quite a hack. I think using INFO with a new package that conveys the required data to be a much cleaner, more elegant, approach.

	Thanks,
	Paul

On 6/3/16 2:32 AM, Christer Holmberg wrote:
>>>> >updated MSD (ecall) or VEDS (car-crash) goes in a new INFO 
>> So, this is a very minor change that means that the authorization to 
>> send body parts is always per additional-data (using Call-Info), and 
>> the INFO package registration says that INFO can be used to send data 
>> per additional-data.
>
> Again, that is wrong. Information in INFO must be carried using the 
> INFO package mechanism.
>
> Note, though, that I am only talking about INFO. How you carry 
> information in e.g. INVITE is a separate issue.
>
>
> That makes me even more confused why you would want to use something 
> else than an INFO packageŠ
>
>
>>>> request for an updated MSD, the updated MSD is sent in its own 
>>>> >INFO rather than the response to the requesting INFO, so this is 
>>>> in alignment with the change the authors agreed with neutral SIP 
>>>> experts.
>>>

---

From: Roger Marshall <[email-masked]>
Date: Fri, 3 Jun 2016 16:40:43 +0000

Given a variety of factors, including individuals' availability, the chairs have decided to Not schedule an interim meeting at this time.  We look forward to seeing continued list discussion in order to work through the current issues, and it seems like progress is being made.  We also look forward to getting an updated draft soon, so that folks can see the proposed text changes being discussed.

From: Ecrit [mailto:[email-masked]] On Behalf Of Roger Marshall
Sent: Wednesday, June 01, 2016 4:04 PM
To: [email-masked]
Subject: [Ecrit] ECRIT Interim meeting - June

ECRIT:

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 3 Jun 2016 12:44:33 -0400

> I don't think there is anything such as a benign message in SIP.

Point taken. But some can be used in ways that are close to benign. For 
instance, an UPDATE without an offer is mostly benign. (It can have an 
effect on session timers, so that needs to be dealt with.)

And of course it is possible to define an INFO package that is benign.

> So I don't think attaching this to another message is appropriate, except for the proper use of that message, i.e. INFO to carry an INFO package, SUBSCRIBE/NOTIFY to carry an event package and so o…

Note that I agree with you in that I don't think this is the best 
answer. I prefer using an INFO package in a straightforward way.

	Thanks,
	Paul

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Fri, 3 Jun 2016 16:45:13 +0000

Can we see some response to the comments being made first.

This is a WG document, and is meant to reflect the consensus of the working group, and not the authors thoughts and considerations.

Keith

From: Ecrit [mailto:[email-masked]] On Behalf Of Roger Marshall
Sent: 03 June 2016 17:41
To: Roger Marshall; [email-masked]
Subject: Re: [Ecrit] ECRIT Interim meeting - June

From: Ecrit [mailto:[email-masked]] On Behalf Of Roger Marshall
Sent: Wednesday, June 01, 2016 4:04 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Ecrit] ECRIT Interim meeting - June

ECRIT:

---

From: Roger Marshall <[email-masked]>
Date: Fri, 3 Jun 2016 16:52:14 +0000

Keith:
I think you mean that you want to see all of your comments addressed ahead of an updated draft, right?  I see comments being made and some responses.

If you have comments that you believe haven't been addressed as part of the list discussions, resend them.  Be sure to offer proposed text to what you believe may be deficiencies in the current draft.

-roger.

From: Drage, Keith (Nokia - GB) [mailto:[email-masked]]
Sent: Friday, June 03, 2016 9:45 AM
To: Roger Marshall; [email-masked]
Subject: RE: ECRIT Interim meeting - June

Keith

From: Ecrit [mailto:[email-masked]] On Behalf Of Roger Marshall
Sent: 03 June 2016 17:41
To: Roger Marshall; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] ECRIT Interim meeting - June

ECRIT:

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Fri, 3 Jun 2016 17:09:13 +0000

Are you even bothering to read the mailing list - give me an assessment of the draft editor's response to all comments over the last month!

I have seen zero response from the draft editor on any of the comments I have made.

Some of these have been part of existing threads (comments on INFO usage and service URN semantics - so please do not forget my comments there), but there is two major sets of comments made on 19th May, which follow this message to ensure they are not lost.

Regards

Keith

Set 1

I did another read through of this document last night, and had the following comments. I have not reviewed the entire document.

Note that this does not supercede any of the comments made in the last few days:

1)    s. 2, 1st para: ecall in 3GPP is a 3GPP emergency call, and while there are some similarities, 3GPP emergency call does not fully comply with either RFC 6443 or RFC 6881. I am also not sure the references are relevant to the purpose of the draft in any case.

2)    s. 2, 3rd and 4th para: These paragraphs seem to be going beyond document scope, and into a wish list. I suggest both these paragraphs are deleted.

3)    s. 3, 4th paragraph:

   An eCall can be either user-initiated or automatically triggered.

   Automatically triggered eCalls indicate a car crash or some other

   serious incident and carry a greater presumption of risk of injury.

   Manually triggered eCalls might be reports of serious hazards and are

   likely to require a different response than an automatically

   triggered eCall.  Manually triggered eCalls are also more likely to

   be false (e.g., accidental) calls and so might be subject to

   different operational handling by the PSAP.

The distinction between seriousness and impact of manual versus automatic is highly subjective, and will depend on the underlying philosophy of the administration in how it handles what it regards as false alerts, which differs substantially from administration to administration.

4)    s. 3, 5th para:

   As part of this work, the European Telecommunications

   Standards Institute (ETSI) [SDO-ETSI] has published a Technical

   Report titled "Mobile Standards Group (MSG); eCall for VoIP" [MSG_TR]

   that presents findings and recommendations regarding support for

   eCall in an all-IP environment.

This somehow implies that the contents of this document are valid for the interpretation of the draft. Vewry little of the work has migrated into the stage 1 in 3GPP, and the other groups in 3GPP are working directly from the stage 1 description, not from the ETSI work.

5)    s. 3 last para:

   A transition period will exist during which time the various entities

   involved in initiating and handling an eCall might support next-

   generation eCall, legacy eCall, or both.  This transition period

   might last several years or longer.  The issue of migration/co-

   existence during the transition period is very important but is

   outside the scope of this document.  The ETSI TR "Mobile Standards

   Group (MSG); eCall for VoIP" [MSG_TR] discusses these issues in

   Clause 7.

I have not found any statements that support the concept of a transition in any of the documents I have read. The 3GPP stage 1 requires both UEs and PSAPs to support both data transfer mechanisms.

6)    s. 3 general

Some statement should be made in this section about the need for the UE and the PSAP to support both mechanisms within SIP, as required by the stage 1, as the 3GPP emergency network does not provide any data interworking, only signalling interworking. Interworking SIP to CS domain, any attached body to a SIP message will be discarded.

7)    s. 4 reference to 22.101, and s. 18.1. This document carries no provisions needed to implement this document, and therefore it should not be a normative reference. Further the reference should be to release 14 and later. The latest version of all releases of 3GPP documents are still valid documents for that release.

8)    s. 4. Is considerably out of data in regard to the current version of 22.101. This appears to be a summary of the CS requirements before the IMS changes were made.

9)    s. 6 last para.

   This document registers new service URN children within the "sos"

   subservice.  These URNs provide the mechanism by which an eCall is

   identified, and differentiate between manually and automatically

   triggered eCalls (which can be subject to different treatment,

   depending on policy).  The two service URNs are:

   urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual

The URN does not identify an ecall. It identifies the resource to which the ecall needs to be directed. To explain further, the sos URN does not identify an emergency call, it identifies the resource needed to answer the emergency call, which is why we have a separate Resource-Priority namespace "esnet".

10)   s.7

Europe does not use the term ESInet. That term is North America, and possibly USA, specific. It might be more appropriate to use terminology from the ETSI M483 group if this text is needed at all.

11)   s.8

In regard to test calls, I think some statement should be made about what they actually test. Using this URN would certainly not test the emergency call handling capabilities of either the network or the UE. Does it test all data transfer capabilities (including the CS). Why do we need a URN rather than just the same number as is used in the CS domain?

12)   s.9

   Future enhancements are desired to enable the PSAP to send other

   requests to the vehicle, such as locking or unlocking doors, sounding

   the horn, flashing the lights, starting a video stream from on-board

   cameras (such as rear focus or blind-spot), etc.

Do you have a reference for this, or is it speculative thinking?

I do not think the mechanisms proposed in this draft are suitable for transferring a video stream, so even if provided, are they part of ecall, or just part of the standard emergency call. Maybe the only ecall responsibility is to indicate the existence of these?

I'd note that extending beyond the existing CS domain capability is not required at the moment by the 3GPP stage 1. I think we all acknowledge that all and any data available in the car might be candidates for transfer to the PSAP, but it is not clear whether this is part of ecall, or whether it is part of the additional media beyond voice already available as part of 3GPP emergency call. Certainly there is a limit on the amount of data that can be transferred using the mechanisms currently in this draft, beyond which the QoS of the signalling channel will become inappropriate.

13)   s.9 & s.13

It is not clear to me which elements correspond to the existing MSD defined by CEN, and which have been defined over the top. Firstly I think all data that is defined by CEN should carry an appropriate CEN reference, because the UE needs to support both, and it should be the same data that is transferred in this. That should occur either in one of these sections, or in a new separate section.

Further, if information does go over the top of the existing CEN definition, this needs additional review and possibly postponement to a later version, as this is not required by the current 3GPP stage 1.

14)   s.14.3

         A call-back from a PSAP incurs additional risk,

         since the current mechanisms are not ideal for verifying that

         such a call is indeed a call-back from a PSAP in response to an

         emergency call placed by the IVS.  See the discussion in

         Section 11 and the PSAP Callback document [RFC7090].

I do not understand why call-back is being referred to here. Can you explain?

Set 2

I did a reread of the INFO RFC last night in respect of the above draft, and came to the following conclusions.

1)    Any usage of the INFO method requires a full Info package definition. While there are various mentions of legacy usage, the draft is not trying to follow that direction, and in any case I am not convinced new registrations of relevant usage would be allowed down that route. So if the draft is to attempt to use the INFO method, it should formally define that method.

2)    The INFO RFC lays down clear instructions for the reviewer of the INFO package definition before it can be registered. In my view the current ecrit-ecall document would not pass that review.

3)    The INFO RFC makes no reference to transfer of data outside of the INFO method itself. My understanding is that the negotiation of the Info package within the Info-Package header field set to 'emergencyCallData.eCall' relates only to the data transferred in the INFO method using a conformant Info package definition. There therefore needs to be a discussion about what forms the negotiation mechanism for other information transferred, for example in the INVITE request, or other methods of the dialog, if such transfer is needed, and for it to be clearly documented.

4)    As indicated in 3), the INFO RFC does not expect data outside the Info package itself, and therefore nothing is stated there about the correlation of data between an application tagging things onto the methods of the dialog, and the application using the Info package.

5)    The INFO RFC allows for multiple Info packages to be used on the same dialog. There needs to be careful review to ensure that this capability is not compromised either in regard to the existing Info packages, or to new ones, particularly in regard to the assumed correlation between data in the Info package, and data transferred elsewhere in the dialog. I'd note that the draft would appear to sanction the inclusion of data in INFO methods belonging to entirely unrelated Info packages.

I would note that I am beginning to question whether there needs to be any transfer of data in the INVITE request. Transfer only within the INFO package after the response to the INVITE request is exchanged would still meet the 3GPP stage 1 requirements (see 22.101 release 14), and the whole document would be significantly simpler. None of the contents of the MSD is used for routeing the emergency call. This is without going into discussion about whether transfer using the signalling bearer, or some bearer negotiated using the SDP, is more appropriate.

From: Roger Marshall [mailto:[email-masked]]
Sent: 03 June 2016 17:52
To: Drage, Keith (Nokia - GB); [email-masked]
Subject: RE: ECRIT Interim meeting - June

Keith:

-roger.

Keith

ECRIT:

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Fri, 3 Jun 2016 17:16:42 +0000

I'm glad you agree we should keep usage of the INFO transaction within what is defined for INFO packages.

In regard to the rest of your mail, I'd note that UPDATE has semantics, which are to renegotiate session parameters (all of them except Contact, not just the SDP). So sending UPDATE means the endpoints go through all the procedures of completing such a renegotiation. Now I agree that the renegotiation could be to renegotiate exactly the same parameters, but, a) it is expecting the remote side to cooperate and agree the same parameters that it did before, and b) it involves an extra processing load for all the other parameters which is unnecessary.

Regards

Keith

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 03 June 2016 17:45
To: Drage, Keith (Nokia - GB); [email-masked]
Subject: Re: [Ecrit] ECRIT Interim meeting - June

> I don't think there is anything such as a benign message in SIP.

Point taken. But some can be used in ways that are close to benign. For instance, an UPDATE without an offer is mostly benign. (It can have an effect on session timers, so that needs to be dealt with.)

> So I don't think attaching this to another message is appropriate, except for the proper use of that message, i.e. INFO to carry an INFO package, SUBSCRIBE/NOTIFY to carry an event package and so o…

Note that I agree with you in that I don't think this is the best answer. I prefer using an INFO package in a straightforward way.

	Thanks,
	Paul

> attached to it. Somebody suggested defining an INFO package that has 
> no body. (I was a bit dubious of that. Alternatively one could define 
> a very tiny package body part of no significance.)
>
>>>>  I am not sure I understand. The main purpose of the INFO package 
>>>> is for carrying ecall information, and that ecall information is 
>> That is wrong. RFC 6086 says that any new INFO usage MUST use the 
>> INFO package mechanism.
>>
>>
>>> the INFO package registration says that INFO can be used to send 
>>> data per additional-data.
>>
>>>>> The result is that the draft will change so that all body parts 
>>>>> are sent per the additional-data Call-Info header field mechanism, 
>>>>> and if the PSAP sends a mid-call request for updated crash data, 
>>>>> the vehicle >sends a response message to that INFO and a new INFO 
>>>>> Meanwhile, 3GPP recently agreed to use the ecall draft, but noted 
>>>>> a preference by several representatives that when there is a 
>>>>> its own

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Jun 2016 17:18:45 +0000

Hi,

>My preferred approach to this was, after the completion of the initial INVITE, to carry the data in real INFO package bodies, using INFO as designed. I was ok with using additional-data call-info with a >referenced body part to convey initial info in the INVITE. That *might* mean that some information might need to have two different representations - one via call-info and one via INFO. But some >careful redesign could probably avoid the duplication.

Yes.

>In passing I mentioned that body parts *can* be attached to pretty much any message. So another way to do what was proposed would be to use additional-data call-info for all, and find some message >to piggyback on when there is a need to send something. This could be another message that was going anyway. Or one could find a benign message to send, simply as a vehicle to attach the call-info. >This could be a reINVITE or UPDATE, or it could even be an INFO.
>
>To use INFO that way there would need to be some validly constructed INFO to send, and then the call-info and its additional-data body part attached to it. Somebody suggested defining an INFO >package that has no body. (I was a bit dubious of that. Alternatively one could define a very tiny package body part of no significance.)

So, we would define a "dummy" info package, and whenever we want to send eCall data we just "happen" to also be sending an INFO associated with the dummy package - so we can then piggyback the eCall data into that INFO??? 

*mouth and eyes wide open*

I don't find words :)

>I think such an approach is *technically* valid. But I find it quite a hack. I think using INFO with a new package that conveys the required data to be a much cleaner, more elegant, approach.

Yes.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 3 Jun 2016 13:25:46 -0400

> In regard to the rest of your mail, I'd note that UPDATE has semantics, which are to renegotiate session parameters (all of them except Contact, not just the SDP). So sending UPDATE means the endpo…

I think we largely agree. Perhaps my use of the term "benign" was 
overreaching. My point is that there are a variety of messages that one 
could "piggyback" additional data on. Each of them has *some* other 
consequence, so choosing one to send when you otherwise didn't need to 
means accepting those consequences. That is also true of using a "dummy" 
INFO package, though in that case the consequences are well bounded. But 
it is still a hack.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Jun 2016 17:32:46 +0000

Hi,

I'd like to get some input e.g. on what changes will be done regarding the ASN.1 encoding.

Q1: Will ASN.1 be added in addition to XML? Or, will we remove XML?

Q2: For ASN.1, which encoding will we use? CEN allows both UPER and EXER. As 3GPP wants binary encoding, at least UPER needs to be supported. What about EXER?

Q3: What will we do regarding the MSD max size of 140 bytes?

I'd also like to get some input regarding the usage-of-modem-on-the-media-plane issue I raised earlier today. Do we need to say something? What do we need to say?

Etc etc.

Regards,

Christer

From: Ecrit [mailto:[email-masked]] On Behalf Of Roger Marshall
Sent: 03 June 2016 19:52
To: Drage, Keith (Nokia - GB) <[email-masked]>; [email-masked]
Subject: Re: [Ecrit] ECRIT Interim meeting - June

Keith:

-roger.

Keith

ECRIT:

---

From: Randall Gellens <[email-masked]>
Date: Sat, 4 Jun 2016 09:52:59 -0700

Hi Keith,

I agree -- the additional-data mechanism shouldn't be used to 
regulate the transfer of INFO packages.  INFO package registration 
does that.

--Randy

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

>  I would note that as one of the major commenters on this document, 
> I have not been involved in this discussion, not has it appeared 
> prior to this on the WG list.
>
>  I think you absolutely need to separate what goes in the INFO 
> mechanism as an attached body, and what goes in other messages. The 
> additional-data mechanism should not be used to regulate the 
> transfer of INFO packages.
>
>  That comment also probably applies to other messages designed for 
> transferring packages, e.g. SUBSCRIBE/NOTIFY as well.
>
>  Regards
>
>  Keith
>
> parts that are associated with the INFO package, but that means 
> that the draft has two ways of authorizing sending the same body 
> parts:
> authorization to send body parts is always per additional-data 
> (using Call-Info), and the INFO package registration says that INFO 
> can be used to send data per additional-data.
>
>>
>  -------------- Randomly selected tag: --------------- The well-bred 
> contradict other people.  The wise contradict themselves.
>                                                           --Oscar Wilde
>

-------------- Randomly selected tag: ---------------
Teacher Strikes Idle Kids
--Newspaper headline

---

From: Randall Gellens <[email-masked]>
Date: Sat, 4 Jun 2016 09:59:54 -0700

>  That is wrong. RFC 6086 says that any new INFO usage MUST use the INFO

Yes; there will still be an INFO package, to conform with this.

>  than an INFO packageS

-------------- Randomly selected tag: ---------------
Miners Refuse to Work after Death
--Newspaper headline

---

From: Randall Gellens <[email-masked]>
Date: Tue, 7 Jun 2016 17:57:54 -0700

Hi Keith,

The authors have been replying, and will be updating the draft taking 
the comments into account.  If you think we made a mistake and the 
draft doesn't reflect consensus, just let us know.

--Randy

At 4:45 PM +0000 6/3/16, Keith (Nokia - GB) Drage wrote:

>  This is a WG document, and is meant to reflect the consensus of the 
> working group, and not the authors thoughts and considerations.
>
>  Keith
>
>  Given a variety of factors, including individuals' availability, 
> the chairs have decided to Not schedule an interim meeting at this 
> time.  We look forward to seeing continued list discussion in order 
> to work through the current issues, and it seems like progress is 
> being made.  We also look forward to getting an updated draft soon, 
> so that folks can see the proposed text changes being discussed.
>
>  From: Ecrit 
> [<mailto:[email-masked]>mailto:[email-masked]] On 
> Behalf Of Roger Marshall
>  To: <mailto:[email-masked]>[email-masked]
>  The work group needs to figure out how it can address some of the 
> raised issues in order to make progress on 
> draft-ietf-ecrit-ecall-07.
>
> <http://doodle.com/poll/hnfhkvfgc7x6hesx>http://doodle.com/poll/hnfhkvfgc7x6hesx
>
>  Please mark your best available times to discuss.  Bridge 
> information will follow, once we have a timeslot identified.
>
>
>  NOTICE TO RECIPIENT: This email, including attachments, may contain 
> information which is confidential, proprietary, attorney-client 
> privileged and/or controlled under U.S. export laws and regulations 
> and may be restricted from disclosure by applicable State and 
> Federal law. Nothing in this email shall create any legal binding 
> agreement between the parties unless expressly stated herein and 
> provided by an authorized representative of Comtech 
> Telecommunications Corp. or its subsidiaries. If you are not the 
> intended recipient of this message, be advised that any 
> dissemination, distribution, or use of the contents of this message 
> is strictly prohibited. If you received this message in error, 
> please notify us immediately by return email and permanently delete 
> all copies of the original email and any attached documentation 
> from any computer or other media.
>

-------------- Randomly selected tag: ---------------
Invention is the mother of necessity.       --Thorstein Veblen

---

From: Randall Gellens <[email-masked]>
Date: Mon, 27 Jun 2016 17:41:58 -0700

Hi Christer,

>  Q1: Will ASN.1 be added in addition to XML? Or, will we remove XML?

I've added the ASN.1 PER encoding from Annex A of EN 15722, deleted 
the registration for the XML encoding of the MSD, and added a 
parenthetical aside to explicit note that it isn't used.

>
>  Q2: For ASN.1, which encoding will we use? CEN allows both UPER and 
> EXER. As 3GPP wants binary encoding, at least UPER needs to be 
> supported. What about EXER?

Since EN 15722 specifically defines the PER encoding as normative in 
Annex A, and since that is what's used in CS-eCall, and since my 
understanding is this is what 3GPP prefers, that's what I've included.

>  Q3: What will we do regarding the MSD max size of 140 bytes?

We don't need to do anything in this draft.  That's a 3GPP 
limitation, and the ASN.1 PER encoding meets that.

>  I'd also like to get some input regarding the 
> usage-of-modem-on-the-media-plane issue I raised earlier today. Do 
> we need to say something? What do we need to say?

i don't believe we need to say anything in this draft.

--Randy

>  I think you mean that you want to see all of your comments 
> addressed ahead of an updated draft, right?  I see comments being 
> made and some responses.
>
>  If you have comments that you believe haven't been addressed as 
> part of the list discussions, resend them.  Be sure to offer 
> proposed text to what you believe may be deficiencies in the 
> current draft.
>
>  -roger.
>
>  From: Drage, Keith (Nokia - GB) 
> [<mailto:[email-masked]>mailto:[email-masked]]
>  To: Roger Marshall; <mailto:[email-masked]>[email-masked]
>  To: Roger Marshall; <mailto:[email-masked]>[email-masked]

-------------- Randomly selected tag: ---------------
Beware of programmers who carry screwdrivers.  --Leonard Brandwein