Subject: [Ecrit] Errata and queries re draft-ietf-ecrit-ecall-11

From: [email-masked] (Dale R. Worley)
Date: Tue, 30 Aug 2016 10:54:52 -0400

Note that the <...> around the URL in the value of a Call-Info header is
mandatory (RFC 3261 section 25.1):

    Call-Info   =  "Call-Info" HCOLON info *(COMMA info)
    info        =  LAQUOT absoluteURI RAQUOT *( SEMI info-param)
    info-param  =  ( "purpose" EQUAL ( "icon" / "info"
                   / "card" / token ) ) / generic-param

All four example Call-Info headers in draft-ietf-ecrit-ecall-11 omit the
<...>:

      Call-Info: cid:[email-masked];
                 purpose=emergencyCallData.eCall.MSD;
      Call-Info: cid:[email-masked];
                 purpose=emergencyCallData.eCall.control;
      Call-Info: cid:[email-masked];
                 purpose=emergencyCallData.eCall.control;
      Call-Info: cid:[email-masked];
                 purpose=emergencyCallData.eCall.MSD;

In addition, all of these headers end with an incorrect semicolon.

RFC 6086 section 4.2.1 says:

   The INFO request MUST NOT contain a Recv-Info header field.  A UA can
   only indicate a set of Info Packages for which it is willing to
   receive INFO requests by using the SIP methods (and their responses)
   listed in Section 5.

But draft-ietf-ecrit-ecall-11 has two places in section 11 where example
INFO requests contain a Recv-Info header:

      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
      Recv-Info: emergencyCallData.eCall.MSD
      ...

      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;
      Accept: application/sdp, application/pidf+xml,
              application/emergencyCallData.eCall.control+xml
      CSeq: 51862 INFO
      Recv-Info: emergencyCallData.eCall.MSD
      ...

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

It is clear how the caller detects that it must resend its Additional
Data, it is requested to by the callee.  But how do the transit networks
detect that they must resend their Additional Data, i.e., attach it to
the resulting INFO request?  Must they scan all transiting INFO requests
for use of the ACK info package?  I suppose that that can be specified,
and indeed, only requests to urn:service:sos:* URIs need be scanned, so
the overhead is probably small.  (Scanning the INFO requests would be
much the same as scanning the INVITE requests, but everybody expects
INVITE processing to be heavier than in-dialog request processing.)

Dale