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

[Randall Gellens <[e-mail]>]

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

>  (ISSUE 21 reformulated)
>
>  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.
>
>  On:
>
>   > >>  >  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".
>   > >
>   > >  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.
>   >
>   > 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."

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.
>
>                    +-----------+----------------------------+
>                    | 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.
>
>   > >>  >
>   > >>  >  ISSUE 20
>   > >>  >
>   > >>  >  examples contain a value of schemaLocation parameter which is not
>   > >> > aligned with 
> <https://www.w3.org/TR/xmlschema-0/#schemaLocation> 
> 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.
>   > >
>   > >  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>http://www.w3.org/2001/XMLSchema-instance"
>   >
>   > 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>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
>
>


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I could never make out what those damned dots meant.
    --Lord Randolph Churchill, former Chancellor of the Exchequer,
      regarding decimal points