Re: [salud] WGLC of draft-ietf-salud-alert-info-urns-09

[Paul Kyzivat <[e-mail]>]

On 11/20/13 11:44 AM, Dale R. Worley wrote:
> [as chair]
>
> Given that we're having a WGLC, I'd like the authors of the draft to
> indicate their opinion of the -09 version on the Salud mailing list.
>
> So far, I've been the only one to comment at all.
>
> Dale
>

Sorry Dale. I just did another review and found a few editorial things:

Section 1.1:

    Another limitation of the current solution is that the referenced
    tones are tied to particular rendering.  It is not possible to
    provide semantic indications or names for rendering characteristics
    that signals the intent and allows the recipient UA to decide how to
    render the received information in an appropriate way.

s/signals/signal/
s/allows/allow/

Section 1.3:

    This specification uses a number of terms to refer to the roles
    involved in the use of alerting indications in SIP.  A "specifier"
    sends an "alerting indication" (one or more URNs in an Alert-Info
    header field) to a "renderer" which then "renders" a "signal" or
    "rendering" based on the indication to a human user.  A "category" is
    a characteristic whose "values" can be used to classify indications.

Reorder a sentence to make it clearer:

s/based on the indication to a human user/to a human user based on the 
indication/

Section 4:

       Registration date:  TBD

How is this to be filled in? Should there be instructions to the editor?

Section 7.2:

    The meaning of a <private-name> or an <alert-label> that is defined
    privately (because of a preceding <private-name>) is only fixed
    within the context provided by the sequence of preceding <alert-
    name>s; these components have no meaning in isolation and there is no
    necessary relationship between the meaning of textually identical
    <alert-name>s that are preceded by different sequences of <alert-
    name>s. .

Extra "." at the end of the paragraph.

Section 9.2:

The examples are a but hard to follow. Specifically, each example 
describes the signals at each source and the winner, but when doing so 
it never mentions which signals (Signal 1, Signal 2, ...) - it instead 
identifies by alert urn. Since to point is to determine the signal to be 
rendered, this seems obscure. For example the following would seem 
clearer to me for 9.2.1:

    If the device receives <urn:alert:source:internal>, then the sort is:

    Signals at source:internal: (this is, first place)

       Signal 2

    Signals at source: (tied for second place)

       Signal 3
       Signal 4
       Signal 5

    And these signals are excluded from the set:

       Signal 1

    So in this example, the sorting algorithm properly gives first place
    to Signal 2.

Section 10:

    A SIP UA MAY add a URN or multiple URNs to the Alert-Info header
    field in a SIP request or a provisional 1xx response (excepting a 100
    response) when it needs to provide additional information about the
    call or about the provided service.

The above only talks about adding *to* an Alert-Info, not the adding 
*of* an Alert-Info. I suggest:

    A SIP UA MAY include one or more Alert-Info header fields,
    containing one or more URNs in a SIP request or a provisional 1xx
    response (excepting a 100 response) when it needs to provide
    additional information about the call or about the provided service.

Section 11:

    A SIP proxy MAY add a URN or multiple URNs to the Alert-Info header
    field in a SIP request or a provisional 1xx response (excepting a 100
    response) when it needs to provide additional information about the
    call or about the provided service.

I think we would ideally allow a proxy to modify/remove URNs, but 3261 
doesn't permit that. But a proxy can get a similar effect by putting a 
counteracting URN earlier in the sequence. But it is also possible that 
there will be no Alert-Info and the proxy needs to add one. I suggest:

    A SIP proxy MAY add an Alert-Info header field if none is present,
    and MAY add or remove URNs to an Alert-Info header
    field in a SIP request or a provisional 1xx response (excepting a 100
    response) when it needs to provide additional information about the
    call or about the provided service.

	Thanks,
	Paul