Re: [salud] WGLC of draft-ietf-salud-alert-info-urns-09

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

I've been neglecting Salud...

> Date: Wed, 20 Nov 2013 15:12:50 -0800
> From: Paul Kyzivat <[e-mail]>

My comments on items in this message.  (The other items I agree with.)

> Section 4:
>
>        Registration date:  TBD
> 
> How is this to be filled in? Should there be instructions to the editor?

The common method (e.g., draft-cardona-cablelabs-urn-02.txt) seems to
be:

        Registration date: YYYY-MM-DD [RFC Editor: Please replace YYYY-
        MM-DD with the publication date of this RFC.]

> Section 9.2:
> 
> The examples are a [bit] hard to follow. Specifically, each example 
> describes the signals at each source and the winner, but when doing so 
> it never mentions which signals (Signal 1, Signal 2, ...) - it instead 
> identifies by alert urn. Since to point is to determine the signal to be 
> rendered, this seems obscure. For example the following would seem 
> clearer to me for 9.2.1:
> 
>     If the device receives <urn:alert:source:internal>, then the sort is:
> 
>     Signals at source:internal: (this is, first place)
> 
>        Signal 2
> 
>     Signals at source: (tied for second place)
> 
>        Signal 3
>        Signal 4
>        Signal 5
> 
>     And these signals are excluded from the set:
> 
>        Signal 1
> 
>     So in this example, the sorting algorithm properly gives first place
>     to Signal 2.

Yes, you're right there.  I'll rewrite that section and send it in
another message.

> Section 10:
> 
>     A SIP UA MAY add a URN or multiple URNs to the Alert-Info header
>     field in a SIP request or a provisional 1xx response (excepting a 100
>     response) when it needs to provide additional information about the
>     call or about the provided service.
> 
> The above only talks about adding *to* an Alert-Info, not the adding 
> *of* an Alert-Info. I suggest:
> 
>     A SIP UA MAY include one or more Alert-Info header fields,
>     containing one or more URNs in a SIP request or a provisional 1xx
>     response (excepting a 100 response) when it needs to provide
>     additional information about the call or about the provided service.
> 
> Section 11:
> 
>     A SIP proxy MAY add a URN or multiple URNs to the Alert-Info header
>     field in a SIP request or a provisional 1xx response (excepting a 100
>     response) when it needs to provide additional information about the
>     call or about the provided service.
> 
> I think we would ideally allow a proxy to modify/remove URNs, but 3261 
> doesn't permit that. But a proxy can get a similar effect by putting a 
> counteracting URN earlier in the sequence. But it is also possible that 
> there will be no Alert-Info and the proxy needs to add one. I suggest:
> 
>     A SIP proxy MAY add an Alert-Info header field if none is present,
>     and MAY add or remove URNs to an Alert-Info header
>     field in a SIP request or a provisional 1xx response (excepting a 100
>     response) when it needs to provide additional information about the
>     call or about the provided service.

There is complexity because we don't really care whether a URN is
added to an existing Alert-Info or whether a new Alert-Info is
inserted containing the URN.  I looked up the terminology in RFC 3261,
and it isn't quite what I thought it was:

      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.

      Header Field Value: A header field value is a single value; a
         header field consists of zero or more header field values.

(There is no separate definition of "header field row".)

So a "header field value" is (in our case) a single URN, a "header
field row" is one of those things starting with "Alert-Info:"
containing one or more URNs, and the Alert-Info "header field" is the
abstract array of all of all the URNs.

Also, it seems to be understood that a proxy can reorganize how a
header field is split into header field rows, and can reorder how the
header field rows for one field name are ordered with respect to the
header field rows of another field name.  (RFC 3261 section 7.3 and
section 16.6 step "copy request") But this is not stated very clearly.

Based on that, the first sentences you've listed under section 10 and
section 11 are correct, in that we mean that the UA or proxy can add
URNs as header field values into the array of header field values, and
we don't care how the entity organizes the Alert-Info header field
rows as long as the header field is correct.  I think it would be
clearer to start the sentences:

     A SIP UA/proxy MAY add one or more URN header field values to the
     Alert-Info header field ...

Do we want to footnote "header field" with "RFC 3261 section 6", which
contains the definitions I have quoted?

Dale