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

[Laura Liess <[e-mail]>]

Dale, Paul,

thank you for the comments. I am already working on the 10-th version, to
incorporate your comments. It may take some time because I am very busy
till the end of this year. Maybe I will come back with questions if I have
problems  with the comments.

Please let me know what you think about following changes I did for the
10-th version:
- I moved the "Requirements Language"  section to further down. It has the
number 1.4.

- I changed the titles according to Dale's comment and capitalized all
important words. I left words within <...> and  "alert" witout capital
letter, excepting when they are at the beginning if a title or of a
sentance.

Thank you
Laura



2013/11/21 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
> _______________________________________________
> salud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/salud
>