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

[Christer Holmberg <[e-mail]>]

Hi,

>>>> 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.
>>>
>>> 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?
>
> There are interesting complications.  Certainly if you can tell that the 180 is the successor of the 181 on the same branch of the call, then performing 
> only the rendering for the 180 makes sense.  And you may be able to tell that the 180 is the successor of the 181, perhaps by looking at the tags or the History-Info.
>
> But if the call forks, it could make sense to audio-mix the renderings for the two 180s that you receive.  That seems to be how situations in the PSTN work if two destination telephone systems deal with the call simultaneously.
>
> If you have a visual display, and the renderings are text fragments, simply listing "forarding" for the 181, followed by "ringing" for the 180, may be useful for the user.
>
>> 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...
>
> The critical thing is "choose among or combine *these renderings*".
> That is, each set of Alert-Infos is turned into a rendering, and then in a second step, the UA "chooses among or combines" them.  An Alert-Info URN in one response cannot interact (*as a URN*) with one in another response.
>
> I suspect that there is room for experimentation and development in developing good logic for handling multiple responses.  My goal with that text is to allow freedom for the UA 
> designers.  The only rules are (1) the URNs in different responses don't interact *as URNs*, but only by some sort of interaction between the renderings that they specify, and (2) later 
> information is "prefered" relative to earlier information.  That second rule is a hint that in many cases, the later information does supersede the former information.

Perhaps we could say that, within a given dialog, a subsequent URN disables the previous.

Then, in the case of forking, we leave it open, and simply say that it is an implementation issue how URNs received on different dialogs are treated, and how/if they interact.




> From: Laura Liess <[e-mail]>
> > From: [e-mail] (Dale R. Worley)
> > > From: Christer Holmberg <[e-mail]>
> 
> > > 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.
>
> 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."

Which is essentially the same as my version, so we're all agreed on that.



>>>> 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?
>>> 
>>> 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?
>>
>> Looking at 3325 and 3329, there are a number of places where they specify header fields to be removed, and neither of them provides indication of what parts of 3261 are being amended thereby.

That's my point: we could say that a proxy can remove the Alert-Info header field - without saying anything about updating 3261 :)



>>> 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.
>> 
>> From: Laura Liess <[e-mail]>
>> 
>> "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."
>
> If the issue is "This section is below the "Updates to RFC 3261"
> section, but it is unclear exactly what is updated.", the answer is "What is being updated is the rules in section 16.6 and 16.7 regarding how proxies 
> forward requests and responses."  And it would seem to be to be a proper answer to insert that sentence in section 4.2.
>
> As Christer notes, previous RFCs don't specify "what is updated" at all.
>
> If the issue is "I want to see the section stated in the form of a textual amendment to RFC 3261." then Laura's change seems to be a good 
> one, as any attempt to track down all statements regarding Alert-Info will find it.  And it does not involve textually editing the words of 
> sections 16.6 and 16.7, which would be quite unpleasant -- but just as above, it requires the reader to semantically combine the amendment 
> with the original rules of 16.6 and 16.7.
>
> Christer, if you think Laura's text works, why don't we go with that?
>
>Repeating:
> Don't you mean "add or remove an Alert-Info header field"?
>
> The assumption has been that an Alert-Info header field is just a way of carrying Alert-Info header field values, so removing the last value automatically 
> removes the last header field (as a header field with no values is not allowed syntactically).
> And if there are no Alert-Info header fields, adding one value will create the header field as well as creating the header field value.

True. But, at least RFC 3329 explicitly says that, if the last header field value (in the case of 3329, option-tags in Require/Proxy-Require) is removed, then the header field itself is also removed. I don't think it would hurt to explicitly say that also in this draft - at least as a note. 


> Ugh, one problem is that our terminology doesn't perfectly match that of 3261, and 3261 is not completely consistent.  In most of 3261, there is one, unique 
> Alert-Info "header field", which consists of "header field rows" (each of which is what is ordinarily called a "header"), with each row containing one or more values.  The relevant texts are:
>
>      Header Field: A header field is a component of the SIP message
>         header.  A header field can appear as one or more header field
>         rows. Header field rows consist of a header field name and zero
>         or more header field values. Multiple header field values on a
>         given header field row are separated by commas. Some header
>         fields can only have a single header field value, and as a
>         result, always appear as a single header field row.
>
>   [H4.2] also specifies that multiple header fields of the same field
>   name whose value is a comma-separated list can be combined into one
>   header field.  [Note this isn't consistent with the above definition!]
>
>   Multiple header field rows with the same field-name MAY be present in
>   a message if and only if the entire field-value for that header field
>   is defined as a comma-separated list (that is, if follows the grammar
>   defined in Section 7.3).  It MUST be possible to combine the multiple
>   header field rows into one "field-name: field-value" pair, without
>   changing the semantics of the message, by appending each subsequent
>   field-value to the first, each separated by a comma.
>
> The texts in the draft that deal with this are as follows.  They are not completely parallel to each other.
>
>   Abstract
>
>   This document also permits proxies to add and remove header field
>   values from the Alert-Info header field.
>
>   4.2.  Proxies May Alter Alert-Info Header Fields
>
>   A SIP proxy MAY add or remove header field values in an Alert-Info
>   header field in a SIP request or a provisional 1xx response
>   (excepting a 100 response).
>
>   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.
>
> Let me propose that we use this phrase, which I think covers all the possibilities and works with either definition of "header field":
>
>   a SIP proxy MAY add or remove an Alert-Info header field, and MAY
>   add or remove Alert-Info header field values
>
>
> That would amend the draft to read:
>
>   Abstract
>
>   This document also permits proxies to add or remove an Alert-Info
>   header field, and to add or remove Alert-Info header field values.
>
>   4.2.  Proxies May Alter Alert-Info Header Fields
>
>   A SIP proxy MAY add or remove an Alert-Info header field, and MAY
>   add or remove Alert-Info header field values, in a SIP request or a
>   non-100 provisional response.
>
>   14.  Proxy Behaviour
>
>   A SIP proxy MAY add or remove an Alert-Info header field, and MAY
>   add or remove Alert-Info header field values, in a SIP request or a
>   non-100 provisional response when it needs to modify the
>   information about the call or about the provided services.

I still don't think we need 4.2, as there is no similar text in other RFCs allowing the removal of header field/header field values (perhaps SIPCORE should make a generic update of 3261, and allow specifications of individual header fields ti define whether a header field can be removed by proxies.)

BUT, if I am the only one having that opinion, I will rest my case in order not to delay the draft :)

Regards,

Christer