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

[Christer Holmberg <[e-mail]>]

Hi,


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

I was actually assuming that, when you receive a new Alert-Info, you would "disable" whatever rendering the previous triggered.

For example, if I receive a 181 with a call-forwarding-urn, and later a 180 with a called-party-alerting-urn, why would I keep rendering the call-fowarding-urn?

If you say "choose among or combine", how do you know that the UA will behave as you expect? We would need to define how different urns interact with each other, and I don't think we want to go down that path...


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

Correct.

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

I hear what you are saying.

However, I think we have already broken those rules in the past. For example, RFC 3325 specifies that a proxy can remove a P-Preferred-Identity header field, and that RFC does not update RFC 3261.

Also, RFC 3329 specifies that a proxy can remove the Require and Proxy-Require header field, after it has removed the security option-tags, and there are no option-tags left.

So, while the fact that we have done something in the past doesn't automatically justify us to do it again, I just wonder whether it would be the end of the world?


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

Don't you mean "add or remove an Alert-Info header field"?

Also, I think you could remove "1xx", and say "non-100 provisional response".

I don't have any strong preference, as long as it is clear what we update. But, perhaps we should ask the SIPCORE folks (that's mostly us :) whether we really would need to go down the path and update sections 16.6 and 16.7, or whether we e.g. in section 20.4 could simply say that a proxy can remove the header field.

Regards,

Christer