Subject: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

From: Ivo Sedlacek <[email-masked]>
Date: Mon, 8 Aug 2016 07:58:57 +0000

Hello,

According to RFC3261, the Call-Info header field provides additional information about the caller or callee.

According to draft-ietf-ecrit-ecall-11, the Call-Info header field is used to form a "content-table" of pointers to bodies INVITE request (and of INVITE response, of INFO request) in headers of INVITE request (and of INVITE response, of INFO request).

If the Call-Info header field points to a body which describes the callers or callee, then Call-Info semantic fits (even though I would still question usefulness of such Call-Info inclusion).

If the Call-Info header field points to a body which request an action in remote UE and which reports to remote UE an outcome of an action done by the local UE, then Call-Info semantic does not fit.

Particularly:

------------------------------------------------------------------------------

   A PSAP or IVS transmits a metadata/control object (see Section 9) by

   encoding it per the description in this document and attaching it to

   a SIP message as a MIME body part per [RFC7852].  The body part is

   identified by its MIME content-type ('application/

   emergencyCallData.eCall.control+xml') in the Content-Type header

   field of the body part.  The body part is assigned a unique

   identifier which is listed in a Content-ID header field in the body

   part.  The SIP message is marked as containing the metadata/control

   object by adding (or appending to) a Call-Info header field at the

   top level of the SIP message.  This Call-Info header field contains a

   CID URL referencing the body part's unique identifier, and a

   'purpose' parameter identifying the data as an eCall metadata/control

   block per the Emergency Call Additional Data Blocks registry entry;

   the 'purpose' parameter's value is 'emergencyCallData.eCall.control'.

------------------------------------------------------------------------------

and

------------------------------------------------------------------------------

SIP/2.0 200 OK

      To: <sip:[email-masked]>;tag=9fxced76sl

      From: Exemplar PSAP <urn:service:sos.ecall.automatic>

      Call-ID: [email-masked]

      Call-Info: cid:[email-masked];

                 purpose=emergencyCallData.eCall.control;

      Accept: application/sdp, application/pidf+xml,

              application/emergencyCallData.eCall.control+xml,

              application/emergencyCallData.eCall.MSD+per

      CSeq: 31862 INVITE

      Recv-Info: emergencyCallData.eCall.MSD

      Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,

             SUBSCRIBE, NOTIFY, UPDATE

      Content-Type: multipart/mixed; boundary=boundaryX

      Content-Length: ...

      --boundaryX

      Content-Type: application/sdp

           ...Session Description Protocol (SDP) goes here...

      --boundaryX

      Content-Type: application/EmergencyCallData.eCall.control+xml

      Content-ID: [email-masked]

      Content-Disposition: by-reference;handling=optional

      <?xml version="1.0" encoding="UTF-8"?>

      <EmergencyCallData.eCall.Control

          xmlns="urn:ietf:params:xml:ns:EmergencyCallData:eCall:control"

          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

          xsi:schemaLocation=

              "urn:ietf:params:xml:ns:EmergencyCallData:eCall:control">

      <ack received="true" ref="[email-masked]"/>

      </EmergencyCallData.eCall.Control>

      --boundaryX--

------------------------------------------------------------------------------

Kind regards

Ivo

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, August 05, 2016 4:43 PM
To: [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value

Ivo,

IIUC, you are saying that the Call-Info that refers to the body is unnecessary because the recipient will know what to do with the body even in the absence of the Call-Info. Is that right?

This assumption mixes up two things:

- understanding a body syntactically

- understanding *why* the body is present and how it should be used.

Historically, processing of body parts in sip was very poorly defined.

Initially the only body of interest was SDP, so how one might process other bodies or body parts was not well considered. Eventually this started to be a liability, so RFC5621 was published to clarify it.

Processing of body parts is governed by a complex interaction between Content-Type, Content-Disposition, Content-ID.

So the call-info header indicates the reason that body is being included. I realize that there is one predominant reason for doing so, but that is not the only possible reason. (E.g., it might be included as context in an intended discussion about problems handling a call in the

past.)

If all the handling of the call is coded in a special purpose way, solely for the emergency call path, then alternatives may be of no concern. But ideally the call will largely be handled via standard library code that is also used for other call paths and other message processing. So processing body parts in a "standard" way, rather than special casing, is desirable.

                Thanks,

                Paul

On 8/5/16 7:15 AM, Ivo Sedlacek wrote:

> Hello,

> COMMENT:

> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

> \\\\\\\\

> Inclusion of Call-Info header field with

> purpose=emergencyCallData.eCall.MSD or

> purpose=emergencyCallData.eCall.control in requests and responses does

> not seem to bring any value. It seems to only waste radio resources.

> For Call-Info with purpose=emergencyCallData.eCall.MSD included in the

> initial INVITE request:

> - if this is meant to be used by a proxy for routing of the eCall

> emergency call to a PSAP supporting eCall emergency call, then this

> seems to be redundant to the eCall URN included in the Request-URI and

> the Recv-Info header field containing eCall specific info package

> (emergencyCallData.eCall.MSD).

> - if this is meant to be used by UAS (i.e. PSAP), then according to

> RFC3261 subclause 8.2.3, then the UAS anyway needs to check that all

> the bodies of the INVITE request not marked with Content-Disposition:

> ...; handling=optional are understood. So,

> application/emergencyCallData.eCall.MSD+per MIME body will anyway be

> found by UAS during the INVITE request processing.

> For Call-Info with purpose=emergencyCallData.eCall.control included in

> a response to the initial INVITE request

> - no routing decisions are done by proxies when receiving a response

> to the initial INVITE request so this does not seem to have any value

> for the proxies

> - UAC includes Accept with supported MIME types in INVITE request so

> why would UAS send any MIME body not wished by the UAC?

> For Call-Info with purpose=emergencyCallData.eCall.control included in

> the INFO request

> - no routing decisions are done by proxies when receiving an in-dialog

> request so this does not seem to have any value for the proxies

> - support of info package emergencyCallData.eCall.MSD in the call

> implies that either application/EmergencyCallData.eCall.control+xml

> MIME body or application/emergencyCallData.eCall.MSD+per MIME body is

> included. Again, according to RFC3261 subclause 8.2.3, the UAS anyway

> needs to check that all the bodies of the INFO request not marked with

> Content-Disposition: ...; handling=optional are understood. So,

> application/EmergencyCallData.eCall.control+xml MIME body or

> application/emergencyCallData.eCall.MSD+per MIME body will anyway be

> found by UAS during the INFO request processing.

> //////////////////////////////////////////////////////////////////////

> ////////

> PROPOSED SOLUTION to COMMENT

> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

> \\\\\\\\

> Remove insertion of Call-Info header field.

> //////////////////////////////////////////////////////////////////////

> ////////

> Kind regards

> Ivo Sedlacek

> _______________________________________________

> Ecrit mailing list

> [email-masked]<mailto:[email-masked]>

> https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________

Ecrit mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/ecrit

---

From: <[email-masked]>
Date: Mon, 8 Aug 2016 09:44:54 +0000

Hi Ivo,

using the ecall urn (urn:service:sos.ecall.automatic) does not implicitly means using the MSD within the Body. It could be also an interworked call where all ecall information is included inband using the In-band modem solution.

We have to think also on backwards compatibility issues.  Thus when moving PSAP's to SIP imply also that there must exist an interworking between the old mobile world towards the new mobile world using SIP.

Using the Call-Info header would help the PAST to distinguish the in-band and outband solution. Perhaps it would be worth to define an additional value for inband data, to identify ecalls coming from other networks not supporting the MSD Body.

Best Regards

Roland.

Von: Ecrit [mailto:[email-masked]] Im Auftrag von Ivo Sedlacek
Gesendet: Montag, 8. August 2016 09:59
An: Paul Kyzivat; [email-masked]
Betreff: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hello,

Particularly:

and

SIP/2.0 200 OK

      Call-ID: [email-masked]<mailto:[email-masked]>

      CSeq: 31862 INVITE

      Content-Length: ...

      --boundaryX

      --boundaryX

      Content-ID: [email-masked]<mailto:[email-masked]>

          xsi:schemaLocation=

      <ack received="true" ref="[email-masked]<mailto:[email-masked]>"/>

      --boundaryX--

Kind regards

Ivo

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, August 05, 2016 4:43 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value

Ivo,

past.)

                Thanks,

                Paul

Ecrit mailing list

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 8 Aug 2016 10:12:18 +0000

Hi,

We really need to separate the initial request (INVITE) of the call, and mid-call requests (INFO).

People seem to claim that Call-Info can be usable for routing and describing the semantics of the call.

When it comes to routing, once you've established the call mid-call requests will be routed using normal SIP procedures (using the route set). So, nothing additional is needed for routing.

When it comes to semantics, the info package description shall describe the semantics of the INFO. So, nothing additional is needed for that (at least nobody has indicated why it would be needed).

Just referencing additional-data is not a valid justification - especially since additional-data doesn't say anything about usage of INFO.

Also, in general, there are a number of SIP header fields that are included only in the INVITE. We don't insert header fields in mid-call requests just because they happen to be included in the initial INVITE. There shall be a reason for including header fields.

Regards,

Christer

From: Ecrit [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 08 August 2016 12:45
To: Ivo Sedlacek <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hi Ivo,

Best Regards

Roland.

Von: Ecrit [mailto:[email-masked]] Im Auftrag von Ivo Sedlacek
Gesendet: Montag, 8. August 2016 09:59
An: Paul Kyzivat; [email-masked]<mailto:[email-masked]>
Betreff: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hello,

Particularly:

and

SIP/2.0 200 OK

      CSeq: 31862 INVITE

      Content-Length: ...

      --boundaryX

      --boundaryX

          xsi:schemaLocation=

      --boundaryX--

Kind regards

Ivo

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, August 05, 2016 4:43 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value

Ivo,

past.)

                Thanks,

                Paul

Ecrit mailing list

---

From: Ivo Sedlacek <[email-masked]>
Date: Mon, 8 Aug 2016 11:40:57 +0000

Hello Roland,

UAS (i.e. PSAP) needs to check all the bodies of INVITE request (except where there is Content-Disposition with handling=optional), so it should be irrelevant for the PSAP whether the Call-Info with cid URL pointing to the body containing MSD is included or not. The actual presence of the body containing MSD in the INVITE is important for PSAP to decide whether NG-eCall emergency call takes place or in-band modem eCall emergency call takes place.

Furthermore, given that draft-ietf-ecrit-ecall mandates the UE to indicate support of the emergencyCallData.eCall.MSD info package in INVITE request, the routing of NG-eCall emergency call to a PSAP different than the one receiving in-band modem eCall emergency call can be done based on Recv-Info: emergencyCallData.eCall.MSD in INVITE request with Request-URI set to an eCall URN.

Kind regards

Ivo

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, August 08, 2016 11:45 AM
To: Ivo Sedlacek; [email-masked]; [email-masked]
Subject: AW: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hi Ivo,

Best Regards

Roland.

Hello,

Particularly:

and

SIP/2.0 200 OK

      CSeq: 31862 INVITE

      Content-Length: ...

      --boundaryX

      --boundaryX

          xsi:schemaLocation=

      --boundaryX--

Kind regards

Ivo

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, August 05, 2016 4:43 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value

Ivo,

past.)

                Thanks,

                Paul

Ecrit mailing list

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 8 Aug 2016 09:13:12 -0400

On 8/8/16 7:40 AM, Ivo Sedlacek wrote:
> Hello Roland,
>
>
>
> UAS (i.e. PSAP) needs to check all the bodies of INVITE request (except
> where there is Content-Disposition with handling=optional), so it should
> be irrelevant for the PSAP whether the Call-Info with cid URL pointing
> to the body containing MSD is included or not. The actual presence of
> the body containing MSD in the INVITE is important for PSAP to decide
> whether NG-eCall emergency call takes place or in-band modem eCall
> emergency call takes place.

By that logic there should *never* (for any SIP message) be a reason to 
refer to a body part from a header - the body should always be processed 
by virtue of its presence.

In this case, IIUC, there *could* be a call-info header pointing to the 
ecall info in an external server. The data being in a body part is 
simply a special case of that. So it makes sense to me that the starting 
point for discovering ecall data be with the call-info header. (Again, 
I'm not talking about INFO here. The situation is different for it.)

> Furthermore, given that draft-ietf-ecrit-ecall mandates the UE to
> indicate support of the emergencyCallData.eCall.MSD info package in
> INVITE request, the routing of NG-eCall emergency call to a PSAP
> different than the one receiving in-band modem eCall emergency call can
> be done based on Recv-Info: emergencyCallData.eCall.MSD in INVITE
> request with Request-URI set to an eCall URN.

The indication of support for info packages in the INVITE is intended to 
facilitate negotiation of the use of INFO. IMO using that to affect how 
bodies in the INVITE itself is wrong.

	Thanks,
	Paul

> Kind regards
>
>
>
> Ivo
>
>
>
> *From:[email-masked] [mailto:[email-masked]]
> *Sent:* Monday, August 08, 2016 11:45 AM
> *To:* Ivo Sedlacek; [email-masked]; [email-masked]
> *Subject:* AW: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not
> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage
> brings no value)
>
>
>
> Hi Ivo,
>
> using the ecall urn (urn:service:sos.ecall.automatic) does not
> implicitly means using the MSD within the Body. It could be also an
> interworked call where all ecall information is included inband using
> the In-band modem solution.
>
>
>
> We have to think also on backwards compatibility issues.  Thus when
> moving PSAP’s to SIP imply also that there must exist an interworking
> between the old mobile world towards the new mobile world using SIP.
>
>
>
> Using the Call-Info header would help the PAST to distinguish the
> in-band and outband solution. Perhaps it would be worth to define an
> additional value for inband data, to identify ecalls coming from other
> networks not supporting the MSD Body.
>
>
>
> Best Regards
>
>
> Roland.
>
>
>
>
>
> *Von:*Ecrit [mailto:[email-masked]] *Im Auftrag von *Ivo Sedlacek
> *Gesendet:* Montag, 8. August 2016 09:59
> *An:* Paul Kyzivat; [email-masked] <mailto:[email-masked]>
> *Betreff:* [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not
> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage
> brings no value)
>
>
>
> Hello,
>
>
>
> According to draft-ietf-ecrit-ecall-11, the Call-Info header field is
> used to form a "content-table" of pointers to bodies INVITE request (and
> of INVITE response, of INFO request) in headers of INVITE request (and
> of INVITE response, of INFO request).
>
>
>
> If the Call-Info header field points to a body which describes the
> callers or callee, then Call-Info semantic fits (even though I would
> still question usefulness of such Call-Info inclusion).
>
>
>
> If the Call-Info header field points to a body which request an action
> in remote UE and which reports to remote UE an outcome of an action done
> by the local UE, then Call-Info semantic does not fit.
>
>
>
> Particularly:
>
> <mailto:[email-masked]>
>
> <mailto:[email-masked]>
>
>       <ack received="true" ref="[email-masked]
> <mailto:[email-masked]>"/>
>
>
>
> To: [email-masked] <mailto:[email-masked]>
> IIUC, you are saying that the Call-Info that refers to the body is
> unnecessary because the recipient will know what to do with the body
> even in the absence of the Call-Info. Is that right?
>
>
>
> Initially the only body of interest was SDP, so how one might process
> other bodies or body parts was not well considered. Eventually this
> started to be a liability, so RFC5621 was published to clarify it.
>
>
>
> Processing of body parts is governed by a complex interaction between
> Content-Type, Content-Disposition, Content-ID.
>
>
>
> So the call-info header indicates the reason that body is being
> included. I realize that there is one predominant reason for doing so,
> but that is not the only possible reason. (E.g., it might be included as
> context in an intended discussion about problems handling a call in the
>
> past.)
>
>
>
> If all the handling of the call is coded in a special purpose way,
> solely for the emergency call path, then alternatives may be of no
> concern. But ideally the call will largely be handled via standard
> library code that is also used for other call paths and other message
> processing. So processing body parts in a "standard" way, rather than
> special casing, is desirable.
>
>
>
>                 Thanks,
>
>                 Paul
>
>
>
>> [email-masked] <mailto:[email-masked]>
>
> [email-masked] <mailto:[email-masked]>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 8 Aug 2016 14:10:16 +0000

