Re: [salud] Review comments on draft-ietf-salud-alert-info-urns-13 (Dale R. Worley) Tue, 09 September 2014 20:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 17AB81A0172 for <>; Tue, 9 Sep 2014 13:32:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y1HlR-NDeuSh for <>; Tue, 9 Sep 2014 13:32:40 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:96]) by (Postfix) with ESMTP id 144F41A0149 for <>; Tue, 9 Sep 2014 13:32:39 -0700 (PDT)
Received: from ([]) by with comcast id p85S1o0040mv7h0598Yf2y; Tue, 09 Sep 2014 20:32:39 +0000
Received: from ([]) by with comcast id p8Ye1o00b1KKtkw3X8YfVZ; Tue, 09 Sep 2014 20:32:39 +0000
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id s89KWc2d028511; Tue, 9 Sep 2014 16:32:38 -0400
Received: (from worley@localhost) by (8.14.7/8.14.7/Submit) id s89KWcma028510; Tue, 9 Sep 2014 16:32:38 -0400
Date: Tue, 9 Sep 2014 16:32:38 -0400
Message-Id: <>
From: (Dale R. Worley)
Sender: (Dale R. Worley)
To: Christer Holmberg <>
In-reply-to: <> (
References: <>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1410294759; bh=Mt0OlGO9YvgWYcKXQwqXi66MiO1SEflBD+znyFanR18=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=IBmZVsm/AJiOoY9mFh68OJpCz061eb5b1P0B5dEl735xrtfFO4tj3TfqbDgDF9kJx S0FnsFax4XjW++0k1+h83QyhgUKJHqJ3qRL9yyL/erfs5ED+hgzv76kfPycsJ3jy05 lgcmeC4ckSTFt/Mhy0+ubvR1vMavQ/opPs/MngNJVo1kqfBiQ3OCgUMx2/9gF36T02 vDMQklkKKS9H7ypHjiMUbKj0LK940eEmoPGv3HpTLhdpb2DaTz5K4b1usMDPWb09i6 1eqBNnPb1jalowpZ+SiswtFiNW8tbs31XwVDOAXsFNRn65AlrkxE0j9YTrZTjmsqHt ThE42Vj3WDbUg==
Subject: Re: [salud] Review comments on draft-ietf-salud-alert-info-urns-13
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: Tue, 09 Sep 2014 20:32:42 -0000

Many thanks for your review!

My apologies for not tending to this earlier.

> From: Christer Holmberg <>

> <QG_1>
> As it is now allowed to use the Alert-Info header field in any
> non-100 provisional response, I assume the value could actually
> change from one response to another.
> Even though RFC3261 does not explicitly forbid it, perhaps it would
> be good to explicitly mention that in this draft, because I assume
> there could be use cases where e.g. one value is received in a 181,
> and another value in a subsequent 180.

I can easily see use cases where different values are received in
different provisional responses, even when they come from (or on
behalf of) the same UAS.  For instance, a 181 (Ringing) with one alert
signal may be followed by 181 (Call Is Being Forwarded) with an alert
signal specifying call forwarding.

As you say, this is allowed already.  But since Alert-Info hasn't been
*used* before, people might overlook this possibility.

It seems to me that the best place to insert this would be at the end
of section 13, where we are stating the rules for UAs regarding
rendering Alert-Info.  We could add a paragraph at the end:

    Different provisional responses (even within one early dialog) may
    have different Alert-Info header field values.  Each Alert-Info header
    field value specifies a rendering independently of all other
    provisional responses.  The User Agent must choose among or combine
    these renderings.  It SHOULD prefer renderings derived from
    provisional responses that are received later in time over those that
    are received earlier.

> Section 4.1:
> ---------------
> <Q4-1_1>
> This is pure editorial, but for alignment purpose I suggest to
> change "in all provisional responses..." to "in any non-100
> provisional response..."

I believe the text you are referring to is:

   It changes the usage of the Alert-Info header field defined in RFC
   3261 by additionally allowing its use in all provisional responses
   to INVITE (except the 100 response).

I think you mean to revise it to:

   It changes the usage of the Alert-Info header field defined in RFC
   3261 by additionally allowing its use in all non-100 provisional
   responses to INVITE.

I agree that the latter reads better.

> Section 4.2:
> ---------------
> <Q4-2_1>
> This section is below the "Updates to RFC 3261" section, but it is
> unclear exactly what is updated.
> The first paragraph of section 20.4/RFC 3261 already says that a
> proxy can insert a A-I header. If you want to explicitly say that a
> proxy can also modify an existing header, shouldn't that be text
> that you add to e.g. the same paragraph?

The problem is that it is actually a modification to the rules
governing proxies, forwarding requests (section 16.6 item 1) and
forwarding responses (section 16.7 item 9), both of which forbid
*removing* header field values (except Via in responses).

The text of 20.4 allows a proxy to *insert* Alert-Info.  That can be
done already in requests but needs special permission in responses.
But removing header fields is specifically forbidden in 16.6 and 16.7.
So we're being more aggressive than what 20.4 already is doing.

Given how long and complicated those sections are, it's rather awkward
to edit the change into those sections textually.

But I can see the value of pointing out what specifically is changed.
Perhaps this would suffice?  (I am also including the wording change
you suggest in the second item, because it seems to apply to this item
as well.)

   4.2.  Proxies May Alter Alert-Info Header Fields

   Sections 16.6 and 16.7 are modified so that when forwarding a SIP
   request or a non-100 provisional 1xx response, a SIP proxy MAY add
   or remove header field values in an Alert-Info header field.