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

Laura Liess <laura.liess.dt@googlemail.com> Thu, 21 November 2013 13:10 UTC

Return-Path: <laura.liess.dt@googlemail.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8E91ADF73 for <salud@ietfa.amsl.com>; Thu, 21 Nov 2013 05:10:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.777
X-Spam-Level:
X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zm8ipCoDevdF for <salud@ietfa.amsl.com>; Thu, 21 Nov 2013 05:10:36 -0800 (PST)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id DCDEF1ADF57 for <salud@ietf.org>; Thu, 21 Nov 2013 05:10:35 -0800 (PST)
Received: by mail-lb0-f177.google.com with SMTP id w7so4649972lbi.22 for <salud@ietf.org>; Thu, 21 Nov 2013 05:10:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cXzdMVqNuQ3Z2Z38nACfs7g6iYDRS3/zgH/rQoFmnCs=; b=dPlD006ijnt7T7JiZi8cME36OTgoFTS5AncMgXOK70NyvC8BoZowr/VSEgilhiFu+s jeuQZOPPZC1rMrQ02wFHFWTV/+CwGWxd1aDmXWCCX7UxnGY7PKJ6seGyvOECqOsDx8lc yg0jiwNaIIySI7VktG2zz7o5bk+z/uQSY9/rtzzjCgv/RUsTxGntLtU1nOMXs9vlUPBq zL8wqiWTvl599fIk5GBPfHld3rUlR/4zafm76ZP1XJ1ZY9qUWEGe+1Mnorp1HAw4SZh3 J5n1qwi3yumwp5Xz0CySbKgqtC5iaAr213YuXKc93Jmvy8ps2uChKO7u0DrRP19UWV5w J8tw==
MIME-Version: 1.0
X-Received: by 10.112.13.72 with SMTP id f8mr1271174lbc.40.1385039428486; Thu, 21 Nov 2013 05:10:28 -0800 (PST)
Received: by 10.114.77.198 with HTTP; Thu, 21 Nov 2013 05:10:28 -0800 (PST)
In-Reply-To: <528D41F2.8090200@alum.mit.edu>
References: <201311201944.rAKJiS7d5355422@shell01.TheWorld.com> <528D41F2.8090200@alum.mit.edu>
Date: Thu, 21 Nov 2013 14:10:28 +0100
Message-ID: <CACWXZj1__2cXwBp4nSiSguF4DatBZrsa+aycYj90+LUVSif_5Q@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary=001a11c3ee6a2289a904ebaf9fd5
Cc: "salud@ietf.org" <salud@ietf.org>
Subject: Re: [salud] WGLC of draft-ietf-salud-alert-info-urns-09
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list <salud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/salud>, <mailto:salud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/salud/>
List-Post: <mailto:salud@ietf.org>
List-Help: <mailto:salud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/salud>, <mailto:salud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Nov 2013 13:10:39 -0000

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 <pkyzivat@alum.mit.edu>

> 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
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>