Hi,

> In this case, IIUC, there *could* be a call-info header pointing to the ecall info in an external server. The data being in a body part is simply a special case of that.
>
> So it makes sense to me that the starting point for discovering ecall data be with the call-info header. 

In theory you could put ANY information associated with the call - including SDP - on an external server. Does that mean we should always include call-info for every call, as a starting point to discover the information???

*IF* someone defines the procedures associated with retrieving data from an external server, he/she needs to define the procedures associated with that. Currently no such cases exist for ecall.

Regards,

Christer

> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info 
> usage brings no value)
>
>
>
> Hi Ivo,
>
> moving PSAP's to SIP imply also that there must exist an interworking 
> aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info 
> usage brings no value)
>
>
>
> Hello,
>
>
>
> used to form a "content-table" of pointers to bodies INVITE request 
> (and of INVITE response, of INFO request) in headers of INVITE request 
> (and of INVITE response, of INFO request).
>
>
>
> in remote UE and which reports to remote UE an outcome of an action 
> done by the local UE, then Call-Info semantic does not fit.
>
>
>
> Particularly:
>
> but that is not the only possible reason. (E.g., it might be included 
> as context in an intended discussion about problems handling a call in 
> the
>
> past.)
>
>
>

[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 8 Aug 2016 10:39:28 -0400

> In theory you could put ANY information associated with the call - including SDP - on an external server. Does that mean we should always include call-info for every call, as a starting point to di…

You go too far mentioning SDP. The mechanism for O/A is explicitly 
limited to use of a body - there is no provision for dereferencing a URL 
to obtain the SDP.

But I will take your point. I haven't been paying close enough attention 
to the details of the draft. I see that it is effectively specifying 
that when the call-info has purpose="emergencyCallData.eCall.MSD" then 
it MUST have a CID URL.

But still, how is the processing of the body specified. I see the 
following used:

This specifically says that the disposition of the body is determined by 
a *reference* to the body. If the call-info isn't used there won't be 
any reference.

If you want to remove the call-info, then you need to define a new c-d 
type that specifies how the body part is to be processed. The 
content-type isn't sufficient by itself, since there could be a variety 
of ways it can be disposed of. E.g., it could be rendered, or logged. 
"Render" is the default, but "render" has no clear meaning in SIP - it 
was really intended for email.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 8 Aug 2016 15:03:50 +0000

Hi,

...

> But I will take your point. I haven't been paying close enough attention to the details of the draft. I see that 
> it is effectively specifying that when the call-info has purpose="emergencyCallData.eCall.MSD" then it MUST have a CID URL.
>
> But still, how is the processing of the body specified. I see the following used:
>
> This specifically says that the disposition of the body is determined by a *reference* to the body. If the call-info isn't used there won't be any reference.
>
> If you want to remove the call-info, then you need to define a new c-d type that specifies how the body part is to be 
> processed. The content-type isn't sufficient by itself, since there could be a variety of ways it can be disposed of. E.g., it 
> could be rendered, or logged. 
> "Render" is the default, but "render" has no clear meaning in SIP - it was really intended for email.

At this point I am not saying we should remove it from INVITE - I am saying we don't need it for INFO (and, when used within INFO, the C-D value shall be "Info-Package").

Regarding INVITE, I am trying to understand for what it is needed.

Regards,

Christer

>> additional value for inband data, to identify ecalls coming from 
>> other networks not supporting the MSD Body.
>>
>>
>>
>> Best Regards
>>
>>
>> Roland.
>>
>>
>>
>>
>>
>> (and of INVITE response, of INFO request) in headers of INVITE 
>> request (and of INVITE response, of INFO request).
>>
>>
>>
>> If the Call-Info header field points to a body which request an 
>> action in remote UE and which reports to remote UE an outcome of an 
>> action done by the local UE, then Call-Info semantic does not fit.
>>
>>
>>
>> Particularly:
>>
>> ---------------------------------------------------------------------
>> -
>> --------
>>
>> ---------------------------------------------------------------------
>> -
>> --------
>>
>> and
>>
>> ---------------------------------------------------------------------
>> -
>> --------
>>
>> SIP/2.0 200 OK
>>
>> ---------------------------------------------------------------------
>> -
>> --------
>>
>>
>>
>> Kind regards
>>
>>
>>
>> Ivo
>>
>>
>>
>> included. I realize that there is one predominant reason for doing 
>> so, but that is not the only possible reason. (E.g., it might be 
>> included as context in an intended discussion about problems handling 
>> a call in the
>>
>> past.)
>>
>>
>>
>>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
>>> \
>>> \
>>
>>> \\\\\\\\
>>
>>>
>>
>>> ////////////////////////////////////////////////////////////////////
>>> /
>>> /
>>
>>> ////////
>>
>>>
>>
>>> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
>>> \
>>> \
>>
>>> \\\\\\\\
>>
>>>
>>
>>> ////////////////////////////////////////////////////////////////////
>>> /
>>> /
>>
>>> ////////
>>
>>>
>>
>>>
>>
>>>
>>
>>> Kind regards
>>
>>>
>>
>>>
>>
>>>
>>
>>> Ivo Sedlacek
>>
>>>
>>
>>>
>>
>>>
>>

---

From: Ivo Sedlacek <[email-masked]>
Date: Mon, 8 Aug 2016 15:22:20 +0000

> So it makes sense to me that the starting point for discovering ecall data be with the call-info header. (Again, I'm not talking about INFO here. The situation is different for it.)

In case of draft-ietf-ecrit-ecall-11, the Call-Info in an INVITE *always* points to the body of the same INVITE.

And, again, semantically the Call-Info is supposed to carry info about callee or caller according to RFC3261. 

If the Call-Info header field points to a body which request an action in remote UE and which reports to remote UE an outcome of an action done by the local UE, then Call-Info semantic does not fit. A new header field would need to be defined for that purpose.

Kind regards

Ivo

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 8 Aug 2016 12:54:12 -0400

> If the Call-Info header field points to a body which request an action in remote UE and which reports to remote UE an outcome of an action done by the local UE, then Call-Info semantic does not fit…

If you don't want to use call-info, then define a new 
content-disposition value that signifies what to do with the content. 
(Content-type only says what it *is*, not what to do with it.) The c-d 
of "by-reference" doesn't make sense in this case.

	Thanks,
	Paul

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 9 Aug 2016 14:23:07 +0000

Hello,

given the use case raised by Roland and clarified by Paul, let me suggest the following compromise: 

	Call-Info included in an INVITE request and pointing to the application/emergencyCallData.eCall.MSD+per body of the INVITE request is kept, while Call-Info in a response to the INVITE request and in an INFO request is removed.

Does this work for everyone?

Kind regards

Ivo Sedlacek

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 9 Aug 2016 12:01:41 -0400

> Does this work for everyone?

I agree wrt INFO, but not for INVITE response.

The invite response still has a body with content-disposition 
by-reference. If you remove the reference then its processing is undefined.

	Thanks,
	Paul

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 10 Aug 2016 07:41:08 +0000

Hello,

> The invite response still has a body with content-disposition by-reference. If you remove the reference then its processing is undefined.

If the Call-Info is omitted in INVITE response, then:
Alt1: a new value could be defined and used in the Content-Disposition header field of the application/emergencyCallData.eCall.control+xml body;
	or
Alt2: an existing value could be used in the Content-Disposition header field of the application/emergencyCallData.eCall.control+xml body;
	or
Alt3: the Content-Disposition header field can be omitted and thus "render" would apply for the application/emergencyCallData.eCall.control+xml body according to RFC3261 section 13.2.1.

We cannot use the Call-Info in INVITE response as described in  draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, the Call-Info points to the application/emergencyCallData.eCall.control+xml body. This body contains a delivery report for the MSD sent in INVITE request. This is NOT information about callee as described in RFC3261. 

Kind regards

Ivo

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Aug 2016 10:43:18 -0400

> Alt1: a new value could be defined and used in the Content-Disposition header field of the application/emergencyCallData.eCall.control+xml body;

This would "work", and it doesn't seem to violate anything

> Alt2: an existing value could be used in the Content-Disposition header field of the application/emergencyCallData.eCall.control+xml body;

This would work if there is an existing one with appropriate semantics.
There are only a few for which the *sip* semantics are defined. And I 
don't think any of those fit.

There are others (i.e. "render") that on the surface seem like they 
*might* fit. But their semantics wrt sip are undefined. This would need 
to be thrashed out.

> Alt3: the Content-Disposition header field can be omitted and thus "render" would apply for the application/emergencyCallData.eCall.control+xml body according to RFC3261 section 13.2.1.

Same as Alt2 using "render".

> We cannot use the Call-Info in INVITE response as described in  draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, the Call-Info points to the application/emergencyCallData.eCall.co…

Using call-info here seems to be at least a small abuse if the intended 
semantics of call-info. We can perhaps argue if the usage is wrong or 
the definition of call-info is wrong.

The definition of a new c-d appears to be the "cleanest", but it also is 
going to be viewed by many as overkill to avoid a trivial bending of the 
usage of call-info.

If a new c-d is defined, then presumably it should also be used in the 
INVITE.

	Thanks,
	Paul

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 10 Aug 2016 15:11:49 +0000

Unless someone is defining a new usage for Call-Info beyond RFC7852 then I have to agree with Ivo. That additional usage is not currently defined in draft-ietf-ecrit-ecall, and I would need to understand that usage before it is included.

At the moment RFC7852 is only used for the transfer of MSD in INVITE requests and 200 (OK) responses, and therefore that is the only place where it should appear in association with RFC7852.

Negotiation and transfer of MSD in association with INFO requests is an entirely separate transfer mechanism, not covered by draft-ietf-ecrit-data-only-ea and therefore it should never appear there as though it had been. Inclusion will lead to complete confusion as to whether the requirements of the INFO mechanism or the requirements of draft-ietf-ecrit-data-only-ea apply, when it should be absolutely clear that only the former apply.

Regards

Keith

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: 10 August 2016 08:41
To: Paul Kyzivat; [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hello,

Kind regards

Ivo

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 10 Aug 2016 15:11:51 +0000

I fundamentally disagree. We have two different data transfer mechanisms, and the presence of the data should be clearly understood from the appropriate transfer mechanism protocol.

So Call-Info applies when RFC 7852 applies, which is the INVITE and 200 (OK) response, and does not when the INFO mechanism is in use.

Additionally it only applies when it is pointing to data which is actually attached to the message.

Keith

From: Ecrit [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 08 August 2016 10:45
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hi Ivo,

Best Regards

Roland.

Hello,

Particularly:

and

SIP/2.0 200 OK

      CSeq: 31862 INVITE

      Content-Length: ...

      --boundaryX

      --boundaryX

          xsi:schemaLocation=

      --boundaryX--

Kind regards

Ivo

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, August 05, 2016 4:43 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value

Ivo,

past.)

                Thanks,

                Paul

Ecrit mailing list

---

From: Randall Gellens <[email-masked]>
Date: Wed, 10 Aug 2016 10:12:52 -0700

At 7:41 AM +0000 8/10/16, Ivo Sedlacek wrote:

>  Alt1: a new value could be defined and used in the 
> Content-Disposition header field of the 
> application/emergencyCallData.eCall.control+xml body;
>  	or
>  Alt2: an existing value could be used in the Content-Disposition 
> header field of the application/emergencyCallData.eCall.control+xml 
> body;
>  	or
>  Alt3: the Content-Disposition header field can be omitted and thus 
> "render" would apply for the 
> application/emergencyCallData.eCall.control+xml body according to 
> RFC3261 section 13.2.1.
>
>  We cannot use the Call-Info in INVITE response as described in 
> draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, 
> the Call-Info points to the 
> application/emergencyCallData.eCall.control+xml body. This body 
> contains a delivery report for the MSD sent in INVITE request. This 
> is NOT information about callee as described in RFC3261.

Hi Ivo,

Call-Info is used in accordance with RFC 7852.

--Randy

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
History has the relation to truth that theology has to
religion -- i.e., none to speak of.     --Lazarus Long

---

From: Randall Gellens <[email-masked]>
Date: Wed, 10 Aug 2016 10:17:16 -0700

At 10:43 AM -0400 8/10/16, Paul Kyzivat wrote:

>> header field of the 
>  There are only a few for which the *sip* semantics are defined. And 
> I don't think any of those fit.
>
> *might* fit. But their semantics wrt sip are undefined. This would 
> need to be thrashed out.
>
>> contains a delivery report for the MSD sent in INVITE request. 
>> This is NOT information about callee as described in RFC3261.
>
>  Using call-info here seems to be at least a small abuse if the 
> intended semantics of call-info. We can perhaps argue if the usage 
> is wrong or the definition of call-info is wrong.

Use of Call-Info to identify emergency data blocks is defined in RFC 7852.

>
>  The definition of a new c-d appears to be the "cleanest", but it 
> also is going to be viewed by many as overkill to avoid a trivial 
> bending of the usage of call-info.
>
>  If a new c-d is defined, then presumably it should also be used in 
> the INVITE.
>
>  	Thanks,
>  	Paul
>

-------------- Randomly selected tag: ---------------
Computer Science: solving today's problems tomorrow.

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 10 Aug 2016 17:19:28 +0000

Is this response only in respect of the INVITE / 200 (OK) inclusion?

Keith

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Randall Gellens
Sent: 10 August 2016 18:13
To: Ivo Sedlacek; Paul Kyzivat; [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

At 7:41 AM +0000 8/10/16, Ivo Sedlacek wrote:

> draft-ietf-ecrit-ecall-11 - in the response to the INVITE request, the 
> Call-Info points to the 
> contains a delivery report for the MSD sent in INVITE request. This is 
> NOT information about callee as described in RFC3261.

Hi Ivo,

--Randy

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- History has the relation to truth that theology has to
religion -- i.e., none to speak of.     --Lazarus Long

---

From: Randall Gellens <[email-masked]>
Date: Wed, 10 Aug 2016 10:19:55 -0700

Hi Keith,

At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote:

>  Unless someone is defining a new usage for Call-Info beyond RFC7852 
> then I have to agree with Ivo. That additional usage is not 
> currently defined in draft-ietf-ecrit-ecall, and I would need to 
> understand that usage before it is included.
>
>  At the moment RFC7852 is only used for the transfer of MSD in 
> INVITE requests and 200 (OK) responses, and therefore that is the 
> only place where it should appear in association with RFC7852.

RFC 7852 covers use of Call-Info to point to emergency call data 
blocks in any SIP message that is permitted to carry a body.

>
>  Negotiation and transfer of MSD in association with INFO requests 
> is an entirely separate transfer mechanism, not covered by 
> draft-ietf-ecrit-data-only-ea and therefore it should never appear 
> there as though it had been. Inclusion will lead to complete 
> confusion as to whether the requirements of the INFO mechanism or 
> the requirements of draft-ietf-ecrit-data-only-ea apply, when it 
> should be absolutely clear that only the former apply.
>
>  Regards
>
>  Keith
>
>  Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not 

-------------- Randomly selected tag: ---------------
The idea that Bill Gates has appeared like a knight in shining armor
to lead all customers out of a mire of technological chaos neatly
ignores the fact that it was he who, by peddling second-rate technology,
led them into it in the first place.                    --Douglas Adams

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 10 Aug 2016 17:29:27 +0000

I disagree.

The inclusion of the data element in INFO is nothing to do with RFC 7852. The data element is included because the use of an appropriate Info package has been negotiated and used. That Info package definition and the INFO mechanism itself makes no mention of use of Call-Info in association with it. 

Further I see no justification for complicating any error handling by suddenly defining it to be applicable, as it is not necessary. INFO requests always contain a data element appropriate to the Info package that is defined for its use - it absolutely does not need a secondary reference to the package.

Keith

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: 10 August 2016 18:20
To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hi Keith,

At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote:

> then I have to agree with Ivo. That additional usage is not currently 
> defined in draft-ietf-ecrit-ecall, and I would need to understand that 
> usage before it is included.
>
>  At the moment RFC7852 is only used for the transfer of MSD in INVITE 
> requests and 200 (OK) responses, and therefore that is the only place 
> where it should appear in association with RFC7852.

RFC 7852 covers use of Call-Info to point to emergency call data blocks in any SIP message that is permitted to carry a body.

>
>  Negotiation and transfer of MSD in association with INFO requests is 
> an entirely separate transfer mechanism, not covered by 
> there as though it had been. Inclusion will lead to complete confusion 
> as to whether the requirements of the INFO mechanism or the 
> requirements of draft-ietf-ecrit-data-only-ea apply, when it should be 
> absolutely clear that only the former apply.
>
>  Regards
>
>  Keith
>

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- The idea that Bill Gates has appeared like a knight in shining armor to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he who, by peddling second-rate technology,
led them into it in the first place.                    --Douglas Adams

---

From: Brian Rosen <[email-masked]>
Date: Wed, 10 Aug 2016 13:45:21 -0400

Just for the moment, put aside any specific issues with eCall.

We/ve agreed that if one needs a mid-call update of Additional Data, that one defines a new INFO package and uses that to send such an update.

Use some case like alarm data: you get alarm status when the INVITE arrives with a call, and you can get an update of that alarm data mid call using INFO.

In these cases, the EXACT same data is being sent, for the exact same use, with the only difference being mid call vs call establishment.  That’s very clearly Additional Data.

Should the MIME type be different for these use cases?

Is the mid call update different from the call establishment in any respect other than the sip message used?

I agree that including the Call-Info is duplicative of the INFO, but is it harmful?

Is eCall so fundamentally different that it warrants a completely different answer?

Brian

> 
>> On Aug 10, 2016, at 1:29 PM, Drage, Keith (Nokia - GB) <[email-masked]> wrote:
>> 
>> I disagree.
>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Aug 2016 17:54:04 +0000

Hi Brian,

Maybe I’ve missed something, but I don’t think anyone has said that you need to use different MIME types. You can use the same MIME type in INVITE and INFO, and you can use the same MIME type in different info packages.

Regards,

Christer

From: Ecrit [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: 10 August 2016 20:45
To: Emergency Context Resolution with Internet Technologies Discussion List <[email-masked]>
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Brian

On Aug 10, 2016, at 1:29 PM, Drage, Keith (Nokia - GB) <[email-masked]<mailto:[email-masked]>> wrote:

I disagree.

Keith

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]]
Sent: 10 August 2016 18:20
To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hi Keith,

Regards

Keith

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: 10 August 2016 08:41
To: Paul Kyzivat; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not

Hello,

The invite response still has a body with content-disposition
by-reference. If you remove the reference then its processing is
undefined.

Kind regards

Ivo

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Aug 2016 18:03:15 +0000

Hi,

Again, as we have discussed before, RFC 7852 does not apply to INFO. And, we did agree to not carry the bodies in INFO responses.

And, again, in INFO we won't use the "by-reference" content type, which is another example why you can't apply RFC 7852 to INFO.

I DID raise these issues before 7852 was published, but was told it's too late to change at that point. So, maybe we need to correct 7852 if that is unclear.

Regards,

Christer

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Randall Gellens
Sent: 10 August 2016 20:20
To: Drage, Keith (Nokia - GB) <[email-masked]>; Ivo Sedlacek <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hi Keith,

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 10 Aug 2016 18:13:59 +0000

I think it the inclusion of Call-Info in INFO requests introduces additional complexities in protocol processing, which could result in the data element not being processed, which in my view is harmful.

If for example, the Call-Info is sent with a one character error in the reference text (the header field value), we could well end up with the recipient dropping the data element.

Keeping it simple means not including anything beyond that required by the SIP part of the data transfer protocol. That protocol is the INFO mechanism with the appropriate package definition.

I do agree that we could do more in the draft to stress that we do have two entirely separate SIP data transfer mechanism – obviously both contain MSDs, coded using the same syntax, but the surrounding protocol is different. As a result the error handling is that defined for each individual transfer mechanism, and not carried over to the other. Data from the two separate mechanism is only combined in a layer above the SIP actions.

I do not believe the MIME type needs to be different, the MIME type describes the body syntax and the body is one and the same (at the moment). We are discussing Call-Info versus the Info-Package header fields, both of which perform similar tasks in identifying a body and the usage it belongs to, each for its appropriate data transfer mechanism.

Keith

From: Ecrit [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: 10 August 2016 18:45
To: Emergency Context Resolution with Internet Technologies Discussion List
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Brian

I disagree.

Keith

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]]
Sent: 10 August 2016 18:20
To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hi Keith,

Regards

Keith

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: 10 August 2016 08:41
To: Paul Kyzivat; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not

Hello,

Kind regards

Ivo

---

From: Randall Gellens <[email-masked]>
Date: Wed, 10 Aug 2016 14:30:59 -0700

I see it as one data transfer mechanism, which has additional 
restrictions/impositions when used with INFO.  INFO has various 
prohibitions and restrictions and mandates in an attempt to reign in 
the former freewheeling use of INFO as a generic data transfer 
mechanism.  In our case, we're using INFO only for mid-call updates, 
and only because it seemed at the time to be cleaner than using 
re-INVITE or UPDATE or OPTIONS or something else.  If we diverge into 
two entirely separate mechanisms, one just for INFO, then we will do 
a disservice to emergency call processing.

At 3:11 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote:

>
>  I fundamentally disagree. We have two different data transfer 
> mechanisms, and the presence of the data should be clearly 
> understood from the appropriate transfer mechanism protocol.
>
>  So Call-Info applies when RFC 7852 applies, which is the INVITE and 
> 200 (OK) response, and does not when the INFO mechanism is in use.
>
> interworked call where all ecall information is included inband 
> using the In-band modem solution.
>
> moving PSAP's to SIP imply also that there must exist an 
> interworking between the old mobile world towards the new mobile 
> world using SIP.
>
> in-band and outband solution. Perhaps it would be worth to define 
> an additional value for inband data, to identify ecalls coming from 
>  Von: Ecrit 
> [<mailto:[email-masked]>mailto:[email-masked]] Im 
> Auftrag von Ivo Sedlacek
>  An: Paul Kyzivat; <mailto:[email-masked]>[email-masked]
>  Betreff: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not 
>  According to RFC3261, the Call-Info header field provides 
> additional information about the caller or callee.
>
>  According to draft-ietf-ecrit-ecall-11, the Call-Info header field 
> is used to form a "content-table" of pointers to bodies INVITE 
> request (and of INVITE response, of INFO request) in headers of 
> INVITE request (and of INVITE response, of INFO request).
>
> callers or callee, then Call-Info semantic fits (even though I 
> would still question usefulness of such Call-Info inclusion).
>
>        To: 
> <<sip:[email-masked]>sip:[email-masked]>;tag=9fxced76sl
>        Call-ID: <mailto:[email-masked]> 
> [email-masked]
>        Call-Info: 
> <cid:[email-masked]>cid:[email-masked];
>        Content-ID: 
> <mailto:[email-masked]>[email-masked]
> xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>http://www.w3.org/2001/XMLSchema-instance"
>            xsi:schemaLocation=
>        <ack received="true" 
> ref="<mailto:[email-masked]>[email-masked]"/>
>
>  From: Ecrit 
> [<mailto:[email-masked]>mailto:[email-masked]] On 
> Behalf Of Paul Kyzivat
>  To: <mailto:[email-masked]>[email-masked]
> unnecessary because the recipient will know what to do with the 
> body even in the absence of the Call-Info. Is that right?
>
>  Initially the only body of interest was SDP, so how one might 
> process other bodies or body parts was not well considered. 
> Eventually this started to be a liability, so RFC5621 was published 
> to clarify it.
>
>  Processing of body parts is governed by a complex interaction 
> between Content-Type, Content-Disposition, Content-ID.
>
> included as context in an intended discussion about problems 
> handling a call in the
>  past.)
>
> library code that is also used for other call paths and other 
> message processing. So processing body parts in a "standard" way, 
> rather than special casing, is desirable.
>
>                  Thanks,
>                  Paul
>
>   > <mailto:[email-masked]>[email-masked]
>   > 
> <https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit
>   >
>
>  <mailto:[email-masked]>[email-masked]
> 
> <https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit
>

-------------- Randomly selected tag: ---------------
I asked President Reagan what he thought about the IBM PC Jr.,
and he replied that he didn't believe in abortions
                                             --Steve Wozniac

---

From: Randall Gellens <[email-masked]>
Date: Wed, 10 Aug 2016 14:36:07 -0700

As I see it, we have one data transfer mechanism which is used in all 
messages and responses.

At 5:19 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote:

>  -------------- Randomly selected tag: --------------- History has 
> the relation to truth that theology has to

-------------- Randomly selected tag: ---------------
Dr. Beverly Crusher to Wesley Crusher as he is about to beam down to
begin his journey with the Traveler into other dimensions: "Be sure to
dress warmly on those other planes of existence."

---

From: Randall Gellens <[email-masked]>
Date: Wed, 10 Aug 2016 14:38:42 -0700

In reality, there is no separate INFO package negotiation.  The 
endpoints support the data types not because they support the iNFO 
package, but rather they support the INFO package and the data types 
and Call-Info because they comply with the draft.

At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote:

>  I disagree.
>
>  The inclusion of the data element in INFO is nothing to do with RFC 
> 7852. The data element is included because the use of an 
> appropriate Info package has been negotiated and used. That Info 
> package definition and the INFO mechanism itself makes no mention 
> of use of Call-Info in association with it.
>
>  Further I see no justification for complicating any error handling 
> by suddenly defining it to be applicable, as it is not necessary. 
> INFO requests always contain a data element appropriate to the Info 
> package that is defined for its use - it absolutely does not need a 
> secondary reference to the package.
>
>  Keith
>
>  -------------- Randomly selected tag: --------------- The idea that 
> Bill Gates has appeared like a knight in shining armor to lead all 
> customers out of a mire of technological chaos neatly ignores the 
> fact that it was he who, by peddling second-rate technology,

-------------- Randomly selected tag: ---------------
Einstein never accepted quantum mechanics because of this element
of chance and uncertainty. He said, "God does not play dice."
It seems that Einstein was doubly wrong. The quantum effects
of black holes suggests that not only does God play dice, He
sometimes throws them where they cannot be seen.  --Steven Hawking

---

From: Randall Gellens <[email-masked]>
Date: Wed, 10 Aug 2016 14:45:53 -0700

Hi Christer,

RFC 7852 is not excluded for use in INFO.

We did agree to not send data in an INFO response, not because it is 
harmful to do so, but to avoid argument about legalistic 
interpretations of INFO.  In our case, INFO is being used exactly as 
any other SIP message, not in any special/unique way.  I realize that 
to some, INFO is the unaccompanied minor of SIP messages: it must be 
constantly chaperoned and protected against wanton misuse as a 
generic transport mechanism where random data types are sent to 
unsuspecting endpoints that don't know how to process them.  That's 
an entirely different situation than we have.  We have endpoints in a 
limited domain that exchange a very small number of data types.

At 6:03 PM +0000 8/10/16, Christer Holmberg wrote:

>  Hi,
>
>  Again, as we have discussed before, RFC 7852 does not apply to 
> INFO. And, we did agree to not carry the bodies in INFO responses.
>
>  And, again, in INFO we won't use the "by-reference" content type, 
> which is another example why you can't apply RFC 7852 to INFO.
>
>  I DID raise these issues before 7852 was published, but was told 
> it's too late to change at that point. So, maybe we need to correct 
> 7852 if that is unclear.
>
>  Regards,
>
>  Christer
>
>
>  To: Drage, Keith (Nokia - GB) <[email-masked]>; Ivo Sedlacek 
> <[email-masked]>; Paul Kyzivat <[email-masked]>; 
> [email-masked]

-------------- Randomly selected tag: ---------------
...All repairs tend to destroy the structure [of the software], to
  increase the entropy and disorder of the system.  Less and less
  effort is spent on fixing original design flaws; more and more is
  spent on fixing flaws introduced by earlier fixes.  As time passes,
  the system becomes less and less well-ordered.  Sooner or later the
  fixing ceases to gain any ground.  Each forward step is matched by a
  backward one.  Although in principle usable forever, the system has
  worn out as a base for progress.  [...] Systems program building is
  an entropy-decreasing process, hence inherently metastable.  Program
  maintenance is an entropy-increasing process, and even its most
  skillful execution only delays the subsidence of the system into
  unfixable obsolescence.
                             --Fred Brooks in _The Mythical Man Month_

---

From: <[email-masked]>
Date: Thu, 11 Aug 2016 05:28:58 +0000

Hi Keith,
since my statement I learned from the mail discussion hat such a mechanism is not appropriate. So I agree your statement.
Nevertheless another mechanism for inband indication of ecall would be nice but I understand that such an issue is more or less out of scope of this draft.

Best Regards

Roland

Von: Drage, Keith (Nokia - GB) [mailto:[email-masked]]
Gesendet: Mittwoch, 10. August 2016 17:12
An: Jesske, Roland; [email-masked]; [email-masked]; [email-masked]
Betreff: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Keith

From: Ecrit [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 08 August 2016 10:45
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hi Ivo,

Best Regards

Roland.

Hello,

Particularly:

and

SIP/2.0 200 OK

      CSeq: 31862 INVITE

      Content-Length: ...

      --boundaryX

      --boundaryX

          xsi:schemaLocation=

      --boundaryX--

Kind regards

Ivo

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, August 05, 2016 4:43 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage brings no value

Ivo,

past.)

                Thanks,

                Paul

Ecrit mailing list

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Aug 2016 05:55:58 +0000

Hi,

>mechanism.  In our case, we're using INFO only for mid-call updates,

We don¹t have the authority to say ³Well, we only use INFO for this
special case, so therefore we don¹t need to follow RFC 6086².

And, most usages of INFO are for a specific purpose. That¹s the whole idea
of the info package mechanism - to to have a clear scope and semantics of
the usage.

>a disservice to emergency call processing.

The difference is on the SIP level. As the same MIME types etc are used,
the applications will see no difference.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Aug 2016 05:59:48 +0000

Hi,

>and Call-Info because they comply with the draft.

Specifications may mandate you to support certain SIP extensions in order
to be compliant with the specification, but you still need to comply with
the SIP procedures associated with indicating support and using those
extensions.

Regards,

Christer

>>is

---

From: Randall Gellens <[email-masked]>
Date: Thu, 11 Aug 2016 00:44:16 -0700

At 5:55 AM +0000 8/11/16, Christer Holmberg wrote:

>  We don't have the authority to say "Well, we only use INFO for this
>  special case, so therefore we don't need to follow RFC 6086".

We are following RFC 6086.

>
>  And, most usages of INFO are for a specific purpose. That's the whole idea

-------------- Randomly selected tag: ---------------
Probable-Possible, my black hen,
She lays eggs in the Relative When.
She doesn't lay eggs in the Positive Now
Because she's unable to postulate how.
            --Frederick Winsor, "The Space Child's Mother Goose"
              [Simon & Schuster 1966], paperback

---

From: Randall Gellens <[email-masked]>
Date: Thu, 11 Aug 2016 00:54:56 -0700

Hi Christer,

We are complying, of course.

--Randy

-------------- Randomly selected tag: ---------------
The brain is a wonderful organ; it starts working the moment you get
up in the morning, and does not stop until you get to work.
                                                      --Robert Frost

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 11 Aug 2016 07:59:13 +0000

Hello,

> Use of Call-Info to identify emergency data blocks is defined in RFC 7852.

RFC 7852 does not change RFC3261 so any usage of Call-Info must be compliant to RFC3261 definition of the Call-Info. I.e. Call-Info must provide additional information about the caller or callee. 

This is NOT the case of Call-Info usage of draft-ietf-ecrit-ecall-11 in INVITE response and INFO request.

In short: draft-ietf-ecrit-ecall-11 is NOT compliant with RFC3261.

Kind regards

Ivo

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Aug 2016 08:00:36 +0000

Hi,

>We are following RFC 6086.

Yes, but it seems you only want to do it for ³cosmetic purpose², because
you still want to use 7852 for INFO.

Again, as per RFC 6086, the semantics of the MIMEs shall be described by
by the info package specification. Whether the info package is used for
some ³special purpose² and/or ³between a small set of devices" is
irrelevant.

Regards,

Christer

>>>>-----------------------------------------------------------------------
>>>>--
>>>>-----
>>>>      top level of the SIP message.  This Call-Info header field
>>>>contains
>>>>a
>>>>-----------------------------------------------------------------------
>>>>--
>>>>-----
>>>>   and
>>>>
>>>>
>>>>-----------------------------------------------------------------------
>>>>--
>>>>-----
>>>>   SIP/2.0 200 OK
>>>>         To:
>>>>
>>>><<sip:[email-masked]>sip:[email-masked]>;tag=9fxced
>>>>76
>>>>sl
>>>>xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>http://www.w3.org
>>>>/2
>>>>001/XMLSchema-instance"
>>>>             xsi:schemaLocation=
>>>>               
>>>>ref="<mailto:[email-masked]>[email-masked].
>>>>co
>>>>m"/>
>>>>
>>>>-----------------------------------------------------------------------
>>>>--
>>>>-----
>>>>
>>>>   Kind regards
>>>>
>>>>   Ivo
>>>>
>>>>    > For Call-Info with purpose=emergencyCallData.eCall.MSD included
>>>>in
>>>>the
>>>>    > initial INVITE request:
>>>>    >
>>>>    > seems to be redundant to the eCall URN included in the
>>>>Request-URI
>>>>and
>>>>    > For Call-Info with purpose=emergencyCallData.eCall.control
>>>>included
>>>>in
>>>>    > For Call-Info with purpose=emergencyCallData.eCall.control
>>>>included
>>>>in
>>>>    > the INFO request
>>>>    >
>>>>    > implies that either
>>>>application/EmergencyCallData.eCall.control+xml
>>>>    > MIME body or application/emergencyCallData.eCall.MSD+per MIME
>>>>body
>>>>is
>>>><https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailm
>>>>an
>>>>/listinfo/ecrit
>>>>    >
>>>>
>>>><https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailm
>>>>an
>>>>/listinfo/ecrit
>>>>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Thu, 11 Aug 2016 12:39:40 +0000

Can you clarify whether this is a comment that RFC 7852 is not compliant with RFC 3261 or that draft-ietf-ecrit-ecall is not compliant with RFC 3261?

Keith

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: 11 August 2016 08:59
To: Randall Gellens; Paul Kyzivat; [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hello,

Kind regards

Ivo

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Thu, 11 Aug 2016 12:43:05 +0000

I fundamentally cannot agree to this statement.

I thought we had agreed that the INFO package would be used, and this statement is absolutely denying that.

Chairs, please intervene with your understanding of the current consensus.

Keith

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: 10 August 2016 22:39
To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; [email-masked]
Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

In reality, there is no separate INFO package negotiation.  The endpoints support the data types not because they support the iNFO package, but rather they support the INFO package and the data types and Call-Info because they comply with the draft.

At 5:29 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote:

> 7852. The data element is included because the use of an appropriate 
> Info package has been negotiated and used. That Info package 
> definition and the INFO mechanism itself makes no mention of use of 
> Call-Info in association with it.
>
>  Further I see no justification for complicating any error handling by 
> suddenly defining it to be applicable, as it is not necessary.
>> defined in draft-ietf-ecrit-ecall, and I would need to understand 
>> that  usage before it is included.
>>
> This is
> customers out of a mire of technological chaos neatly ignores the fact 
> that it was he who, by peddling second-rate technology,

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- Einstein never accepted quantum mechanics because of this element of chance and uncertainty. He said, "God does not play dice."
It seems that Einstein was doubly wrong. The quantum effects of black holes suggests that not only does God play dice, He sometimes throws them where they cannot be seen.  --Steven Hawking

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Thu, 11 Aug 2016 13:08:24 +0000

I think I need to state how I see ecrit operating.

I see some sort of supporting ecrit "application" in the PSAP and the calling UA. That supporting application initiates two independent data transport mechanisms within SIP, using RFC 7852 for the initial MSD and the data response to indicate support of MSD reception, and using RFC 6086 for any subsequent MSD. SIP itself knows nothing about the relationship between these two mechanisms, only the ecrit "application". It is the ecrit "application" that performs the combination of the data received using the two data transfer mechanisms as appropriate.

The MSDs transferred using the two mechanisms following identical syntax and coding, but that is merely a matter of convenient definition.

As such, use of Call-Info in INFO would be entirely inappropriate, because INFO does not transfer additional-data according to RFC 7852.

Note that RFC 7842 is only used by ecrit in the initial INVITE transaction, and appearance in subsequent messages of any form would not be expected by the recipient PSAP.

I believe the above is the correct usage of these mechanisms, as opposed to that put forward by the current draft author.

Regards

Keith

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: 11 August 2016 09:01
To: Randall Gellens; Drage, Keith (Nokia - GB); [email-masked]; Ivo Sedlacek; [email-masked]; [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hi,

>We are following RFC 6086.

Yes, but it seems you only want to do it for ³cosmetic purpose², because you still want to use 7852 for INFO.

Again, as per RFC 6086, the semantics of the MIMEs shall be described by by the info package specification. Whether the info package is used for some ³special purpose² and/or ³between a small set of devices" is irrelevant.

Regards,

Christer

>>>>   We have to think also on backwards compatibility issues.  Thus 
>>>> when  moving PSAP's to SIP imply also that there must exist an  
>>>>   According to draft-ietf-ecrit-ecall-11, the Call-Info header 
>>>> field  is used to form a "content-table" of pointers to bodies 
>>>> INVITE  request (and of INVITE response, of INFO request) in 
>>>> headers of  INVITE request (and of INVITE response, of INFO request).
>>   >>
>>>>   If the Call-Info header field points to a body which describes 
>>>> the  callers or callee, then Call-Info semantic fits (even though I  
>>>>contains a
>>>>   If all the handling of the call is coded in a special purpose 
>>>> way,  solely for the emergency call path, then alternatives may be 
>>>> of no  concern. But ideally the call will largely be handled via 
>>>> standard  library code that is also used for other call paths and 
>>>> other  message processing. So processing body parts in a "standard" 
>>>> way,  rather than special casing, is desirable.
>>>>
>>>>                   Thanks,
>>>>                   Paul
>>>>
>>>>Request-URI and
>>>>body is
>>>-------------- Randomly selected tag: --------------- I asked 
>>>President Reagan what he thought about the IBM PC Jr., and he replied 
>>>that he didn't believe in abortions
>>>                                              --Steve Wozniac
>>>
>Probable-Possible, my black hen, She lays eggs in the Relative When.
>She doesn't lay eggs in the Positive Now Because she's unable to 
>postulate how.

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 11 Aug 2016 13:51:09 +0000

I identified the problem when reading draft-ietf-ecrit-ecall-11. I have not followed RFC 7852 closely.

If the body referenced in Call-Info in RFC 7852 contains additional information about callee or caller, then Call-Info usage in RFC 7852 is perfectly OK.
If the body referenced in Call-Info in RFC 7852 contains something unrelated to callee or caller, then Call-Info usage in RFC 7852 would suffer the same problem as the two problematic use cases in  draft-ietf-ecrit-ecall-11.

Kind regards

Ivo

-----Original Message-----
From: Drage, Keith (Nokia - GB) [mailto:[email-masked]] 
Sent: Thursday, August 11, 2016 2:40 PM
To: Ivo Sedlacek; Randall Gellens; Paul Kyzivat; [email-masked]
Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Keith

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: 11 August 2016 08:59
To: Randall Gellens; Paul Kyzivat; [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hello,

Kind regards

Ivo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Aug 2016 10:23:37 -0400

On 8/10/16 5:38 PM, Randall Gellens wrote:
> package, but rather they support the INFO package and the data types and
> Call-Info because they comply with the draft.

You can't do that without violating something.

For one thing, when using INFO packages the body part that is the info 
package must have a content-disposition of "Info-Package". But for the 
ecall usage the body part must have a content-disposition of "by-reference".

	Thanks,
	Paul

>> suddenly defining it to be applicable, as it is not necessary. INFO
>> requests always contain a data element appropriate to the Info package
>> that is defined for its use - it absolutely does not need a secondary
>> reference to the package.
>>
>>  Keith
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Aug 2016 10:31:33 -0400

On 8/10/16 5:45 PM, Randall Gellens wrote:
> harmful to do so, but to avoid argument about legalistic interpretations
> of INFO.  In our case, INFO is being used exactly as any other SIP
> message, not in any special/unique way.

It seems that you agreed without understanding the point of the objection.

I agree that 7852 isn't excluded from use of INFO. But if it was to be 
used with INFO then it would be piggybacking on the info usage, not 
subsumed into it. You would have the INFO, identifying some info 
package, with the body part defined for use with that info package and 
content-disposition "Info-Package", and on top of that you would have 
the call-info with a cid: uri referencing a *different* body part that 
has content-disposition of (whatever it is, I forget).

We discussed that alternative, and people found it to be a hack. So 
instead we decided to *really* use an info package.

	Thanks,
	Paul

> I realize that to some, INFO is
> the unaccompanied minor of SIP messages: it must be constantly
> chaperoned and protected against wanton misuse as a generic transport
> mechanism where random data types are sent to unsuspecting endpoints
> that don't know how to process them.  That's an entirely different
> situation than we have.  We have endpoints in a limited domain that
> exchange a very small number of data types.
>
>>  Again, as we have discussed before, RFC 7852 does not apply to INFO.
>> And, we did agree to not carry the bodies in INFO responses.
>>
>>  I DID raise these issues before 7852 was published, but was told it's
>> too late to change at that point. So, maybe we need to correct 7852 if
>> that is unclear.
>>
>>  Regards,
>>
>>  Christer
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Aug 2016 10:36:07 -0400

+1

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Aug 2016 10:44:15 -0400

> In short: draft-ietf-ecrit-ecall-11 is NOT compliant with RFC3261.

Part of your concern will be resolved by ceasing the use of call-info 
with the INFO messages.

Regarding use in INVITE response:

I think you are technically correct, though some will consider it 
nit-picking.

To avoid that, simply stop sending ecall data in the INVITE response. 
Instead, simply wait and send it in an INFO.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Thu, 11 Aug 2016 10:47:31 -0700

At 8:00 AM +0000 8/11/16, Christer Holmberg wrote:

>  Yes, but it seems you only want to do it for "cosmetic purpose", because

I'd say we're complying for legalistic purposes, but yes.

>  by the info package specification.

And they are.  They are also described per RFC 7852.  We're using 
both.  RFC 7852 for consistency with non-INFO.

>  Whether the info package is used for
>  some "special purpose" and/or "between a small set of devices" is
>  irrelevant.

Fair enough.

-------------- Randomly selected tag: ---------------
A logician saves the life of a space alien and is rewarded with
an offer to answer any question.  After a thought he asks: What
is the best question to ask and the correct answer to it?  After
a brief panic the alien consults her computer and says: The best
question to ask is the one you just did and the correct answer
to it is the one I gave.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 11 Aug 2016 10:50:38 -0700

Hi Keith,

Yes, we agreed that the draft would define and use an INFO package 
registration, and it does so.  My point is that the endpoints aren't 
relying on INFO package negotiation, they are compliant with the 
spec.  It's a subtle difference, and not one observable "on the 
wire."  There is an INFO package registration, and the draft requires 
compliance with INFO RFC.  So, all is good.

--Randy

At 12:43 PM +0000 8/11/16, Keith (Nokia - GB) Drage wrote:

>  I thought we had agreed that the INFO package would be used, and 
> this statement is absolutely denying that.
>
>  Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not 
> package, but rather they support the INFO package and the data 
> types and Call-Info because they comply with the draft.
>
>  -------------- Randomly selected tag: --------------- Einstein 
> never accepted quantum mechanics because of this element of chance 
> and uncertainty. He said, "God does not play dice."
>  It seems that Einstein was doubly wrong. The quantum effects of 
> black holes suggests that not only does God play dice, He sometimes 
> throws them where they cannot be seen.  --Steven Hawking

-------------- Randomly selected tag: ---------------
It is very dangerous to be right when the established authorities
are wrong.                           --Voltaire

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Fri, 12 Aug 2016 00:47:41 +0000

To be honest, I believe you are making what you desire fit the INFO mechanism where it touchs, thus you have a concept of making something look like Info, but which is not actually specified according to RFC 6086.

Ecrit does not need to provide procedures that are already in RFC 6086, so all it needs to say is that the xxx info package is mandatory for support on all ecrit calls in accordance with RFC 6086, and that covers the package negotiation.

Further I do not believe you need to add to the Info usage with add ons that only seem to be there because they were in the previous version of your document, and are irrelevant for correct operation, such as the usage of a Call-Info header field. They lead to future deployment and interoperability problems which noone needs on an emergency call.

Regards

Keith

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: 11 August 2016 18:51
To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; [email-masked]
Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hi Keith,

Yes, we agreed that the draft would define and use an INFO package registration, and it does so.  My point is that the endpoints aren't relying on INFO package negotiation, they are compliant with the spec.  It's a subtle difference, and not one observable "on the wire."  There is an INFO package registration, and the draft requires compliance with INFO RFC.  So, all is good.

--Randy

At 12:43 PM +0000 8/11/16, Keith (Nokia - GB) Drage wrote:

>>>    Unless someone is defining a new usage for Call-Info beyond 
>>> RFC7852  then I have to agree with Ivo. That additional usage is not 
>>>    Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage 
>>> not  aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- 
>>> Call-Info  usage brings no value)
>>>
>>>    Hello,
>>>
>  -------------- Randomly selected tag: --------------- Einstein never 
> accepted quantum mechanics because of this element of chance and 
> uncertainty. He said, "God does not play dice."
>  It seems that Einstein was doubly wrong. The quantum effects of black 
> holes suggests that not only does God play dice, He sometimes throws 
> them where they cannot be seen.  --Steven Hawking

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- It is very dangerous to be right when the established authorities
are wrong.                           --Voltaire

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Fri, 12 Aug 2016 11:08:24 +0000

RFC 7852 defines a general mechanism for adding a message body referenced by Call-Info, and provides no constraint on what those message bodies are. It creates a registry " Emergency Call Data Types" for listing these.

It then goes on to define several specific additional data types of which the ones currently identified are as follows:

      +----------------+--------------+------------+
      | Token          |  Data About  | Reference  |
      +----------------+--------------+------------+
      | ProviderInfo   |   The Call   |  RFC 7852  |
      | ServiceInfo    |   The Call   |  RFC 7852  |
      | DeviceInfo     |   The Call   |  RFC 7852  |
      | SubscriberInfo |   The Call   |  RFC 7852  |
      | Comment        |   The Call   |  RFC 7852  |
      +----------------+--------------+------------+

Obviously these will need to be reviewed and judgement applied as to whether they relate to the sender of the Call-Info header field.

Regards

Keith

-----Original Message-----
From: Ivo Sedlacek [mailto:[email-masked]] 
Sent: 11 August 2016 14:51
To: Drage, Keith (Nokia - GB); Randall Gellens; Paul Kyzivat; [email-masked]
Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Kind regards

Ivo

-----Original Message-----
From: Drage, Keith (Nokia - GB) [mailto:[email-masked]] 
Sent: Thursday, August 11, 2016 2:40 PM
To: Ivo Sedlacek; Randall Gellens; Paul Kyzivat; [email-masked]
Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Keith

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: 11 August 2016 08:59
To: Randall Gellens; Paul Kyzivat; [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hello,

Kind regards

Ivo

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Aug 2016 09:48:32 -0400

> It then goes on to define several specific additional data types of which the ones currently identified are as follows:

I don't think we need to get too carried away here.

Clearly at least *some* of this stuff is related to the sender. IMO that 
justifies using call-info. And note that call-info is explicitly 
permitted to provide info about the callee when used in responses.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Fri, 12 Aug 2016 13:12:53 -0700

Hi Keith,

The main aspect is sending data in INVITE and the response.  Using 
INFO is a secondary mechanism that is only used in a subset of calls. 
So, we have use the RFC 7852 mechanism.  When we use INFO, use still 
use RFC 7852, with additional aspects to comply with rules for using 
INFO.

--Randy

At 12:47 AM +0000 8/12/16, Keith (Nokia - GB) Drage wrote:

>  To be honest, I believe you are making what you desire fit the INFO 
> mechanism where it touchs, thus you have a concept of making 
> something look like Info, but which is not actually specified 
> according to RFC 6086.
>
>  Ecrit does not need to provide procedures that are already in RFC 
> 6086, so all it needs to say is that the xxx info package is 
> mandatory for support on all ecrit calls in accordance with RFC 
> 6086, and that covers the package negotiation.
>
>  Further I do not believe you need to add to the Info usage with add 
> ons that only seem to be there because they were in the previous 
> version of your document, and are irrelevant for correct operation, 
> such as the usage of a Call-Info header field. They lead to future 
> deployment and interoperability problems which noone needs on an 
> emergency call.
>
>  Regards
>
>  Keith
>
> registration, and it does so.  My point is that the endpoints 
> aren't relying on INFO package negotiation, they are compliant with 
> the spec.  It's a subtle difference, and not one observable "on the 
> wire."  There is an INFO package registration, and the draft 
> requires compliance with INFO RFC.  So, all is good.
>
>  --Randy
>
>  -------------- Randomly selected tag: --------------- It is very 
> dangerous to be right when the established authorities
>  are wrong.                           --Voltaire

-------------- Randomly selected tag: ---------------
Misery loves company, but company does not reciprocate.

---

From: Ivo Sedlacek <[email-masked]>
Date: Mon, 15 Aug 2016 05:59:50 +0000

Several people expressed a view that solely info package definition is required and Call-Info is not needed in INFO. 

This is my view as well.

Kind regards

Ivo Sedlacek

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Friday, August 12, 2016 10:13 PM
To: Drage, Keith (Nokia - GB); Ivo Sedlacek; Paul Kyzivat; [email-masked]
Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hi Keith,

The main aspect is sending data in INVITE and the response.  Using INFO is a secondary mechanism that is only used in a subset of calls. 
So, we have use the RFC 7852 mechanism.  When we use INFO, use still use RFC 7852, with additional aspects to comply with rules for using INFO.

--Randy

At 12:47 AM +0000 8/12/16, Keith (Nokia - GB) Drage wrote:

> mechanism where it touchs, thus you have a concept of making something 
> look like Info, but which is not actually specified according to RFC 
> 6086.
>
> 6086, so all it needs to say is that the xxx info package is mandatory 
> for support on all ecrit calls in accordance with RFC 6086, and that 
> covers the package negotiation.
>
> relying on INFO package negotiation, they are compliant with the spec.  
> It's a subtle difference, and not one observable "on the wire."  There 
> is an INFO package registration, and the draft requires compliance 
> with INFO RFC.  So, all is good.
>
>  --Randy
>
>>>    The inclusion of the data element in INFO is nothing to do with 
>>> RFC  7852. The data element is included because the use of an 
>>>    Further I see no justification for complicating any error 
>>> handling  by  suddenly defining it to be applicable, as it is not necessary.
>>>   INFO requests always contain a data element appropriate to the 
>>> Info  package that is defined for its use - it absolutely does not 
>>> need a  secondary reference to the package.
>>>
>>>    Keith
>>>
>>>>  RFC7852  then I have to agree with Ivo. That additional usage is 
>>>> not  currently  defined in draft-ietf-ecrit-ecall, and I would need 
>>>> to  understand  that  usage before it is included.
>>>>
>>>>     Negotiation and transfer of MSD in association with INFO 
>>>> requests  is  an entirely separate transfer mechanism, not covered 
>>>> by  draft-ietf-ecrit-data-only-ea and therefore it should never 
>>>> appear  there as though it had been. Inclusion will lead to 
>>>> complete  confusion  as to whether the requirements of the INFO 
>>>> mechanism or  the  requirements of draft-ietf-ecrit-data-only-ea 
>>>> apply, when it  should be  absolutely clear that only the former apply.
>>>>
>>>>     Regards
>>>>
>>>>     Keith
>>>>
>>>>    draft-ietf-ecrit-ecall-11 - in the response to the INVITE 
>>>> request,  the  Call-Info points to the  
>>>    -------------- Randomly selected tag: --------------- The idea 
>>> that  Bill Gates has appeared like a knight in shining armor to lead 
>>> all  customers out of a mire of technological chaos neatly ignores 
>>> the  fact  that it was he who, by peddling second-rate technology,
>> never

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- Misery loves company, but company does not reciprocate.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 15 Aug 2016 06:24:26 +0000

Hi,

I don¹t know what is meant by ³secondary mechanism². When you use INFO,
there is one, only one, and nothing but one mechanism - info package.

Whether INFO as such is only used in a subset of calls doesn¹t really
matter. WHEN it¹s used, it has to be used as specified.

Regards,

Christer

On 12/08/16 23:12, "Ecrit on behalf of Randall Gellens"
<[email-masked] on behalf of [email-masked]> wrote:

>>>>RFC 
>>>>not 
>>>>>requests 
>>>>that

---

From: Randall Gellens <[email-masked]>
Date: Mon, 15 Aug 2016 02:16:40 -0700

Hi Christer,

I don't think anyone is suggesting that INFO be used without 
conforming to its specification.

--Randy

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

>  Hi,
>
>  I don't know what is meant by "secondary mechanism". When you use INFO,
>  Whether INFO as such is only used in a subset of calls doesn't really
>  matter. WHEN it's used, it has to be used as specified.
>
>  Regards,
>
>  Christer
>
>

-------------- Randomly selected tag: ---------------
Gossip is when you hear something you like about someone you don't.
    --Earl Wilson

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 15 Aug 2016 09:33:12 +0000

Hi,

No, but you also want to somehow mix it with other mechanisms (well, parts of other mechanisms, actually).

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Randall Gellens<mailto:[email-masked]>
Sent: ‎15/‎08/‎2016 12:16
To: Christer Holmberg<mailto:[email-masked]>; Drage, Keith (Nokia - GB)<mailto:[email-masked]>; Ivo Sedlacek<mailto:[email-masked]>; Paul  Kyzivat<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned  with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no  value)

Hi Christer,

--Randy

---

From: Randall Gellens <[email-masked]>
Date: Mon, 15 Aug 2016 03:31:23 -0700

Hi Christer,

Yes, we want the mechanism to be consistent.

--Randy

At 9:33 AM +0000 8/15/16, Christer Holmberg wrote:

>  Hi,
>
>  No, but you also want to somehow mix it with other mechanisms 
> (well, parts of other mechanisms, actually).
>
>  Regards,
>
>  Christer
>
>  From: <mailto:[email-masked]>Randall Gellens
>  Sent: 15/08/2016 12:16
>  To: <mailto:[email-masked]>Christer Holmberg; 
> <mailto:[email-masked]>Drage, Keith (Nokia - GB); 
> <mailto:[email-masked]> Ivo Sedlacek; 
> <mailto:[email-masked]>Paul  Kyzivat; 
> <mailto:[email-masked]> [email-masked]
>>>>    From: Randall Gellens 
>>>> [<mailto:[email-masked]>mailto:[email-masked]]
>>>>>     From: Randall Gellens 
>>>>> [<mailto:[email-masked]>mailto:[email-masked]]
>>>>     >>   From: Randall Gellens 
>>>> [<mailto:[email-masked]>mailto:[email-masked]]
>>>>>>> [<mailto:[email-masked]>mailto:[email-masked]] 
>>>>>>> On Behalf Of Ivo
>>>>>>>    Sedlacek

-------------- Randomly selected tag: ---------------
I have learned
To spell hors d'oeuvres
Which still grates on
Some people's n'oeuvres.
        -- Warren Knox

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 15 Aug 2016 10:39:38 +0000

Hi,

The mechanisms are not consistent, and just adding a Call-Info header is
not going to make them consistent.

Regards,

Christer

On 15/08/16 13:31, "Randall Gellens" <[email-masked]> wrote:

>>>>>>     I thought we had agreed that the INFO package would be used,
>>>>>>and this
>>>>>>    statement is absolutely denying that.
>>>>>>
>>>>>>types
>>>>>>>appropriate
>>>>>>>handling
>>>>>>>Info
>>>>>>>>       Alt3: the Content-Disposition header field can be omitted
>>>>>>>>and
>>>>>>>>thus
>>>>>>>      Opinions are personal;    facts are suspect;    I speak for
>>>>>>>myself
>>>>>>>only
>>>>>>>      led them into it in the first place.
>>>>>>>--Douglas
>>>>>>>Adams
>>>>>>
>>>>>>
>>>>>>     --
>>>>>>     Randall Gellens
>>>>>>     Opinions are personal;    facts are suspect;    I speak for
>>>>>>myself
>>>>>>only
>>>>>>black
>>>>an/listinfo/ecrit

---

From: Randall Gellens <[email-masked]>
Date: Mon, 15 Aug 2016 12:23:02 -0700

Hi Paul,

The draft says that when data is sent in INFO, the body part's 
Content-Disposition is set to "Info-Package" (to be compliant with 
the INFO spec).  Content-Disposition was created a long time ago to 
bring some order to the wild and wooly world of body parts. 
Content-Disposition allows an implementation that receives a random 
body part to have some idea of what to do with it even if it doesn't 
understand it.  In our case, we're dealing with a limited usage where 
the end points are conformant to the spec and understand the eCall 
MSD (or VEDS for car-crash) or metadata/control body part.  They 
don't need the Content-Disposition value for guidance.  So, I don't 
see any conflict with using "Info-Package" when the data arrives via 
INFO and "by-reference" in other cases.  Call-Info identifies the 
data type, and this is the same regardless of how the data arrives.

--Randy

At 10:23 AM -0400 8/11/16, Paul Kyzivat wrote:

>  For one thing, when using INFO packages the body part that is the 
> info package must have a content-disposition of "Info-Package". But 
> for the ecall usage the body part must have a content-disposition 
> of "by-reference".
>
>  	Thanks,
>  	Paul
>

-------------- Randomly selected tag: ---------------
Who tells the stories of a culture really governs human behavior.  It
used to be the parent, the school, the church, the community.  Now it's
a handful of global conglomerates that have nothing to tell, but a
great deal to sell.
    --George Gerbner, dean of Annenberg School of Communication

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Aug 2016 15:56:53 -0400

On 8/15/16 3:23 PM, Randall Gellens wrote:
> Content-Disposition is set to "Info-Package" (to be compliant with the
> INFO spec).

The examples show that. But I don't find any text saying to do that.

And if there was, it would seem to be in conflict with RFC7852:

    ... The 'by-reference' disposition type of RFC 5621 [RFC5621]
    allows a SIP message to contain a reference to the body part, and the
    SIP User Agent (UA) processes the body part according to the
    reference.  This is the case for a Call-Info header field containing
    a CID URL.

It isn't entirely clear if this was intended to be normative or not.

> Content-Disposition was created a long time ago to bring
> some order to the wild and wooly world of body parts.

I know. I was actively involved.

> Content-Disposition allows an implementation that receives a random body
> part to have some idea of what to do with it even if it doesn't
> the end points are conformant to the spec and understand the eCall MSD
> (or VEDS for car-crash) or metadata/control body part.  They don't need
> the Content-Disposition value for guidance.  So, I don't see any
> conflict with using "Info-Package" when the data arrives via INFO and
> "by-reference" in other cases.  Call-Info identifies the data type, and
> this is the same regardless of how the data arrives.

When you say this you constrain how implementation can be done. It 
should be possible to build a sip stack that has generic logic for 
processing bodies and body parts. For each body part it then needs to 
figure out what it is that governs what determines how each part is to 
be processed. This is complicated, especially since both Content-Type 
and Content-Disposition are themselves optional, and the defaults when 
they aren't present are context sensitive.

You have introduced an ambiguity about whether the processing of this 
body part is governed by a "handler" for the info-package, or by a 
handler for the call-info header. Perhaps this won't be a problem - 
maybe they will both handle it. But it is ill-defined.

The alternative is that there is no general framework for this - that 
special code, driven by the specific R-URI, handles all the body 
handling. If you do this the result is likely to be very fragile. E.g., 
it might break if there happens to be another body part present for some 
orthogonal feature of the request. (Perhaps there is another call-info 
with a different purpose, with another cid: referencing another body 
part. This could arise based on STIR.)

	Thanks,
	Paul

>> for the ecall usage the body part must have a content-disposition of
>> "by-reference".
>>
>>      Thanks,
>>      Paul
>>
>>>>> currently
>>>>> INVITE
>>>>> requests is
>>>>> confusion

---

From: Randall Gellens <[email-masked]>
Date: Mon, 15 Aug 2016 14:05:44 -0700

Hi Paul,

Thanks for clarifying your point/concern.  I now understand the issue 
better, and am discussing possible solutions with Brian.  We'll send 
an update to the list.  By the way, the text does explicitly say in 
Section 6:

    When data is being carried in an INFO request message, the body part
    also carries a Content-Disposition header field set to "Info-
    Package".

--Randy

At 3:56 PM -0400 8/15/16, Paul Kyzivat wrote:

> processing bodies and body parts. For each body part it then needs 
> to figure out what it is that governs what determines how each part 
> is to be processed. This is complicated, especially since both 
> Content-Type and Content-Disposition are themselves optional, and 
> the defaults when they aren't present are context sensitive.
>
>  You have introduced an ambiguity about whether the processing of 
> this body part is governed by a "handler" for the info-package, or 
> by a handler for the call-info header. Perhaps this won't be a 
> problem - maybe they will both handle it. But it is ill-defined.
>
>  The alternative is that there is no general framework for this - 
> that special code, driven by the specific R-URI, handles all the 
> body handling. If you do this the result is likely to be very 
> fragile. E.g., it might break if there happens to be another body 
> part present for some orthogonal feature of the request. (Perhaps 
> there is another call-info with a different purpose, with another 
> cid: referencing another body part. This could arise based on STIR.)
>
>  	Thanks,
>  	Paul
>
>>  --Randy
>>

-------------- Randomly selected tag: ---------------
Every successful person has had failures but repeated failure is no
guarantee of eventual success.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Aug 2016 17:12:51 -0400

On 8/15/16 5:05 PM, Randall Gellens wrote:
> better, and am discussing possible solutions with Brian.  We'll send an
> update to the list.  By the way, the text does explicitly say in Section 6:
>

Ah. Then my search for "Info-Package" didn't find this because it was 
split across lines. :-(

	Sorry,
	Paul

>> handling. If you do this the result is likely to be very fragile.
>> E.g., it might break if there happens to be another body part present
>> for some orthogonal feature of the request. (Perhaps there is another
>> call-info with a different purpose, with another cid: referencing
>> another body part. This could arise based on STIR.)
>>
>>      Thanks,
>>      Paul
>>
>>>  --Randy
>>>
>>>>>> handling by
>>>>>>> RFC7852

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 16 Aug 2016 06:12:10 +0000

Hello,

> Content-Disposition allows an implementation that receives a random body part to have some idea of what to do with it even if it doesn't understand it.  

As the UE understands the eCall info package, the UE knows the semantic of the bodies associated (by Content-Disposition: info-package) with the eCall info package. 

So, there is no need to have a Call-Info in INFO request.

Please remove Call-Info from the INFO request.

Kind regards

Ivo Sedlacek

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Monday, August 15, 2016 9:23 PM
To: Paul Kyzivat; Drage, Keith (Nokia - GB); Ivo Sedlacek; [email-masked]; Brian Rosen
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hi Paul,

The draft says that when data is sent in INFO, the body part's Content-Disposition is set to "Info-Package" (to be compliant with the INFO spec).  Content-Disposition was created a long time ago to bring some order to the wild and wooly world of body parts. 
Content-Disposition allows an implementation that receives a random body part to have some idea of what to do with it even if it doesn't understand it.  In our case, we're dealing with a limited usage where the end points are conformant to the spec and understand the eCall MSD (or VEDS for car-crash) or metadata/control body part.  They don't need the Content-Disposition value for guidance.  So, I don't see any conflict with using "Info-Package" when the data arrives via INFO and "by-reference" in other cases.  Call-Info identifies the data type, and this is the same regardless of how the data arrives.

--Randy

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- Who tells the stories of a culture really governs human behavior.  It used to be the parent, the school, the church, the community.  Now it's a handful of global conglomerates that have nothing to tell, but a great deal to sell.
    --George Gerbner, dean of Annenberg School of Communication

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 Aug 2016 13:58:13 +0000

Hi,

>understand it.  

Exactly - and in INFO you use Content-Disposition ³info-package², which
means that the info package description define what to do it. And, you
will not receive it unless you understand it.

C-D ³info-package² does NOT refer to a Call-Info header field - and
including a Call-Info header field in INFO would not change that.

Regards,

Christer

>INFO spec).  Content-Disposition was created a long time ago to bring
>understand it.  In our case, we're dealing with a limited usage where the
>end points are conformant to the spec and understand the eCall MSD (or
>VEDS for car-crash) or metadata/control body part.  They don't need the
>Content-Disposition value for guidance.  So, I don't see any conflict
>with using "Info-Package" when the data arrives via INFO and
>-------------- Randomly selected tag: --------------- Who tells the
>stories of a culture really governs human behavior.  It used to be the
>parent, the school, the church, the community.  Now it's a handful of
>global conglomerates that have nothing to tell, but a great deal to sell.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 17 Aug 2016 13:56:54 -0700

Hi Everyone,

The authors wish to propose a solution to the concerns that have been 
raised.  We recognize that the vehicle data (MSD for eCall and VEDS 
for car-crash) is properly considered additional data in the context 
of RFC 7852, while the metadata/control block can be considered its 
own request/response protocol.  With that in mind, our proposal is to 
have the INFO package associated with the metadata/control block but 
not the MSD nor VEDS.  For a mid-call update request, the PSAP sends 
a metadata/control block requesting an updated MSD (or VEDS) in INFO. 
The IVS in turn sends an INFO with a metadata/control block 
acknowledging the request with a successful result.  Both INFO 
messages contain a metadata/control block associated with the INFO 
package and not referenced by a Call-Info header field.  The INFO 
sent by the IVS also contains an updated MSD (or VEDS) as RFC 7852 
additional data, referenced by a Call-Info header field.  There would 
be two body parts in the INFO from the IVS to the PSAP, each with its 
appropriate MIME type and Content-Disposition.  One body part is 
associated with the INFO package and is the response to the request. 
The second body part is the updated MSD and is referenced by 
Call-Info.  This more cleanly separates the request/response protocol 
from the vehicle data.  The request/response protocol uses INFO, is 
associated with an INFO package, and carries data with the 
Info-Package Content-Disposition.  INFO messages sent by the IVS may 
also contain vehicle data not associated with the INFO package.  In 
eCall, this allows the PSAP to request a mid-call update and the IVS 
to respond. In car-crash, this allows the PSAP to request the vehicle 
to take other actions (such as flashing the lights).  In all cases, 
the vehicle responds to a request with an acknowledgment (and 
indicates if the request was successfully carried out).

Note that RFC 6086 permits INFO messages to also carry data not 
associated with INFO packages.

This has an additional advantage of making it cleaner and easier to 
reuse the emergency call request/response protocol later, in other 
documents (e.g., so the PSAP can request building sensor data).

-------------- Randomly selected tag: ---------------
It is easier to fight for one's principles than to live up to them.
                                                     --Alfred Adler

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 Aug 2016 22:20:53 +0000

Hi,

I thought we discussed usage of legacy (non-Info-Package) INFOs already. RFC 6086 allows it for backward compatibility. Any new usage MUST use an Info Package.

And, even if it was allowed, using two different INFO mechanisms would make things even more complicated.

I'll let others decide on whether MSD is considered additional data or not, but I don't think it's relevant because additional data is not a legacy INFO usage, nor does additional data update RFC 6086.

Regards,

Christer

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: 17 August 2016 23:57
To: Christer Holmberg <[email-masked]>; Paul Kyzivat <[email-masked]>; Drage, Keith (Nokia - GB) <[email-masked]>; [email-masked]; Brian Rosen <[email-masked]>
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hi Everyone,

The authors wish to propose a solution to the concerns that have been raised.  We recognize that the vehicle data (MSD for eCall and VEDS for car-crash) is properly considered additional data in the context of RFC 7852, while the metadata/control block can be considered its own request/response protocol.  With that in mind, our proposal is to have the INFO package associated with the metadata/control block but not the MSD nor VEDS.  For a mid-call update request, the PSAP sends a metadata/control block requesting an updated MSD (or VEDS) in INFO. 
The IVS in turn sends an INFO with a metadata/control block acknowledging the request with a successful result.  Both INFO messages contain a metadata/control block associated with the INFO package and not referenced by a Call-Info header field.  The INFO sent by the IVS also contains an updated MSD (or VEDS) as RFC 7852 additional data, referenced by a Call-Info header field.  There would be two body parts in the INFO from the IVS to the PSAP, each with its appropriate MIME type and Content-Disposition.  One body part is associated with the INFO package and is the response to the request. 
The second body part is the updated MSD and is referenced by Call-Info.  This more cleanly separates the request/response protocol from the vehicle data.  The request/response protocol uses INFO, is associated with an INFO package, and carries data with the Info-Package Content-Disposition.  INFO messages sent by the IVS may also contain vehicle data not associated with the INFO package.  In eCall, this allows the PSAP to request a mid-call update and the IVS to respond. In car-crash, this allows the PSAP to request the vehicle to take other actions (such as flashing the lights).  In all cases, the vehicle responds to a request with an acknowledgment (and indicates if the request was successfully carried out).

Note that RFC 6086 permits INFO messages to also carry data not associated with INFO packages.

This has an additional advantage of making it cleaner and easier to reuse the emergency call request/response protocol later, in other documents (e.g., so the PSAP can request building sensor data).

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- It is easier to fight for one's principles than to live up to them.
                                                     --Alfred Adler

---

From: Brian Rosen <[email-masked]>
Date: Wed, 17 Aug 2016 18:43:52 -0400

You are missing the point of the suggested compromise.

This is NOT a legacy INFO.  It’s a new-style INFO package, conforming to 6086.

There is only ONE INFO part.  It only carries the metadata/control block, and its ACK.

You send an INFO, with the metadata/control body part, with the proper INFO mime type and content disposition.  The MSD/VEDS is not there.
You send the MSD/VEDS as Additional Data, in a separate body part, with the additional data MIME type and content disposition using Call-Info.

So there are two parts in the body.  One is the INFO block, the other is the Additional Data block, with the Call-Info header pointing to it.  The latter isn’t legacy use of INFO, it’s permitted use of Call-Info.  6069 expressly permits this.

MSD is most definitely Additional Data, as it is how it is sent in the initial INVITE.  Same data, same MIME, same Disposition.  The point we are making is that the INFO is the command/control mechanism.  The Call-Info carries the VEDS/MSD, whether it’s on an INVITE or an INFO.  The INFO package has the command and it’s response (the ACK).

Brian

> On Aug 17, 2016, at 6:20 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Aug 2016 20:59:21 -0400

> MSD is most definitely Additional Data, as it is how it is sent in the initial INVITE.  Same data, same MIME, same Disposition.  The point we are making is that the INFO is the command/control mech…

Yes, that I how I understood the proposal.

And IMO it is a valid thing to do. (I'm pretty sure I did mention an 
approach like this along the way, but it got lost along the way.)

This seems plausible to me.

I would then suggest that the while there can then be an INFO with a 
body that requests the sending of Additional Data, there shouldn't be a 
*requirement* that the Additional Data come in the same INFO that 
carries the ACK to that request. It might *typically* come there, 
because it is a convenient message that happens to be going out at the 
right time. But it *might* happen to go in some other message - a 
different INFO, containing some other metadata, or a reINVITE that 
happens to be needed for some reason, or whatever. This decouples the 
two usages.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Aug 2016 06:23:04 +0000

Hi,

Please see my reply inline. But, I¹d like you to send an INFO example
according to your example, to make sure we are talking about the same
thing.

>This is NOT a legacy INFO.  It¹s a new-style INFO package, conforming to
>6086.
>
>You send an INFO, with the metadata/control body part, with the proper
>INFO mime type and content disposition.  The MSD/VEDS is not there.
>You send the MSD/VEDS as Additional Data, in a separate body part, with
>the additional data MIME type and content disposition using Call-Info.
>
>So there are two parts in the body.  One is the INFO block, the other is
>the Additional Data block, with the Call-Info header pointing to it.  The
>latter isn¹t legacy use of INFO, it¹s permitted use of Call-Info.  6069
>expressly permits this.

While RFC 6086 does allow usage of other C-D values than ³info-package²
for specific body parts, the body parts are still associated with the Info
Package - which means you know the semantics, and you know that the
receiver will support the body part. So, I still don¹t see what you need
Call-Info for?

Yes, 6086 does contain an example where one body part is not associated
with the Info Package to begin with. But, again, that is to address legacy
usages of INFO.

Regards,

Christer

>> I thought we discussed usage of legacy (non-Info-Package) INFOs
>>already. RFC 6086 allows it for backward compatibility. Any new usage
>>MUST use an Info Package.
>> 
>> I'll let others decide on whether MSD is considered additional data or
>>not, but I don't think it's relevant because additional data is not a
>>legacy INFO usage, nor does additional data update RFC 6086.
>> 
>> Regards,
>> 
>> Christer
>> 
>> 
>> To: Christer Holmberg <[email-masked]>; Paul Kyzivat
>><[email-masked]>; Drage, Keith (Nokia - GB)
>><[email-masked]>; [email-masked]; Brian Rosen
>><[email-masked]>
>>raised.  We recognize that the vehicle data (MSD for eCall and VEDS for
>>car-crash) is properly considered additional data in the context of RFC
>>7852, while the metadata/control block can be considered its own
>>request/response protocol.  With that in mind, our proposal is to have
>>the INFO package associated with the metadata/control block but not the
>>MSD nor VEDS.  For a mid-call update request, the PSAP sends a
>>metadata/control block requesting an updated MSD (or VEDS) in INFO.
>>acknowledging the request with a successful result.  Both INFO messages
>>contain a metadata/control block associated with the INFO package and
>>not referenced by a Call-Info header field.  The INFO sent by the IVS
>>also contains an updated MSD (or VEDS) as RFC 7852 additional data,
>>referenced by a Call-Info header field.  There would be two body parts
>>in the INFO from the IVS to the PSAP, each with its appropriate MIME
>>type and Content-Disposition.  One body part is associated with the INFO
>>package and is the response to the request.
>> The second body part is the updated MSD and is referenced by Call-Info.
>> This more cleanly separates the request/response protocol from the
>>vehicle data.  The request/response protocol uses INFO, is associated
>>with an INFO package, and carries data with the Info-Package
>>Content-Disposition.  INFO messages sent by the IVS may also contain
>>vehicle data not associated with the INFO package.  In eCall, this
>>allows the PSAP to request a mid-call update and the IVS to respond. In
>>car-crash, this allows the PSAP to request the vehicle to take other
>>actions (such as flashing the lights).  In all cases, the vehicle
>>responds to a request with an acknowledgment (and indicates if the
>>request was successfully carried out).
>> 
>> -------------- Randomly selected tag: --------------- It is easier to
>>fight for one's principles than to live up to them.
>>                                                   --Alfred Adler
>>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 18 Aug 2016 09:12:12 -0400

Yes, that makes sense.

Brian
> On Aug 17, 2016, at 8:59 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> And IMO it is a valid thing to do. (I'm pretty sure I did mention an approach like this along the way, but it got lost along the way.)
> 
> I would then suggest that the while there can then be an INFO with a body that requests the sending of Additional Data, there shouldn't be a *requirement* that the Additional Data come in the same INFO that carries the ACK to that request. It might *typically* come there, because it is a convenient message that happens to be going out at the right time. But it *might* happen to go in some other message - a different INFO, containing some other metadata, or a reINVITE that happens to be needed for some reason, or whatever. This decouples the two usages.
> 
> 	Thanks,
> 	Paul
> 
>>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 18 Aug 2016 09:15:22 -0400

We’ll work up an example.

There is no restriction on an INFO carrying body parts not associated with the INFO.  In this case, we would have a body part associated with the Call-Info CID (the MSD), as well as the body part that is associated with the INFO (the ack).  As per the prior message, the MSD wouldn’t be limited to to the ACK INFO, even if it usually occurred there.

Brian
> On Aug 18, 2016, at 2:23 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 18 Aug 2016 13:22:16 +0000

Hello,

From my point of view, it does not make sense. 

Why to send two bodies (MSD, control block for "ack") in an INFO request, if so far solely MSD was included and is no problem was found?

Moreover, if we adopt Paul's idea that MSD and control block for "ack" can potentially be sent in two INFO transactions, then we get an additional INFO transaction.

And if we need to send two bodies and we are defining an info package to transfer them, why don't we associate both bodies with the info package?

And I still have not got an answer to my question on why is using the Call-ID in INFO request? UAS of INFO request? Proxy handling INFO request?

So, in short, this proposal brings a LOT of complexity for no clear benefit.

Kind regards

Ivo Sedlacek

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Thursday, August 18, 2016 3:12 PM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Yes, that makes sense.

Brian

---

From: Brian Rosen <[email-masked]>
Date: Thu, 18 Aug 2016 11:43:38 -0400

Ivo

Please try to look at this from a wider perspective.  You are concentrating on very limited example of a more general problem of PSAPs being able to manage data being sent to them from a device.

The MSD comes in more than one way: unsolicited, and requested.  The data block, the MSD itself, is the same.  Its use is the same.  The XML is the same.  It IS Additional Data.

The command we send to request in mid call is an active command/control and response protocol that has a much bigger use than just eCall.  There are many examples of this, including the one Randall mentioned: getting environmental information from a building.  I can give you plenty of others, for example, you may be able to control the elevators of that building, or a container may have some kind of leak detector that you want an update from. 

This command/control mechanism needs to be standardized, independently of eCall, but we’re not going to try to do that in this document.  All we want to do is separate the piece that very clearly is Additional Data, from the command/control and it’s Ack/Nak response.  Since we recognize that any other instance of command/control that is mid call initiated would need its own INFO package, we don’t need to do much to make eCall an instance of a more general command/control mechanism.

We propose to use Call-Info to “label” the MSD so that all instances of this data is treated as Additional Data, which it very clearly is.  

With respect to UAS and Proxy issues, again, please consider that eCall is a very limited example of a much bigger problem.  Consider, for example, if a call was dropped, and the PSAP called the vehicle back.  We would like to be able to request the MSD, but now the caller is the PSAP.  I don’t think a proxy would have any problems with, or would do anything with the INFO package other than forward it like any other INFO.  The same as is would with Call-Info.

The only complexity is two MIME body parts and the Call-Info header.  Yeah, that’s more, three lines, and a little extra processing.  

This is a compromise between what authors want and you want.  Please reconsider.

Brian

> On Aug 18, 2016, at 9:22 AM, Ivo Sedlacek <[email-masked]> wrote:
> 
> Hello,
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Aug 2016 15:49:37 +0000

Hi,

> There is no restriction on an INFO carrying body parts not associated with the INFO.

There is a restriction saying that any new INFO usage must use the info package mechanism.

The only reason RFC 6086 allows carrying body parts not associated with an info package is for backward compatibility with legacy INFO usages.

Regards,

Christer

  In this case, we would have a body part associated with the Call-Info CID (the MSD), as well as the body part that is associated with the INFO (the ack).  As per the prior message, the MSD wouldn’t be limited to to the ACK INFO, even if it usually occurred there.

Brian
>> This is NOT a legacy INFO.  It¹s a new-style INFO package, conforming 
>> to 6086.
>> 
>> You send an INFO, with the metadata/control body part, with the 
>> proper INFO mime type and content disposition.  The MSD/VEDS is not there.
>> You send the MSD/VEDS as Additional Data, in a separate body part, 
>> with the additional data MIME type and content disposition using Call-Info.
>> 
>> So there are two parts in the body.  One is the INFO block, the other 
>> is the Additional Data block, with the Call-Info header pointing to 
>> it.  The latter isn¹t legacy use of INFO, it¹s permitted use of 
>> Call-Info.  6069 expressly permits this.
> 
> 
> While RFC 6086 does allow usage of other C-D values than 
> ³info-package² for specific body parts, the body parts are still 
> associated with the Info Package - which means you know the semantics, 
> and you know that the receiver will support the body part. So, I still 
> don¹t see what you need Call-Info for?
> 
> Yes, 6086 does contain an example where one body part is not 
> associated with the Info Package to begin with. But, again, that is to 
> address legacy usages of INFO.
> 
> Regards,
> 
> Christer
> 
> 
> 
>> 
>>> already. RFC 6086 allows it for backward compatibility. Any new 
>>> usage MUST use an Info Package.
>>> 
>>> I'll let others decide on whether MSD is considered additional data 
>>> or not, but I don't think it's relevant because additional data is 
>>> not a legacy INFO usage, nor does additional data update RFC 6086.
>>> 
>>> Regards,
>>> 
>>> Christer
>>> 
>>> 
>>> The authors wish to propose a solution to the concerns that have 
>>> been raised.  We recognize that the vehicle data (MSD for eCall and 
>>> VEDS for
>>> car-crash) is properly considered additional data in the context of 
>>> RFC 7852, while the metadata/control block can be considered its own 
>>> request/response protocol.  With that in mind, our proposal is to 
>>> additional data, referenced by a Call-Info header field.  There 
>>> would be two body parts in the INFO from the IVS to the PSAP, each 
>>> with its appropriate MIME type and Content-Disposition.  One body 
>>> part is associated with the INFO package and is the response to the request.
>>> vehicle data.  The request/response protocol uses INFO, is 
>>> to respond. In car-crash, this allows the PSAP to request the 
>>> vehicle to take other actions (such as flashing the lights).  In all 
>>> cases, the vehicle responds to a request with an acknowledgment (and 
>>> -------------- Randomly selected tag: --------------- It is easier 
>>> to fight for one's principles than to live up to them.
>>>                                                  --Alfred Adler
>>>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Aug 2016 16:10:14 +0000

Hi,

...

>We propose to use Call-Info to “label” the MSD so that all instances of this data is treated as Additional Data, which it very clearly is.  

When you use INFO you define, within the info package specification, that when you receive body X you treat it as Y. If that treatment has some connection to how you treat Additional Data, fine, but that is a separate issue from how you carry the information in SIP.

No need for any Call-Info "label".

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Aug 2016 12:26:10 -0400

> The only reason RFC 6086 allows carrying body parts not associated with an info package is for backward compatibility with legacy INFO usages.

IMO the specification of INFO has no business disallowing "extra" body 
parts that are serving other needs that are incidental to the primary 
purpose of INFO.

This is no different than the situation with INVITE. INVITE has *one* 
body part that is tightly bound to the function of the message. It is 
identified by content-disposition "session" and content-type 
application/sdp. But it doesn't disallow other body parts, or the 
multipart wrapper that is needed when there are multiple body parts. 
There is no reason for the situation to be any different for INFO.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Aug 2016 16:38:30 +0000

Hi,

> IMO the specification of INFO has no business disallowing "extra" body parts that are serving other needs that are incidental to the primary purpose of INFO.
>
> This is no different than the situation with INVITE. INVITE has *one* body part that is tightly bound to the function of the 
> message. It is identified by content-disposition "session" and content-type application/sdp. But it doesn't disallow other 
> body parts, or the multipart wrapper that is needed when there are multiple body parts. 

MSD transport is one of the main reasons we send the INFO to begin - it defines INFO usage, which means you have to use an info package.

MSD is *not* some information that is piggybacked onto the message that someone just happens to send for some other purpose.

Regards,

Christer

	Thanks,
	Paul

>>> This is NOT a legacy INFO.  It¹s a new-style INFO package, 
>>> conforming to 6086.
>>>
>>> So there are two parts in the body.  One is the INFO block, the 
>>> other is the Additional Data block, with the Call-Info header 
>>> pointing to it.  The latter isn¹t legacy use of INFO, it¹s permitted 
>>> use of Call-Info.  6069 expressly permits this.
>>
>>
>> associated with the Info Package - which means you know the 
>> semantics, and you know that the receiver will support the body part. 
>> So, I still don¹t see what you need Call-Info for?
>>
>> associated with the Info Package to begin with. But, again, that is 
>> to address legacy usages of INFO.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>>
>>>> To: Christer Holmberg <[email-masked]>; Paul 
>>>> Kyzivat <[email-masked]>; Drage, Keith (Nokia - GB) 
>>>> RFC 7852, while the metadata/control block can be considered its 
>>>> own request/response protocol.  With that in mind, our proposal is 
>>>> to have the INFO package associated with the metadata/control block 
>>>> but not the MSD nor VEDS.  For a mid-call update request, the PSAP 
>>>> sends a metadata/control block requesting an updated MSD (or VEDS) in INFO.
>>>> Info-Package Content-Disposition.  INFO messages sent by the IVS 
>>>> may also contain vehicle data not associated with the INFO package.  
>>>> In eCall, this allows the PSAP to request a mid-call update and the 
>>>> IVS to respond. In car-crash, this allows the PSAP to request the 
>>>> vehicle to take other actions (such as flashing the lights).  In 
>>>> all cases, the vehicle responds to a request with an acknowledgment 
>>>> (and indicates if the request was successfully carried out).
>>>>

---

From: Randall Gellens <[email-masked]>
Date: Thu, 18 Aug 2016 09:56:39 -0700

Hi Christer,

RFC 6086 says:

       NOTE: An INFO request can also contain other body parts that are
       meaningful within the context of an invite dialog usage but are
       not specifically associated with the INFO method and the
       application concerned.

At 3:49 PM +0000 8/18/16, Christer Holmberg wrote:

>  Hi,
>
>>  We'll work up an example.
>>
>  There is a restriction saying that any new INFO 
> usage must use the info package mechanism.
>
>  The only reason RFC 6086 allows carrying body 
> parts not associated with an info package is 
> for backward compatibility with legacy INFO 
> usages.
>
>  Regards,
>
>  Christer
>
>
>    In this case, we would have a body part 
> associated with the Call-Info CID (the MSD), as 
> well as the body part that is associated with 
> the INFO (the ack).  As per the prior message, 
> the MSD wouldn't be limited to to the ACK INFO, 
> even if it usually occurred there.
>
>  Brian
>>  Please see my reply inline. But, I©–d like you to send an INFO example
>>>  This is NOT a legacy INFO.  It©–s a new-style INFO package, conforming
>>>  to 6086.
>>>
>>>  it.  The latter isn©–t legacy use of INFO, it©–s permitted use of
>>  ©¯info-package©— for specific body parts, the body parts are still
>>  don©–t see what you need Call-Info for?
>>

-------------- Randomly selected tag: ---------------
Q:  Why do mountain climbers rope themselves together?
A:  To prevent the sensible ones from going home.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 18 Aug 2016 10:00:01 -0700

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

>>>  There is a restriction saying that any new 
>>> INFO usage must use the info package 
>>> mechanism.
>>>
>>  IMO the specification of INFO has no business 
>> disallowing "extra" body parts that are 
>> serving other needs that are incidental to the 
>> primary purpose of INFO.
>>
>>  This is no different than the situation with 
>> INVITE. INVITE has *one* body part that is 
>> tightly bound to the function of the
>>  message. It is identified by 
>> content-disposition "session" and content-type 
>> application/sdp. But it doesn't disallow other
>>  body parts, or the multipart wrapper that is 
>> needed when there are multiple body parts.
>  MSD transport is one of the main reasons we 
> send the INFO to begin - it defines INFO usage, 
> which means you have to use an info package.
>
>  MSD is *not* some information that is 
> piggybacked onto the message that someone just 
> happens to send for some other purpose.

Hi Christer,

We're saying that INFO will be used for a 
request/response protocol.  If a request is for 
the IVS to send an updated MSD, the IVS can send 
that MSD in any convenient SIP message.  As Paul 
says, it might usually be the INFO that contains 
the response to the request (the ACK) but it 
isn't required to be, it might for example be in 
a re-INVITE sent for some other purpose.

>>>  On Aug 18, 2016, at 2:23 AM, Christer 
>>> Holmberg <[email-masked]> 
>>> wrote:
>>>
>>>  Hi,
>>>
>>>>  This is NOT a legacy INFO.  It©–s a new-style INFO package,
>>>>  conforming to 6086.
>>>>
>>>>  pointing to it.  The latter isn©–t legacy use of INFO, it©–s permitted
>>>  So, I still don©–t see what you need Call-Info for?
>>>

-------------- Randomly selected tag: ---------------
George Orwell was an optimist.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 18 Aug 2016 10:05:39 -0700

Hi,

We want there to be one way to transfer the MSD, which uses 
Call-Info.  You've made the argument that we can't use the same 
Call-Info mechanism in non-INFO and also in INFO.  With the 
compromise proposal, we are complying with this: the MSD is always 
sent as Additional Data using Call-Info, while INFO is used to 
transfer a request/response data block.  The fact that sometimes an 
INFO might also have an MSD is essentially besides the point of INFO. 
INFO is used for INFO package compliant data.

--Randy

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

>  Hi,
>
>  ...
>
>>We propose to use Call-Info to "label" the MSD so that all 
>> instances of this data is treated as Additional Data, which it 
>> very clearly is. 
>
>  When you use INFO you define, within the info package 
> specification, that when you receive body X you treat it as Y. If 
> that treatment has some connection to how you treat Additional 
> Data, fine, but that is a separate issue from how you carry the 
> information in SIP.
>

-------------- Randomly selected tag: ---------------
Creativity is just having enough dots to connect.   --Steve Jobs

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Aug 2016 17:08:08 +0000

Hi,

>       not specifically associated with the INFO method and the

The MSD body part *IS* associated with the INFO method. MSD (in addition to the request/ack) is the reason you send the INFO to begin with. It's the main usage of the INFO.

Application foo doesn't send INFO in order to transport bar, and then you just happen to piggyback the MSD because there happens to be an INFO being sent where you can piggyback it.

Regards,

Christer

At 3:49 PM +0000 8/18/16, Christer Holmberg wrote:

>  The only reason RFC 6086 allows carrying body parts not associated 
> with an info package is for backward compatibility with legacy INFO 
> usages.
>
>  Regards,
>
>  Christer
>
>
>    In this case, we would have a body part associated with the 
> Call-Info CID (the MSD), as well as the body part that is associated 
> with the INFO (the ack).  As per the prior message, the MSD wouldn't 
> be limited to to the ACK INFO, even if it usually occurred there.
>
>  Brian
>>  Please see my reply inline. But, I©-d like you to send an INFO 
>> example  according to your example, to make sure we are talking about 
>> the same  thing.
>>
>>>  This is NOT a legacy INFO.  It©-s a new-style INFO package, 
>>> conforming  to 6086.
>>>
>>> pointing to  it.  The latter isn©-t legacy use of INFO, it©-s 
>>> permitted use of  Call-Info.  6069 expressly permits this.
>>
>>
>> ©¯info-package©- for specific body parts, the body parts are still  
>> semantics,  and you know that the receiver will support the body 
>> part. So, I still  don©-t see what you need Call-Info for?
>>
>>>>  I'll let others decide on whether MSD is considered additional 
>>>> data  or not, but I don't think it's relevant because additional 
>>>> data is  not a legacy INFO usage, nor does additional data update RFC 6086.
>>>>
>>>>  Regards,
>>>>
>>>>  Christer
>>>>
>>>>
>>>>  car-crash) is properly considered additional data in the context 
>>>> of  RFC 7852, while the metadata/control block can be considered 
>>>> its own  request/response protocol.  With that in mind, our 
>>>> proposal is to  have the INFO package associated with the 
>>>> metadata/control block but  not the MSD nor VEDS.  For a mid-call 
>>>> update request, the PSAP sends  a metadata/control block requesting an updated MSD (or VEDS) in INFO.
>>>> may  also contain vehicle data not associated with the INFO 
>>>> package.  In  eCall, this allows the PSAP to request a mid-call 
>>>> update and the IVS  to respond. In car-crash, this allows the PSAP 
>>>> to request the  vehicle to take other actions (such as flashing the 
>>>> lights).  In all  cases, the vehicle responds to a request with an 
>>>> acknowledgment (and  indicates if the request was successfully carried out).
>>>>
>>>>  This has an additional advantage of making it cleaner and easier 
>>>> to  reuse the emergency call request/response protocol later, in 
>>>> other  documents (e.g., so the PSAP can request building sensor data).
>>>>
>>>>  --
>>>>  Randall Gellens

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Aug 2016 17:12:08 +0000

Hi,

>We want there to be one way to transfer the MSD, which uses Call-Info.  You've made the argument that we can't use the same Call-Info mechanism in non-INFO and also >in INFO.  With the compromise proposal, we are complying with this: the MSD is always sent as Additional Data using Call-Info, while INFO is used to transfer a >request/response data block.  The fact that sometimes an INFO might also have an MSD is essentially besides the point of INFO. 

Not since MSD transport is the reason you send the INFO to begin with. And, sometimes MSD will be the *ONLY* thing you transport in the INFO, which means it is not "might also have an MSD" - in such cases it will ONLY have an MSD.

Regards,

Christer

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

>  Hi,
>
>  ...
>
>>We propose to use Call-Info to "label" the MSD so that all  instances 
>>of this data is treated as Additional Data, which it  very clearly is.
>
>  When you use INFO you define, within the info package specification, 
> that when you receive body X you treat it as Y. If that treatment has 
> some connection to how you treat Additional Data, fine, but that is a 
> separate issue from how you carry the information in SIP.
>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 18 Aug 2016 13:19:12 -0400

The way we would write this, the INFO always has a command request or response.
The MSD can be in any convenient message that can carry a Call-Info.

We understand that the MSD is related to the command and it’s response.  But it’s not necessary to get legalistic about it.  We have a valid INFO package, and we’re using it appropriately.  Carrying the MSD in Call-Info doesn’t really violate the spirit of what 6086 says.  Violating the letter is an interpretation.  I interpret it as allowed.  I suppose we could ask sippcore for a consensus call if you insist.

And you keep ignoring WHY we’re trying to compromise with you.  The command/response is useful in other domains, and the MSD is Additional Data.

Brian

> On Aug 18, 2016, at 1:12 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Aug 2016 17:28:42 +0000

Hi,

>>>  IMO the specification of INFO has no business disallowing "extra" 
>>> body parts that are serving other needs that are incidental to the 
>>> primary purpose of INFO.
>>>
>>>  This is no different than the situation with INVITE. INVITE has 
>>> *one* body part that is tightly bound to the function of the  
>>> message. It is identified by content-disposition "session" and 
>>> content-type application/sdp. But it doesn't disallow other  body 
>>> parts, or the multipart wrapper that is needed when there are 
>>> multiple body parts.
>>  MSD transport is one of the main reasons we send the INFO to begin - 
>> it defines INFO usage, which means you have to use an info package.
>>
>>  MSD is *not* some information that is piggybacked onto the message 
>> that someone just happens to send for some other purpose.
>
>Hi Christer,
>
>We're saying that INFO will be used for a request/response protocol.  If a request is for the IVS to send an
>updated MSD, the IVS can send that MSD in any convenient SIP message. 

I don't consider the MSD something can is sent in any convenient SIP message. Sending the MSD is a main part of eCall, and we should use a proper mechanism for it - we shall not send it "in any convenient SIP message".

>As Paul says, it might usually be the INFO that contains the response to the request (the ACK) but it isn't required to be, it might for example 
>be in a re-INVITE sent for some other purpose.

So, now you are saying that in cases where MSD is the ONLY thing you send (i.e. there is no ACK), then you would use re-INVITE?????

This is only getting more and more messy...

Regards,

Christer

> associated with the Call-Info CID (the MSD), as well as the body part 
> that is associated with the INFO (the ack).  As per the prior message, 
> the MSD wouldn't be limited to to the ACK INFO, even if it usually 
> occurred there.
>>
>>  Brian
>>>  On Aug 18, 2016, at 2:23 AM, Christer Holmberg 
>>> <[email-masked]>
>>> wrote:
>>>
>>>  Hi,
>>>
>>> example  according to your example, to make sure we are talking 
>>> about the same  thing.
>>>
>>>  So, I still don©-t see what you need Call-Info for?
>>>
>>>>> been raised.  We recognize that the vehicle data (MSD for eCall 
>>>>> and  VEDS for
>>>>> update request, the PSAP  sends a metadata/control block 
>>>>> requesting an updated MSD (or VEDS) in INFO.
>>>>>  This more cleanly separates the request/response protocol from 
>>>>> the  vehicle data.  The request/response protocol uses INFO, is  
>>>>>  In eCall, this allows the PSAP to request a mid-call update and 
>>>>> the  IVS to respond. In car-crash, this allows the PSAP to request 
>>>>> the  vehicle to take other actions (such as flashing the lights).  
>>>>> In  all cases, the vehicle responds to a request with an 
>>>>>  -------------- Randomly selected tag: --------------- It is 
>>>>> easier  to fight for one's principles than to live up to them.
>>>>>                                                   --Alfred Adler
>>>>>

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- George Orwell was an optimist.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Aug 2016 17:52:08 +0000

Hi,

>We understand that the MSD is related to the command and it’s response.  But it’s not necessary to get legalistic about it.  We have a valid INFO package, and we’re using it >appropriately.  Carrying the MSD in Call-Info doesn’t really violate the spirit of what 6086 says. 

I'm afraid I strongly disagree with that. 

Sending req/ack and MSD is the main purpose of the INFO, and just because you use info package for req/ack doesn't mean you don't have to use it for MSD.

If MSD would be something people have used INFO for sending long before 6086, I'd agree with you. But, that's not the case. Sending MSD defines a new INFO usage.

Regards,

Christer

 Violating the letter is an interpretation.  I interpret it as allowed.  I suppose we could ask sippcore for a consensus call if you insist.

Brian

>>> instances of this data is treated as Additional Data, which it  very clearly is.
>>

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 19 Aug 2016 07:36:37 +0000

Hello,

> Please try to look at this from a wider perspective.  You are concentrating 
> on very limited example of a more general problem of PSAPs being able to 
> manage data being sent to them from a device.

We are solving eCall.

If you wish to solve other problems, please bring a separate draft.

> The MSD comes in more than one way: unsolicited, and requested.  The data 
> block, the MSD itself, is the same.  Its use is the same.  The XML is the 
> same.  It IS Additional Data.

MSD is data whose sending in INFO is associated with usage of the info package emergencyCallData.eCall.MSD. 

As such, the info package provides the semantic of the data. 

Why do you believe that this is "Additional Data"?

> The command we send to request in mid call is an active command/control and 
> response protocol that has a much bigger use than just eCall.  There are many 
> examples of this, including the one Randall mentioned: getting environmental 
> information from a building.  I can give you plenty of others, for example, 
> you may be able to control the elevators of that building, or a container may 
> have some kind of leak detector that you want an update from. 

The info package is introduced for eCall and MSD transport as can be seen from its name: 

	emergencyCallData.eCall.MSD

Getting environmental information from a building is unrelated to eCall and sending of MSD, so I wonder how you can use this info package for it.

> This command/control mechanism needs to be standardized, independently of 
> eCall, but we’re not going to try to do that in this document.  All we want 
> to do is separate the piece that very clearly is Additional Data, from the 
> command/control and it’s Ack/Nak response.  Since we recognize that any other 
> instance of command/control that is mid call initiated would need its own 
> INFO package, we don’t need to do much to make eCall an instance of a more 
> general command/control mechanism.
>
> We propose to use Call-Info to “label” the MSD so that all instances of this 
> data is treated as Additional Data, which it very clearly is.  

As each data is sent using its own info package, semantic of this data is indicated by the info package.  No need of additional Call-Info again.
 
> With respect to UAS and Proxy issues, again, please consider that eCall is a 
> very limited example of a much bigger problem.  Consider, for example, if a 
> call was dropped, and the PSAP called the vehicle back.  We would like to be 
> able to request the MSD, but now the caller is the PSAP.  I don’t think a 
> proxy would have any problems with, or would do anything with the INFO 
> package other than forward it like any other INFO.  The same as is would with Call-Info.

You are still not answering the question: 

The question related to usage of Call-Info in INFO request.

PSAP call-back is not done using INFO.
 
> The only complexity is two MIME body parts and the Call-Info header.  Yeah, 
> that’s more, three lines, and a little extra processing.  
> 

This complexity is entirely unnecessary.

Please reconsider.

Kind regards

Ivo Sedlacek

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 19 Aug 2016 07:42:59 +0000

> The MSD can be in any convenient message that can carry a Call-Info.

I am still waiting for answer on the following:

	And I still have not got an answer to my question on who is using the Call-ID in INFO request? UAS of INFO request? Proxy handling INFO request?

Kind regards

Ivo