Re: [salud] Review comments on draft-ietf-salud-alert-info-urns-13

Christer Holmberg <> Wed, 10 September 2014 14:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1AD3C1A0277 for <>; Wed, 10 Sep 2014 07:05:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RnB3eLmRm4ls for <>; Wed, 10 Sep 2014 07:05:34 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 17D901A00E9 for <>; Wed, 10 Sep 2014 07:05:32 -0700 (PDT)
X-AuditID: c1b4fb2d-f793d6d000005356-42-54105aa9ea35
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 86.3F.21334.9AA50145; Wed, 10 Sep 2014 16:05:29 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Wed, 10 Sep 2014 16:05:29 +0200
From: Christer Holmberg <>
To: Laura Liess <>
Thread-Topic: [salud] Review comments on draft-ietf-salud-alert-info-urns-13
Thread-Index: Ac/IFf+gMZjC49hSQeiq/vmrqzhpOAECnhIAAA0sVGIAJFGJAAAGdc21
Date: Wed, 10 Sep 2014 14:05:28 +0000
Message-ID: <>
References: <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-GB
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4425A3ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvje7KKIEQg+1/NS3mXDG0uNtxgNGB yePphMnsHkuW/GQKYIrisklJzcksSy3St0vgyvh9tbDgyhzGipc9h9kbGK91MnYxcnBICJhI rG7m7WLkBDLFJC7cW8/WxcjFISRwlFFi8crpjBDOEkaJLQ0TmEEa2AQsJLr/aYM0iAjoS5zo +8gOYjMLqErsvb2ECcQWFvCWWH7/DzNEjY/E7e1voWw3icP7d7OC2CxA9SdX/gWzeQV8JT6t ucgIYgsJzGWSeLo0FMTmFAiUuHzqENh8RqDjvp9awwSxS1yi6ctKVoijBSSW7DnPDGGLSrx8 /I8VoiZfYsvPoywQ8wUlTs58wjKBUWQWkvZZSMpmISmDiBtIfHl/G8rWlli28DUzhK0v0f3+ NBOy+AJG9lWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgVF1cMtv3R2Mq187HmIU4GBU4uFd sIE/RIg1say4MvcQozQHi5I476Jz84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MIpqRLjY tvaqJd19wjmL4aQ/f4r5441MV1On628zspj+7HHY0R3vfZ0fCW7xLVz4f2unhbvv047l5wwO f7t506PCxvGz2bXwovM5iv8rXQ55z32uY15X7GypUMIt7NZyVmXucrXZ7y5mzuK3UyhI3LE6 1/vkz+3v3jYl2/KtOsb3yK027vZqKyWW4oxEQy3mouJEAJmpqReLAgAA
Cc: "" <>
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: Wed, 10 Sep 2014 14:05:36 -0000

Hi Laura,

Regarding Q4-2_1, we need to say that proxies can remove the whole header field, not only header field values.



Sent from my Windows Phone
From: Laura Liess<>
Sent: ‎10/‎09/‎2014 16:00
To: Christer Holmberg<>
Subject: Re: [salud] Review comments on draft-ietf-salud-alert-info-urns-13

Hi Christer,

      > I don't find any text :)

Sorry for that. I just forgot to insert the text I put into the next draft version.
For Q4-1_1:

New text for the first paragraph of section 4.1:

"This specification changes the usage of the Alert-Info header field    defined in [RFC3261] by additionally allowing its use in any non-100    provisional response to INVITE."

For Q4-2_1:
New text for the first paragraph of section 4.1:

"Following text is added after the first paragraph of section 20.4 [RFC3261]:

A SIP proxy MAY add or remove header field values in an Alert-Info    header field in a SIP request or in any non-100 provisional response."

Thank you


2014-09-09 19:44 GMT+02:00 Christer Holmberg <<>>:

Hi Laura,

>Please find below the text changes according to your comments Q4-1_1  and Q4-2_1.  Is the text OK for you?

I don't find any text :)

> I am not sure what we should do concerning the comment QG_1.  IMO, usually RFCs do not mention all possible scenarios or use cases which may occur. The content of an Alert-Info
> applies just to the message, there is no text saying in any way that the content of the Alert-Info applies to a dialog or transaction.
> Additionaly, if we add text and mention these use cases, I think people will ask for concrete examples, then for message flows and so on, so that finishing the draft will take another year...
> There is also nothing we can do here for a UA receiving different Alert-Info in two non-100 provisional reasponses, we have no rules on how the UA has to handle them, this is implementation dependent anyway.
> So, my personal opinion is to leave this out.

I think a simple note, saying that depending on the use-case/service, subsequent non-100 provisional responses might contain different values. Otherwise I am pretty sure that people, sooner or later, will argue whether it is allowed or not...





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.

Eventhough 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.


Section 4.1:


                This is pure editorial, but for alignment purpose I suggest to change “in all provisional responses…” to “in any non-100 provisional response…”


Section 4.2:


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?




salud mailing list<>