Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15

From: Randall Gellens <[email-masked]>
Date: Mon, 17 Oct 2016 16:37:14 -0700

Hi Ivo,

At 12:48 AM +0000 10/17/16, Ivo Sedlacek wrote:

>  I identified a few issues:
>
>  ISSUE 1:
>
>  section 3 - given that the section 3 contains a lot of information 
> on legacy eCall in 3GPP, on ETSI requirements on NG-eCall, and CEN 
> documents, I wonder why the section 3 does not refer to 3GPP TS 
> 24.229 (particularly subclause 4.7.6) which gives details of 
> requirements on PSAP for usage of eCall in mobile environment.

Reference to TS24.229 added in section 4.  Section 3 has higher-level 
information and background, with references to SDOs rather than 
documents.  Section 4 has references to documents, which is where the 
reference to TS24.229 was added.

>
>  ISSUE 2:
>
>  section 3 - level of technical detail of the last paragraph of 
> section 3 does not fit with level of technical detail of the 
> remaining text of section 3.

Intermediate paragraphs were added in version 17.

>
>  ISSUE 3:
>
>  section 4 - add a reference to stage-3 requirements on eCall in 
> 3GPP TS 24.229.

Reference added.

>
>  ISSUE 4:
>
>  section 4, "   This document registers the 'application/
>     emergencyCallData.eCall.MSD+per' MIME Content-Type to enable the MSD
>     to be carried in SIP."
>
>  There is no MIME Content-Type registry. "MIME Content-Type" -> "MIME type"
>
>  Same in other places of the document.

Corrected "content type" to "media type".

>  ISSUE 6:
>
>  section 6 - "An MSD or a metadata/control block is always enclosed 
> in a multipart
>     body part (even if it would otherwise be the only body part in the
>     SIP message)." - which multipart MIME type is meant? 
> multipart/mixed or multipart/alternative or ....

We do not need to specify that in this text.

>
>  ISSUE 7
>
>  section 6 - "The IVS then attaches an updated MSD to a SIP
>     INFO request and sends it within the dialog." - what is meant by 
> "attaching MSD to SIP INFO request"?

I think that's made abundantly clear in the multiple earlier 
instances in the same section that say "as a MIME body part".

>
>  ISSUE 8
>
>  section 9 - "   If the IVS receives a SIP response without the 
> metadata/control
>     block, it indicates that the SIP dialog is not an NG-eCall (e.g.,
>     some part of the call is being handled as a legacy call)." - 
> needs to talk about final responses only, as earlier text states "A
>     metadata/control object is not attached to provisional (e.g., 180)
>     responses."

Agreed, fixed.

>
>  ISSUE 9
>
>  section 9 - what is "SIP status message"?

I do not see "SIP status message" anywhere in the document.

>
>  ISSUE 10
>
>  "
>  For
>     example, if a PSAP is unable to accept an eCall (e.g., due to
>     overload or too many calls from the same location), it can reject the
>     INVITE.  Since a metadata/control object is also included in the SIP
>     response that rejects the call, the IVS knows if the PSAP received
>     the MSD, and can inform the vehicle occupants that the PSAP
>     successfully received the vehicle location and information but can't
>     talk to the occupants at that time." - this prevents persons in 
> the car from getting emergency service of the PSAP using other 
> means (e.g. using circuit switched network). Possibility for DOS 
> attack.

If the PSAP is overloaded (e.g., there is a very large multi-vehicle 
incident, or another large-scale emergency incident), then there are 
likely to be multiple simultaneous eCall attempts.  The document does 
not in any way dictate or mandate PSAP response.  PSAPs are free to 
respond as they choose.  E.g., a PSAP can accept eCalls and add them 
to a queue, a PSAP can reject an eCall and include an ack with 
"received=false", a PSAP can reject an eCall and include an ack with 
"received=true".  Doing the latter indicates that the PSAP has 
received the MSD and hence is aware of the incident.

