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

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 20 November 2013 23:13 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 BB8041AE071 for <salud@ietfa.amsl.com>; Wed, 20 Nov 2013 15:13:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.635
X-Spam-Level:
X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_41=0.6, SPF_SOFTFAIL=0.665] autolearn=no
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 3SeyZGX7FJWb for <salud@ietfa.amsl.com>; Wed, 20 Nov 2013 15:13:10 -0800 (PST)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id ECF151AE1C7 for <salud@ietf.org>; Wed, 20 Nov 2013 15:12:57 -0800 (PST)
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta14.westchester.pa.mail.comcast.net with comcast id rpLG1m0041c6gX85EzCrTa; Wed, 20 Nov 2013 23:12:51 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id rzCr1m0033ZTu2S3jzCr04; Wed, 20 Nov 2013 23:12:51 +0000
Message-ID: <528D41F2.8090200@alum.mit.edu>
Date: Wed, 20 Nov 2013 15:12:50 -0800
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "Dale R. Worley" <worley@ariadne.com>
References: <201311201944.rAKJiS7d5355422@shell01.TheWorld.com>
In-Reply-To: <201311201944.rAKJiS7d5355422@shell01.TheWorld.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1384989171; bh=+fbgCp5ZFE6WPcGLQqxoHKImxAoMNapHwXIBgyyKPwU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=g04riAf6P3QtUw2MadBKMgCyvEdAGAS38fXbqvig6kHi3sFRxFI1ce9d9ZbJkaWYp sp5J4lTxT4nmrkhfl0pHpXzfzRv9C/7+hAaQnQTuDFPI+k/dEsDN3UVqFAsLkINBoc 2diisrjiIUtSA3RwDRjYo1nQQurarVeQh5kJtag7nwX9gyQC06I5sGrWpliJapzfy5 dIgqNupaazBSVcNKvUP4qKIQzUevzZmLwyazdTTr8st6UFUkMurAMO8Lfi4WmuBrCd opryzuxtlix2+zWHhs5Tj28Mvr9HK8606+JWagTlFWjX7CqliK9bKSai6npVxOFkcg TVQ6Nm7EmIM+Q==
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: Wed, 20 Nov 2013 23:13:11 -0000

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