Re: [salud] Combined draft revision

worley@ariadne.com (Dale R. Worley) Wed, 09 July 2014 18:18 UTC

Return-Path: <worley@ariadne.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 17F751A038F for <salud@ietfa.amsl.com>; Wed, 9 Jul 2014 11:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 VHm9gNMxLqoQ for <salud@ietfa.amsl.com>; Wed, 9 Jul 2014 11:18:00 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id E3AFB1A0B07 for <salud@ietf.org>; Wed, 9 Jul 2014 11:17:59 -0700 (PDT)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta02.westchester.pa.mail.comcast.net with comcast id QHGm1o0011vXlb851JHzXq; Wed, 09 Jul 2014 18:17:59 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta17.westchester.pa.mail.comcast.net with comcast id QJHz1o0071KKtkw3dJHzyW; Wed, 09 Jul 2014 18:17:59 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s69IHwUf029595; Wed, 9 Jul 2014 14:17:58 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s69IHwiJ029594; Wed, 9 Jul 2014 14:17:58 -0400
Date: Wed, 9 Jul 2014 14:17:58 -0400
Message-Id: <201407091817.s69IHwiJ029594@hobgoblin.ariadne.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
In-reply-to: <53BC6DB5.4070103@alum.mit.edu> (pkyzivat@alum.mit.edu)
References: <201407082031.s68KV3vr020822@hobgoblin.ariadne.com> <53BC6DB5.4070103@alum.mit.edu>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1404929879; bh=jWAjsdvwlnjVrzq4uZB5VJT94wTHQCaD1iXTp6R9MIY=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=RJYTJTHOoxhU+to8KlPjxMzICEOKH/iLWtHaYjrPPZojnu2h6xLeM6tfpfxU5TH+v BxFOrbdVwSBLhH/V+i8CbdmqH0N8MlQSqAIQtfUsqVBrIFp9BGpghMB5FfkUzgCwRK ituHekuLViDSacmwbws+oodgISB0wyafRi98wXoy8J6yF8VulPzGj34CDPBHLESele q/tklDQlz15i5fzsXzflHjm5KLEVOjZE33ybPU0J6ZeNCt9Rt855MyukvGPTLCm3tX JMNEgdEC3bCT5QM76HhP+8MweLPGuKQ7Wn5107rCYOKFj0uOm/ZnHH8uYAlaSuiHED U9bcDlAiztZ4A==
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/VflMmbJh6RC5kXM6DQV4Ca5aM40
Cc: salud@ietf.org
Subject: Re: [salud] Combined draft revision
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, 09 Jul 2014 18:18:02 -0000

> From: Paul Kyzivat <pkyzivat@alum.mit.edu>

> 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: <sip:external-ringtone@example.com>

   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