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

[[e-mail] (Dale R. Worley)]

Many thanks for your review!

My apologies for not tending to this earlier.

> From: Christer Holmberg <[e-mail]>

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

Dale