Subject: Re: [sipcore] Can an INFO contain a body related to, but not part of the INFO package?

From: Randall Gellens <[email-masked]>
Date: Sun, 4 Sep 2016 09:17:13 -0700

At 7:27 PM -0400 8/25/16, Dale R. Worley wrote:

>  BTW, what is the name of the draft in question?  As far as I can tell,
>  it's draft-ietf-ecrit-ecall-11.

Yes, that's correct.

>    Why do the example INFO requests in
>  that draft not have Info-Package headers, even though those are central
>  to the interpretation of an info package INFO request?

Thanks for pointing this out.  I'll fix it in the next revision.

>
>  As I understand it:
>
>  RFC 6086 allows an Info Package INFO request to contain the info package
>  data as either the entire message body, or as one part of a multipart
>  body.  Which one applies is determined by the placement of a
>  "Content-Disposition: Info-Package" header, either in the message
>  headers or the headers of one part of the multipart body.  The info
>  package part may itself be a multipart type.
>
>  Any additional body parts of the multipart case SHOULD NOT be data that
>  is intrinsically associated with the data of the info package.  The
>  words "not specifically associated with the INFO method and the
>  application concerned" aren't quite what one means, since the data is
>  *always* associated with "the application concerned" in some way.  The
>  critical thing is that the data is not specifically associated with the
>  particular info package of this INFO request.

That's my understanding as well.

>
>  In ecrit communications, the callee can send an INFO info package
>  request which requests the caller and the transit networks to resend the
>  RFC 7852 Additional Data.  That stimulates the caller to send an INFO
>  request for an info package (seemingly) called "ACK".  The ACK info
>  package acknowledges that the caller has processed the Additional Data
>  refresh request.  Also, the caller attaches to the INFO request its
>  current Additional Data.  And the transit networks attach to the INFO
>  request their current Additional Data.

The mechanism permits the PSAP (the callee) to request that the 
vehicle (the caller) send an updated MSD, which is RFC 7852 
Additional Data.  There is no mechanism to request that service 
providers or access networks resend their RFC 7852 Additional Data, 
and there is no expectation that service providers or access networks 
send updated data.

The INFO package has associated data which can contain either a 
request or an ack.  The package is currently called 
'emergencyCallData.eCall.MSD' but might be renamed to something more 
generic, such as 'emergencyCallData.control'

>
>  The question is, How is the updated Additional Data to be attached to
>  the INFO request?  One choice is that it is attached as described in RFC
>  7852, in the same way that it is attached to the INVITE request, as
>  additional body parts pointed to by Call-Info headers.  The other choice
>  is that it is incorporated into the ACK info package.

Yes, that is the choice.

>
>  An additional question:  It is clear how the caller detects that it must
>  resend its Additional Data.  But how do the transit networks detect that
>  they must resend their Additional Data?  Must they scan all transiting
>  INFO requests for use of the ACK info package?  I suppose that only
>  requests to urn:service:sos:* URIs need be scanned.

Transit networks do not resend their data, so there is no requirement 
nor expectation that they monitor INFO requests.

>
>  The advantage of attaching the Additional Data in the RFC 7852 manner is
>  that the mechanism is already defined, and its implementation is already
>  required.
>
>  The advantage of attaching the Additional Data as part of the ACK info
>  package is that it conforms to RFC 6086, since the Additional Data is
>  specifically intended to be attached to that INFO request, not just some
>  caller's request chosen at random within the dialog.
>
>  Note:  Suppose we define the ACK info package to *only* acknowledge
>  receiving and processing the request for resend, but allow the caller to
>  attach the Additional Data to any request it chooses.  E.g., the caller
>  could send an UPDATE carrying the Additional Data followed by an INFO
>  informing the callee that it had resent the data.  Then the Additional
>  Data would not be *part of* the ACK info package data and the RFC 7852
>  method would not contravene RFC 6086 -- even if the caller *just
>  happened* to always attach the Additional Data to the INFO for the ACK
>  package.

Exactly.  That's the proposal floated by the authors a couple weeks ago.

>
>  Or we could do it *both ways* at the *same time*...

That's the proposal that Christer also sent to the list a few days ago.