>
>  ISSUE 11
>
>  "The body for an emergencyCallData.eCall.MSD info package is a 
> multipart body." - which multipart MIME type is meant? 
> multipart/mixed or multipart/alternative or ....

We do not need to get into that level of detail in this text.

>
>  ISSUE 12
>
>  "Zero or one application/
>     emergencyCallData.eCall.MSD+per part (containing an MSD) and zero or
>     more application/emergencyCallData.control+xml (containing a
>     metadata/control object) parts are permitted." - this allows 
> INFO with no body part at all. If this is intentional, describe 
> when it is supposed to be used. If this is not intentional, state 
> that at least one of both is present.

I clarified this, thanks for catching it.

>
>  ISSUE 13
>
>  "Intermediate multipart
>     body parts MAY appear." - what does it mean? Where is 
> "Intermediate multipart body part" defined?

The text was deleted in version -16.

>
>  ISSUE 14
>
>  "while others can be
>     expected to carry an occasional request" - meaning of 
> "occasional" can be whatever, it depends on perspective of the user 
> - once per milisecond, once per second, once per minute, once per 
> hour or once per day?

Other text makes it clear that a request for an updated MSD is 
generally sent upon manual request of a PSAP call taker who suspects 
vehicle state may have changed.

>
>  ISSUE 15
>
>  Figure 8 expects location body by inclusion of Geolocation: 
> <cid:[email-masked]> but does not show it.

Fixed, thanks for catching this.

>
>  ISSUE 16
>
>>From and To in Figure 9 do not fit From and To in Figure 8.

Fixed, thanks for catching this.

>
>  ISSUE 17
>
>>From in Figure 10 does not contain tag.

Fixed, thanks for catching this.

>
>  ISSUE 18
>
>  Accept in Figure 10 is not correct - INFO response is not expected 
> to contain body.

Fixed, thanks for catching this.

>
>  ISSUE 19
>
>  To in Figure 11 does not contain tag.

Fixed, thanks for catching this.

>
>  ISSUE 20
>
>  examples contain a value of schemaLocation parameter which is not 
> aligned with https://www.w3.org/TR/xmlschema-0/#schemaLocation 
> stating "The schemaLocation attribute value consists of one or more 
> pairs of URI references, separated by white space. "
>
>             xsi:schemaLocation=
>                 "urn:ietf:params:xml:ns:EmergencyCallData:control"

Fixed.

>
>  Kind regards
>
>  Ivo Sedlacek
>
>  _______________________________________________
>  Ecrit mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/ecrit

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Children are natural mimics who act like their parents despite every
effort to teach them good manners.

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 18 Oct 2016 12:02:48 +0000

Hello,

first of all, I am participating in 3GPP CT1 meeting this week and I have not have time to review changes between -015 and -018 properly. Can we shift the deadline to next week?

I am OK with resolution of ISSUE 1, ISSUE 3, ISSUE 8, ISSUE 13, ISSUE 15, ISSUE 16, ISSUE 17, ISSUE 19.

On the remaining issues:

> > section 3 does not fit with level of technical detail of the remaining 
> > text of section 3.
> 

I still believe that section 3 contains different types of information:
Type1: generic overview of the eCall requirements, existing solutions, ...
Type2: information about the draft

It would be better to split those to separate sections.

> Corrected "content type" to "media type".

I can still see a few occurences of "content type" in -018 - e.g.

---------
      Security considerations: This ****content type**** is designed to carry
      vehicle and incident-related data during an emergency call.  This
      data contains personal information including vehicle VIN,
      location, direction, etc.  Appropriate precautions need to be
      taken to limit unauthorized access, inappropriate disclosure to
      third parties, and eavesdropping of this information.  In general,
      it is acceptable for the data to be unprotected while briefly in
      transit within the Mobile Network Operator (MNO); the MNO is
      trusted to not permit the data to be accessed by third parties.
      Sections 7 and Section 8 of [RFC7852] contain more discussion.
