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

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

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

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

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

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

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.

Dale