>
>  Here is an example INFO requesting resending the ecrit data, taken from
>  draft-ietf-ecrit-ecall-11.  I've added "Info-Package:
>  emergencyCallData.eCall.MSD".
>
>        INFO sip:[email-masked] SIP/2.0
>        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: 41862 INFO
>        Info-Package: emergencyCallData.eCall.MSD
>        Recv-Info: emergencyCallData.eCall.MSD
>        Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,
>               SUBSCRIBE, NOTIFY, UPDATE
>        Content-Type: application/EmergencyCallData.eCall.control+xml
>        Content-ID: [email-masked]
>        Content-Disposition: info-package
>
>        <?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">
>
>        <request action="send-data" datatype="eCall.MSD"/>
>
>        </EmergencyCallData.eCall.Control>
>
>  Here is the response INFO request that I propose, made by inserting the
>  Additional Data from an example in RFC 7852 to the response INFO request
>  in the draft:
>
>        INFO urn:service:sos.ecall.automatic SIP/2.0
>        To: urn:service:sos.ecall.automatic
>        From: <sip:[email-masked]>;tag=9fxced76sl
>        Call-ID: [email-masked]
>        Call-Info: cid:[email-masked];
>                   purpose=emergencyCallData.eCall.MSD;
>        Call-Info: <http://wwww.example.com/hannes/photo.jpg>
>                       ;purpose=icon,
>          <http://www.example.com/hannes/> ;purpose=info,
>          <cid:[email-masked]>
>              ;purpose=EmergencyCallData.ProviderInfo,
>          <cid:[email-masked]>
>              ;purpose=EmergencyCallData.DeviceInfo
>        Geolocation: <https://ls.example.net:9768/357yc6s64ceyoiuy5ax3o>
>        Geolocation-Routing: yes
>        Accept: application/sdp, application/pidf+xml,
>                application/emergencyCallData.eCall.control+xml
>        CSeq: 51862 INFO
>        Info-Package: emergencyCallData.eCall.MSD
>        Recv-Info: emergencyCallData.eCall.MSD
>        Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,
>               SUBSCRIBE, NOTIFY, UPDATE
>        Content-Disposition: info-package
>        Content-Transfer-Encoding: binary
>        Content-Type: multipart/mixed; boundary=boundary1
>        Content-Length: ...
>
>        --boundary1
>        Content-Type: application/emergencyCallData.eCall.MSD+per
>        Content-ID: [email-masked]
>
>             ...MSD in ASN.1 PER encoding goes here...
>
>        --boundary1
>        Content-Type: application/EmergencyCallData.DeviceInfo+xml
>        Content-ID: <[email-masked]>
>        Content-Disposition: by-reference;handling=optional
>
>        <?xml version="1.0" encoding="UTF-8"?>
>        <dev:EmergencyCallData.DeviceInfo
>             xmlns:dev=
>             "urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo">
>            ...
>        </dev:EmergencyCallData.DeviceInfo>
>
>        --boundary1
>        Content-Type: application/EmergencyCallData.ProviderInfo+xml
>        Content-ID: <[email-masked]>
>        Content-Disposition: by-reference;handling=optional
>
>        <?xml version="1.0" encoding="UTF-8"?>
>        <pi:EmergencyCallData.ProviderInfo
>           xmlns:pi=
>              "urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">
>            ...
>        </pi:EmergencyCallData.ProviderInfo>
>        --boundary1--
>
>  The point here is that the emergencyCallData.eCall.MSD info package is
>  defined to allow a multipart body and the body of this request is one
>  such.  One part of the body is the
>  application/emergencyCallData.eCall.MSD+per, which presumably carries
>  the ACK semantics, and zero or more parts are
>  application/EmergencyCallData.ProviderInfo+xml, which carry the
>  Additional Data.  This structure conforms to RFC 6086.  (The Call-Info
>  headers that point to external resources are OK because they do not
>  involve additional body parts.)
>
>  The application/EmergencyCallData.ProviderInfo+xml parts are pointed to
>  by Call-Info headers, conforming to RFC 7852.
>
>  Note that the logic that inserts a
>  application/EmergencyCallData.ProviderInfo+xml part into the multipart
>  body which is the emergencyCallData.eCall.MSD info package is the same
>  as the logic which inserts such a part into an ecrit INVITE.

Yes.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- 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: [email-masked] (Dale R. Worley)
Date: Mon, 05 Sep 2016 15:05:55 -0400

> and there is no expectation that service providers or access networks 

(There may have been other statements of this principle.)  That clears
up that question of mine.

Dale