---------
and
---------
   The metadata/control block is designed for use with pan-European
   eCall and also eCall-like systems (i.e., in other regions), and has
   extension points.  Note that eCall-like systems might define their
   own vehicle data blocks, and so might need to register a new INFO
   package to accomodate the new data ****content type**** and the metadata/
   control object.
---------
and
--------
         This ****content type**** carries metadata and control information and
         requests, such as from a Public Safety Answering Point (PSAP)
         to an In-Vehicle System (IVS) during an emergency call.
--------

> >  ISSUE 6:
> >
> >  section 6 - "An MSD or a metadata/control block is always enclosed in 
> > a multipart

IMO, we need to. Else, the UA can provide multipart/mixed while PSAP expects multipart/alternative.

> I think that's made abundantly clear in the multiple earlier instances in the 
> same section that say "as a MIME body part".

I do not really know what "attach body to SIP request"  means. Likely, other readers will not know it either.

A reference to a section defining how to "attach body to SIP request" would help.

> I do not see "SIP status message" anywhere in the document.

It was in -015 section 9 but it looks like it was already resolved in -18.

> > the car from getting emergency service of the PSAP using other means 
> > (e.g. using circuit switched network). Possibility for DOS attack.
> 
> incident, or another large-scale emergency incident), then there are likely 
> to be multiple simultaneous eCall attempts.  The document does not in any way 
> dictate or mandate PSAP response.  PSAPs are free to respond as they choose.  
> E.g., a PSAP can accept eCalls and add them to a queue, a PSAP can reject an 
> eCall and include an ack with "received=false", a PSAP can reject an eCall 
> and include an ack with "received=true".  Doing the latter indicates that the 
> PSAP has received the MSD and hence is aware of the incident.

How can the UA be sure that such response was sent by PSAP and not by an attacker, located somewhere between UA and PSAP? 

Any SIP entity which happens to be in the path of the emergency call INVITE request can generate a 600  (Busy Everywhere), 486 (Busy Here), and 603 (Decline) response and populate it with a particular body.

It is at least a security risk and it needs to be documented.

> We do not need to get into that level of detail in this text.

IMO, we need to. Else, the UA can provide multipart/mixed while PSAP expects multipart/alternative.

> >  ISSUE 14
> >
> >  "while others can be
> >     expected to carry an occasional request" - meaning of "occasional" 
> > can be whatever, it depends on perspective of the user
> > - once per milisecond, once per second, once per minute, once per hour 
> > or once per day?
> 
> Other text makes it clear that a request for an updated MSD is generally sent 
> upon manual request of a PSAP call taker who suspects vehicle state may have changed.

A statement that the request is expected to be triggered by manual action of the PSAP call taker is good, so I suggest to add it to this section too as expert reviewer will read it.

> Fixed, thanks for catching this.

in -18, I can still see Accept with multipart/mixed in the INFO request in Figure 10.

IMO, this is wrong as we do NOT expect a body in INFO response. Yes, there will be a body in subsequent INFO request sent in opposite direction, but that's not impacted by Accept in first INFO request.

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

I can see in -18, that you chose to remove the information about schema location from the XML examples.
That's OK with me.

However, then you can also remove the following as it is not needed any more

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

Kind regards

Ivo Sedlacek

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 18 Oct 2016 13:38:40 +0000

Hi,

Regarding indicating the type of multipart (mixed, alternative etc), I
agree with Ivo. 

Unfortunately RFC 6086 doesn¹t normatively define the type either (in the
examples multipart/mixed is used, though), why I think it¹s even more
important to do it in draft-ecall.

Regards,

Christer

On 18/10/16 15:02, "Ecrit on behalf of Ivo Sedlacek"
<[email-masked] on behalf of [email-masked]> wrote:

