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

[Ivo Sedlacek <[e-mail]>]

(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."



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

> >>  > 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"

>

> 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:



                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