Re: [salud] Combined draft revision

Paul Kyzivat <> Wed, 09 July 2014 22:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 40B011A0065 for <>; Wed, 9 Jul 2014 15:38:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a1eFXNyW48qw for <>; Wed, 9 Jul 2014 15:38:42 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:44:76:96:59:243]) by (Postfix) with ESMTP id 2809F1A0023 for <>; Wed, 9 Jul 2014 15:38:41 -0700 (PDT)
Received: from ([]) by with comcast id QLnr1o0011wpRvQ5DNeh6U; Wed, 09 Jul 2014 22:38:41 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id QNeg1o00H3ZTu2S3eNehsF; Wed, 09 Jul 2014 22:38:41 +0000
Message-ID: <>
Date: Wed, 09 Jul 2014 18:38:40 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Dale R. Worley" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1404945521; bh=c8M6Oe3cuK3gHUcQ5r4wPkl1C7KF2MfAvVR8SLQY3kw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=O3C0KGHspZ6Xo710Ur/pdao8pR6gcxXFAtD2Qdtdjl7i44n8k1M3q/x6DzhvmS3L8 C/RVwJGa9zo9PL7Xq/6ZxkVw5lKVXM5/BOuiQLORyhavIFIeKyE24ZeY1i+e72Fbmz iW72JqmLtZzgFMZ408A2TnkwlbrXofriFSWNiwzyJ4kJViqFOTgFc/Jqf9O100vY17 CItdcvfmWRC+LGdUrLc+piSswDZ4wK7yOvrS1SgJLkK4QqKafJh60Jq01QM3rnE9bA qiFTbceR/Sm7mfzY3OoQs5ccaWQI2B/e5+lB7RTobrxjPbnmYmRWE0BCuPD1gs4TFl 2ilC5SuXU0A3w==
Subject: Re: [salud] Combined draft revision
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Jul 2014 22:38:43 -0000

This all sounds good. Unfortunately you can't submit it until the 
meeting begins. This is a really silly restriction when the wg isn't 
even meeting.

Maybe the ADs would override and allow it to be submitted.

Unfortunately, I think this really needs another WGLC. :-)


On 7/9/14 2:17 PM, Dale R. Worley wrote:
>> From: Paul Kyzivat <>
>> Section 10.1 says:
>>      Extensions, either standard or private, MUST conform to the
>>      following principles:
>> This is certainly right for standard extensions. The expert reviewer
>> enforces this. For private extensions, can we be normative? We want to
>> be, but is that imposing constraints on people rather than code?
> We're imposing a constraint on the URNs that go over the wire and
> their meanings, but it is people who create URNs.
> We had a similar situation in the -12 version, where less-explicit
> principles were stated that implicitly applied to private extensions.
>> I noticed a misspelling in here. s/altert/alert/
> I just ran a spell checker over it.  There is also
> s/availiable/available/.  I've checked in that change as part of
> -update4.
> I have also just added a paragraph to section 14, "Proxy Behaviour",
> to explain *why* a proxy would want to modify Alert-Info.  I think all
> of the examples I list are in the draft already in other places, so
> this is just a writing change:
>     14.  Proxy Behaviour
>     A SIP proxy MAY add an Alert-Info header field if none is present,
>     and MAY add or remove header field values of an Alert-Info header
>     field in a SIP request or a provisional 1xx response (excepting a 100
>     response) when it needs to modify the information about the call or
>     about the provided services.
> +  There are many reasons a proxy may choose do this.  For example: (1)
> +  to add indications based on information that the proxy can determine
> +  about the call, such as that it is coming from an external source, or
> +  that the INVITE contains a "Priority: urgent" header field; (2) to
> +  add indication that a particular service is being invoked at this end
> +  of the call; (3) to remove undesirable indications, such as possibly
> +  deceptive indications from untrusted sources; and (4) to remove
> +  indications that contain information that should be suppressed for
> +  privacy reasons.
>     The following example shows a typical example of a 180 (Ringing)
>     ...
> Some changes in -update4 that I'd like to mention:
> I've reformatted the following text in the Introduction.  But I've
> also replaced "normal" with "external" wherever it appears, because
> the previous examples all used "normal" in the Alert-Info URLs.  I
> assume that these examples do not have to match the behavior of any
> real product, so we can adjust the examples to improve clarity.
>     The issues with URLs that reference audio files can be avoided by
>     using fixed URLs with specific meanings.  However this approach has
>     its own interoperability issues.  For example, consider the PBX
>     special ring tone for an external (to the PBX) caller.  Different
>     vendors use different approaches such as:
>        Alert-Info: <file://ring.pcm>;alert=external
>     where ring.pcm is a dummy file name, or:
>        Alert-Info: <file://external.ring.pcm>
>        Alert-Info: <>
>     As a result, the Alert-Info header field currently only works when
>     the same vendor provides PBX and UA, and only then if the same
>     artificial proprietary URI convention used.
> Now that we've added a subsection to section 4 ("Updates to RFC 3261")
> to state "Proxies May Alter Alert-Info Header Fields", I've
> reformatted it into two subsections, one for each normative change.
> Since Christer was particularly interested in stating the normative
> changes, he should check whether this is done well.
> In the Requirements, there are two uses of the sentence "Use cases and
> values definition are not a subject of this specification."  In
> previous versions, the sentence ends "... are not subject of this
> specification".  The usual way to say this in RFCs is the awkward
> phrase "... is outside the scope of this specification".
> Unfortunately this use of "subject" isn't within the dictionary
> meaning of "subject" -- I suspect it is a direct translation of a
> German expression (which is much clearer than the English "outside the
> scope").  I've added the word "a" to turn this into "Use cases and
> values definition are not a subject of this specification."  This
> isn't quite as nice as using "subject" as a verb, but it's correct
> according to the dictionary and reads smoothly.  I would like to see
> this become the conventional way of expressing this meaning in RFCs.
> The English modifier "more than one" must be followed by a singular
> noun.  That is actually quite peculiar, because the *meaning* is
> necessarily plural.
> Dale