>Hello,
>
>first of all, I am participating in 3GPP CT1 meeting this week and I have
>not have time to review changes between -015 and -018 properly. Can we
>shift the deadline to next week?
>
>>in 
>>likely 
>How can the UA be sure that such response was sent by PSAP and not by an
>attacker, located somewhere between UA and PSAP?
>
>Any SIP entity which happens to be in the path of the emergency call
>INVITE request can generate a 600  (Busy Everywhere), 486 (Busy Here),
>and 603 (Decline) response and populate it with a particular body.
>
>>"occasional" 
>>hour 
>>generally sent 
>A statement that the request is expected to be triggered by manual action
>of the PSAP call taker is good, so I suggest to add it to this section
>too as expert reviewer will read it.
>
>> >
>> >  ISSUE 18
>> >
>IMO, this is wrong as we do NOT expect a body in INFO response. Yes,
>there will be a body in subsequent INFO request sent in opposite
>direction, but that's not impacted by Accept in first INFO request.
>
>> >
>> >  ISSUE 20
>> >

---

From: Randall Gellens <[email-masked]>
Date: Tue, 18 Oct 2016 09:12:03 -0700

Hi Ivo,

I think we can address any remaining comments as part of IETF Last Call.

--Randy

At 12:02 PM +0000 10/18/16, Ivo Sedlacek wrote:

>  Hello,
>
>  first of all, I am participating in 3GPP CT1 meeting this week and 
> I have not have time to review changes between -015 and -018 
> properly. Can we shift the deadline to next week?
>

Can you elaborate on what the problem is?

>  I can still see a few occurences of "content type" in -018 - e.g.

Thanks, I'll do a grep.

> PSAP expects multipart/alternative.

It would be hard to imagine a use case where a UA generates 
multipart/alternative.  However, I don't mind adding text clarifying 
that multipart/mixed is expected.

>> instances in the
>  I do not really know what "attach body to SIP request"  means. 
> Likely, other readers will not know it either.
>

It's the same section, just a little bit before.

>  How can the UA be sure that such response was sent by PSAP and not 
> by an attacker, located somewhere between UA and PSAP?
>
>  Any SIP entity which happens to be in the path of the emergency 
> call INVITE request can generate a 600  (Busy Everywhere), 486 
> (Busy Here), and 603 (Decline) response and populate it with a 
> particular body.
>

OK, I'll add some text.

> PSAP expects multipart/alternative.

Same answer as above.

>  A statement that the request is expected to be triggered by manual 
> action of the PSAP call taker is good, so I suggest to add it to 
> this section too as expert reviewer will read it.

OK, I'll add text.

>  in -18, I can still see Accept with multipart/mixed in the INFO 

I don't see it.  Here is Figure 10:

     INFO sip:[email-masked] SIP/2.0
     To: <sip:[email-masked]>;tag=9fxced76sl
     From: Exemplar PSAP <urn:service:sos.ecall.automatic>;tag=8gydfe65t0
     Call-ID: [email-masked]
     Call-Info: <cid:[email-masked]>;
                purpose=emergencyCallData.control
     CSeq: 41862 INFO
     Info-Package: emergencyCallData.eCall.MSD
     Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,
            SUBSCRIBE, NOTIFY, UPDATE
     Content-Type: multipart/mixed; boundary=boundaryZZZ
     Content-Dispositio: Info-Package
     Content-Length: ...

     --boundaryZZZ
     Content-Disposition: by-reference
     Content-Type: application/emergencyCallData.control+xml
     Content-ID: <[email-masked]>

     <?xml version="1.0" encoding="UTF-8"?>
     <emergencyCallData.control
         xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

     <request action="send-data" datatype="eCall.MSD"/>

     </emergencyCallData.control>
      --boundaryZZZ--

                       Figure 10: INFO requesting MSD

>
>  IMO, this is wrong as we do NOT expect a body in INFO response. 
> Yes, there will be a body in subsequent INFO request sent in 
> opposite direction, but that's not impacted by Accept in first INFO 
> request.
>
>>  >
>>  >  ISSUE 20
>>  >

