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

[Laura Liess <[e-mail]>]

Dale,

Please see in-line.


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

I agree and changed the draft accordingly.


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

I think the text proposed by Paul is clear enough and I would not insert
any additional explanations.

Thank you
Laura


>
> Dale
> _______________________________________________
> salud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/salud
>