Subject: Re: [Ecrit] WGLC Announce: draft-ietf-ecrit-data-only-ea - WGLC comments from Christer

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Nov 2014 14:43:21 +0000

Hi,

Some comments from me, to get the discussions going :)

Regards,

Christer

General
-----------

Q1: Title & Scope

I think this was already discussed before, but I think we should make it more clear that the document describes a "session-free" mechanism.

The text does say that a MESSAGE doesn't create a session, but I think we need some additional stuff:

1)      I think it should be seen in the title. E.g. "Non-Session Data-Only Emergency Calls" or "One-Shot Data-Only Emergency Calls".

2)      It should be more clear that the mechanism is aimed at "single shot" cases only, because there is no guarantee that additional MESSAGE requests would end up at the same location - nor does the draft define any mechanism on how to associated multiple MESSAGE requests with the same "call". There is some text about it in section 4.1, but below I will suggest some text also for the Introduction section.

Q2: SIP Terminology

Throughout the document, please s/header/header field        <- When you talk about SIP header fields, that is

Q3: Terminology alignment

The terminology needs to be consistent regarding SIP responses. Sometimes the text says "425 response", sometimes "425", and sometimes "500 (Server Internal Error)".

I suggest to use the "500 (Server Internal Error)" format - both when talking about responses and when talking about response codes.

Abstract:
------------

Q4:

            s/ "and its transmission using the SIP MESSAGE"/ "and its transmission using SIP MESSAGE requests"

Introduction:
-----------------

Q5:

I suggest to modify:

        This document also describes how a SIP MESSAGE
        [RFC3428] transaction can be used to send a data-only call.

...to:

        This document also describes how a SIP MESSAGE

        [RFC3428] request can be used to send a one-shot

        data-only call, meaning that all data associated

        with the call is sent in a single request.

        NOTE: SIP MESSAGE is not suitable for data-only

        Calls which require the sending of multiple requests.

        There is no guarantee that each SIP MESSAGE request

        will reach traverse the same path and reach the same

        destination. Nor is there a SIP-layer mechanism to

        associate multiple SIP MESSAGE requests with a given

        call.

Section 4.1:
---------------

Q6:

            The first sentence says:

            "A CAP message may be sent on the initial message of any SIP transaction."

            I don't understand what "initial message of a SIP transaction" means.

Q7:

            The text says:

            "However, this document only describes specific behavior
            when used with a SIP INVITE that would accompany a normal emergency
            call and a SIP MESSAGE transaction for a one-shot, data-only
            emergency call.  Behavior with other transactions is not defined."

            I suggest the following modified text:

            "However, this document only describes the transport of CAP messages
            within SIP INVITE requests, when an emergency SIP session is established,
            and within SIP MESSAGE requests, for one-shot data-only emergency calls.

            The transport of CAP messages within other type of SIP messages is outside
            the scope of this specification."

Q8:

            Related to that, throughout the document, I think it would be good to talk
            about "SIP requests" rather than "SIP messages".

Section 4.3:
---------------

Q9:

            I suggest to change the title to "Sending of an one-shot data emergency call".

Q10:

            Related to Q9, the wording "sending a call" sounds a little strange. Couldn't we simply
            talk about "sending of a message"?

Q11:

            I suggest to add some text which states that a SIP MESSAGE may fork, but that the sender will only receive one 200 OK response (according to the 3261 rules for non-INVITE requests). I.e. the sender will not know how many recipients received the MESSAGE.

Section 4.x:
---------------

Q12:

            As you have a section for the one-shot call, I think you should also have a section which describes
            INVITE specific aspects.

Section 5.1.
-----------------

Q13:

            The text says:

                    "The 425 response code is a rejection of the request due to its
        included alert content, indicating that it was malformed or not
        satisfactory for the recipient's purpose."

            I suggest the following modified text:

                    "The recipient sends a 425 response if it considers the alerting content to be

                    malformed or not satisfactory for the recipient's purpose."

Q14:

            The text says:

        "A SIP intermediary can also reject an alert it receives from a UA
        when it understands that the provided alert is malformed."

            I suggest the following modified text:

        "A SIP intermediary can also reject a request, if it considers the

        Included alert content malformed."

Q15:

            The text says:

            "It is only appropriate to generate a 425 response when the responding
            entity has no other information in the request that are usable by the
            responder."

            I don't understand this. Above it is said that 425 is used if the alerting content is not usable, and now
            you say that the recipient should also check other information.

            Perhaps you could REMOVE this sentence, and enhance the sentence in Q11:

                    "The recipient sends a 425 response if it considers the alerting content to be

                    malformed or not satisfactory for the recipient's purpose, and if the request

                    does not contain other information sufficient for emergency purpose."

                    ...or something like that.

Q16:

The text says:

        "A 425 response is a final response within a transaction, and MUST NOT

        terminate an existing dialog."

What does that mean??? A 4xx response DOES terminate a dialog.

Section 5.2
--------------

Q17:

            I have never seen a SIP header field name before, where a capital letter is used within a word. Keep in mind that SIP header fields are case-insensitive.

Regards,

Christer

From: Ecrit [mailto:[email-masked]] On Behalf Of Roger Marshall
Sent: 1. marraskuuta 2014 0:26
To: [email-masked]
Cc: Rosen, Brian ([email-masked])
Subject: [Ecrit] WGLC Announce: draft-ietf-ecrit-data-only-ea

This starts WGLC for draft-ietf-ecrit-data-only-ea, Data-Only Emergency Calls.

The draft can be found at:
http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/

Please review the draft and provide comments to the list before our ECRIT meeting in Honolulu, in just about 2 weeks.

Thanks,

Marc & Roger

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.