I've asked Hannes to verify the XML schema and examples as part of 
IETF Last Call.

-------------- Randomly selected tag: ---------------
Question Authority.  They usually know where the bathroom is.
                                              --MTV's 'Daria'

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 18 Oct 2016 16:16:23 +0000

Hi,

>I think we can address any remaining comments as part of IETF Last Call.

NO. 

We shall forward a document we are ok with. There most likely will be other issues and comments during IETF last call.

Regards,

Christer

At 12:02 PM +0000 10/18/16, Ivo Sedlacek wrote:

>  Hello,
>
>  first of all, I am participating in 3GPP CT1 meeting this week and I 
> have not have time to review changes between -015 and -018 properly. 
> Can we shift the deadline to next week?
>
>>  >  section 3 - level of technical detail of the last paragraph of  > 
>> remaining  > text of section 3.
>>

Thanks, I'll do a grep.

>>  >  section 6 - "An MSD or a metadata/control block is always 
>> enclosed in  > a multipart

It would be hard to imagine a use case where a UA generates multipart/alternative.  However, I don't mind adding text clarifying that multipart/mixed is expected.

OK, I'll add some text.

Same answer as above.

OK, I'll add text.

     --boundaryZZZ

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 18 Oct 2016 16:43:04 +0000

The comments were submitted as part of WGLC and I expect them to be addressed during WGLC.

Kind regards

Ivo

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2016 12:12 AM
To: Ivo Sedlacek <[email-masked]>; Az Mankin <[email-masked]>; [email-masked]
Subject: RE: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15

Hi Ivo,

--Randy

Thanks, I'll do a grep.

OK, I'll add some text.

Same answer as above.

OK, I'll add text.

     --boundaryZZZ

---

From: Randall Gellens <[email-masked]>
Date: Tue, 18 Oct 2016 10:36:22 -0700

Hi Ivo and Christer,

All comments have been addressed in -19.

Thank you.

At 4:43 PM +0000 10/18/16, Ivo Sedlacek wrote:

> multipart/alternative.  However, I don't mind adding text 
> clarifying that multipart/mixed is expected.
>
>>
>>>   >  ISSUE 7
>>>   >

-------------- Randomly selected tag: ---------------
It's a good idea to obey all the rules when you're young just so you'll
have the strength to break them when you're old.           --Mark Twain

---

From: Az Mankin <[email-masked]>
Date: Tue, 18 Oct 2016 10:53:04 -0700

Hi, everyone,

I'd like to remind people that we use rough consensus, not perfect
unanimity, and we use a well defined process, including practical time
periods for our phases of last call.   We also care about "running code,"
and one thing that would be valuable for this last day of the last call is
to share info on state of implementation of these two specs.  This doesn't
mean they must be fully implemented and deployed, of course, but what types
of pragmatic or empirical tests have occurred so far?

I'm planning to request IETF Last Call this afternoon (Pacific Time) as
previously announced.  This will not launch an immediate IETF Last Call,
because there is first an AD Review, and I will work to present to Alyssa
what the remaining issues are in the shepherd's writeup.  I'm open to your
sending me text as input for the writeup.

Allison

On Tue, Oct 18, 2016 at 9:16 AM, Christer Holmberg <
[email-masked]> wrote:

> We shall forward a document we are ok with. There most likely will be
> other issues and comments during IETF last call.
>
> Regards,
>
> Christer
>
>
> multipart/alternative.  However, I don't mind adding text clarifying that
> multipart/mixed is expected.
>
> >
> >>  >  ISSUE 7
> >>  >

---

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

Hi,

There haven’t been any consensus calls on the issues currently discussed, and I don’t think there need to be any: it’s mostly about sorting out and clarifying details. I don’t think there are any major open issues.

Regards,

Christer

