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

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

[as an individual]

> From: Laura Liess <[e-mail]>
>
> I put my current understanding of the discussion outcome into the text
> modifications below. Please look at it and let me know your opinion.

These changes look very good to me (except for a few nits, which I
have noted below).  I recommend keeping section 4.2 with the wording
you've suggested, as it is a normative change to 3261, and we want to
list it as such.

> - Issue 4.1.  New text for 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."
> 
> - Issue 4.2 :
>      - New text for Section "Abstract", second paragraph:
> "This document normatively updates RFC 3261, which defines the Session
> Initiation
> Protocol (SIP): It changes the usage of the Alert-Info header field defined
> in RFC 3261 by additionally allowing its use in any non-100 provisional
> response to INVITE (except the 100 response).This document also permits
                     ^-----------------------^
This text is redundant and can be removed.
> proxies to add or remove an Alert-Info  header field, and to add or remove
> Alert-Info header field values."
> 
>      - It is not clear to me if we completly drop Section 4.2 or if we keep
> it with the new text:
> "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."
> 
>        - Section  14 "Proxy Behaviour". First paragraph is replaced by:
> 
> "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."
> 
> -  Issue "General":  New text at the end of Section 13 "User Agent
> Behaviour"
> 
> "Subsequent provisional responses, even within the same dialog, may    contain
> different Alert-Info header field values.  The Alert-Info header    field
> values received within different Provisional responses are treated
Put this word in lower case. ------^
> independently.  If subsequent provisional responses containing  different
> Alert-Info header field values were received within the same dialog, the
> User Agent should render at anytime the last received Alert-Info header
-------------^
I think we want "SHOULD" here.
> field value. The handling of provisional responses containing  different
> Alert-Info header field values which were not received within the same
> dialog is left as an implementation issue."

Dale