From: Az Mankin [mailto:[email-masked]]
Sent: 18 October 2016 20:53
To: Christer Holmberg <[email-masked]>
Cc: Randall Gellens <[email-masked]>; Ivo Sedlacek <[email-masked]>; [email-masked]
Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15

Hi, everyone,
I'd like to remind people that we use rough consensus, not perfect unanimity, and we use a well defined process, including practical time periods for our phases of last call.   We also care about "running code," and one thing that would be valuable for this last day of the last call is to share info on state of implementation of these two specs.  This doesn't mean they must be fully implemented and deployed, of course, but what types of pragmatic or empirical tests have occurred so far?
I'm planning to request IETF Last Call this afternoon (Pacific Time) as previously announced.  This will not launch an immediate IETF Last Call, because there is first an AD Review, and I will work to present to Alyssa what the remaining issues are in the shepherd's writeup.  I'm open to your sending me text as input for the writeup.
Allison

On Tue, Oct 18, 2016 at 9:16 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

NO.

Regards,

Christer

Thanks, I'll do a grep.

OK, I'll add some text.

Same answer as above.

OK, I'll add text.

     INFO sip:[email-masked]<mailto:[email-masked]> SIP/2.0
     To: <sip:[email-masked]<mailto:[email-masked]>>;tag=9fxced76sl
     From: Exemplar PSAP <urn:service:sos.ecall.automatic>;tag=8gydfe65t0
     Call-ID: [email-masked]<mailto:[email-masked]>
     Call-Info: <cid:[email-masked]<mailto:[email-masked]>>;
                purpose=emergencyCallData.control
     CSeq: 41862 INFO
     Info-Package: emergencyCallData.eCall.MSD
     Allow: INVITE, ACK, PRACK, INFO, OPTIONS, CANCEL, REFER, BYE,
            SUBSCRIBE, NOTIFY, UPDATE
     Content-Type: multipart/mixed; boundary=boundaryZZZ
     Content-Dispositio: Info-Package
     Content-Length: ...

     --boundaryZZZ
     Content-Disposition: by-reference
     Content-Type: application/emergencyCallData.control+xml
     Content-ID: <[email-masked]<mailto:[email-masked]>>

-------------- Randomly selected tag: ---------------
Question Authority.  They usually know where the bathroom is.
                                              --MTV's 'Daria'
_______________________________________________
Ecrit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 27 Oct 2016 10:53:38 +0000

Hello,

I checked -19 against the comments raised during WGLC.

I am OK with resolution of ISSUE 4, ISSUE 6, ISSUE 10, ISSUE 11, ISSUE 14, ISSUE 18.

ISSUE 2 did not seem to be addressed. However, I can live with ISSUE 2 not being addressed so you can mark the ISSUE 2 as withdrawn.

ISSUE 7, ISSUE 20 have not been addressed - see below.

A new ISSUE 21 was found in -19  - see below.

> >  A reference to a section defining how to "attach body to SIP request"

> > would help.

> It's the same section, just a little bit before.

I assume you refer -19 text stating: "[RFC7852] establishes a general mechanism for attaching blocks of

   data to a SIP emergency call."

However, RC7852 contains only one occurence of "attach" and that's in Figure 6 (see below) and it seems to refer to anything else.

                  +-----------+----------------------------+

                  | Token     | Description                |

                  +-----------+----------------------------+

                  | Mobile    | The device is able to move |

                  |           |   at any time              |

                  |           |                            |

                  | Fixed     | The device is not expected |

                  |           |   to move unless the       |

                  |           |   service is relocated     |

                  |           |                            |

                  | Nomadic   | The device is not expected |

                  |           |   to change its point of   |

                  |           |   attachment while on a    |

                  |           |   call                     |

                  |           |                            |

                  | Unknown   | No information is known    |

                  |           |   about the service        |

                  |           |   mobility environment for |

                  |           |   the device               |

                  +-----------+----------------------------+

                    Figure 6: Service Mobility Registry

Or do you refer to anything else? A formal definition would help.

> >>  > stating "The schemaLocation attribute value consists of one or

> >> more  > pairs of URI references, separated by white space. "

> >  I can see in -18, that you chose to remove the information about

> > schema location from the XML examples.

> >  However, then you can also remove the following as it is not needed

> > any more

> I've asked Hannes to verify the XML schema and examples as part of IETF Last Call.

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" is still in XML text examples and there is no usage of "xsi" prefix.

ISSUE 21:

                in in-dialog requests, the Request-URI is set to remote contact URI (in case of loose routing) or to the most top route URI (in case of strict routing) - see rfc3261 section 12.2.1.1. In both cases, it would be SIP URI and not URN as in Figure 11.

Kind regards

Ivo

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 27 Oct 2016 11:14:56 +0000

(ISSUE 21 reformulated)

Hello,

                  | Token     | Description                |

                  |           |   at any time              |

                  |           |                            |

                  |           |   to move unless the       |

                  |           |                            |

                  |           |   call                     |

                  |           |                            |

                  |           |   about the service        |

                  |           |   the device               |

ISSUE 21:

                Request-URI of SIP INFO request in Figure 11 (INFO urn:service:sos.ecall.automatic SIP/2.0) is incorrect.

                Reason: in in-dialog requests, the Request-URI is set to the remote contact URI (in case of loose routing) or to the most top route URI (in case of strict routing) - see rfc3261 section 12.2.1.1.

                The draft does NOT need so state how Request-URI in SIP INFO request is set,  but the Request-URI of SIP INFO request in Figure 11 needs to be corrected.

Kind regards

Ivo

---

From: Randall Gellens <[email-masked]>
Date: Thu, 27 Oct 2016 12:08:03 -0700

At 11:14 AM +0000 10/27/16, Ivo Sedlacek wrote:

>  ISSUE 2 did not seem to be addressed. However, I can live with 
> ISSUE 2 not being addressed so you can mark the ISSUE 2 as 
> withdrawn.
>
>  I assume you refer -19 text stating: "[RFC7852] establishes a 
> general mechanism for attaching blocks of

If you look seven paragraphs above the paragraph in question (same 
section), you'll see:

    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].

Then, three paragraphs later (four paragraphs above the paragraph in 
question) it uses "attach" again:

    An In-Vehicle System (IVS) initiating an NG-eCall attaches an MSD to
    the initial INVITE and optionally attaches a metadata/control object
    informing the PSAP of its capabilities.

The surrounding text makes it clear that these are "attached" as body 
parts in the SIP message.

>
>  However, RC7852 contains only one occurence of "attach" and that's 
> in Figure 6 (see below) and it seems to refer to anything else.
>
>   > >> > aligned with 
> <https://www.w3.org/TR/xmlschema-0/#schemaLocation> 
> https://www.w3.org/TR/xmlschema-0/#schemaLocation
> xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>http://www.w3.org/2001/XMLSchema-instance"
>   >
> xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>http://www.w3.org/2001/XMLSchema-instance" 
> is still in XML text examples and there is no usage of "xsi" prefix.
>
>
>
>  ISSUE 21:
>
>                  Request-URI of SIP INFO request in Figure 11 (INFO 
> urn:service:sos.ecall.automatic SIP/2.0) is incorrect.
>
>                  Reason: in in-dialog requests, the Request-URI is 
> set to the remote contact URI (in case of loose routing) or to the 
> most top route URI (in case of strict routing) - see rfc3261 
> section 12.2.1.1.
>
>                  The draft does NOT need so state how Request-URI in 
> SIP INFO request is set,  but the Request-URI of SIP INFO request 
> in Figure 11 needs to be corrected.
>
>  Kind regards
>
>  Ivo
>
>

-------------- Randomly selected tag: ---------------
I could never make out what those damned dots meant.
    --Lord Randolph Churchill, former Chancellor of the Exchequer,
      regarding decimal points