Summary: Has 2 DISCUSSes. Needs one more YES or NO OBJECTION position to pass.
(1) It seems to me that there is a privacy consideration that is not discussed in this document, namely the unwanted exposure of the call types to third parties. If I'm receiving a lot of calls from the debt collection agency and my UA displays that information in my call log for anyone who might have access to my phone, or an eavesdropper can glean that information from intercepting my SIP signaling, as a user I probably want to be able to tell my SIP provider to disable this. Perhaps this capability to request that certain Call-Info headers not be sent is captured generically in RFC 3261 (I don't remember), in which case pointing that out here would be good. Or if not, I think something needs to be said about the ability for callees to turn off the transmission of these type labels. (2) I'm a little uncomfortable with this document being the definitive source for call types for all phone systems everywhere, since presumably these types have other uses in telephony beyond the use envisioned by this spec. Is there another document that could be cited as the definitive source for these types?
Please respond to the Gen-ART review.
Section 7: Which ABNF is used here, please provide a reference. I also very much would appreciate that the normative reference for "iana-token" was provided in this section rather than 8.3.
Section 8.3: So I am slightly worried that there are no recommendations on the criteria the expert should have for accepting or rejecting an registration request. Well there is always the possibility for appealing a registration request if it gets rejected. Considering that these labels are very much social constructs they will be culture dependent and what may be acceptable in one culture may not be in another. I would expect that being very liberal is the only way forward here. At the same time allowing many overlapping labels could enable attacks on the system. Was these aspects discussed in the WG?
I concur with most or all of Barry's suggested edits and encourage you to consider them when preparing a new version. I also support Alissa's and Magnus' DISCUSS positions. The third paragraph of Section 3 left me uncertain about whether all the references to "header" vs. "header field" were correct. Might be worth another look. In the lists in Sections 4 and 5, I suggest putting colons after each of the hanging labels. Separating them from the prose by just a couple of spaces doesn't seem to be enough. I'm curious about the second paragraph in Section 9; under what circumstances might one deviate from the SHOULD?
Section 1. Per the reference to “the historical precedent of the ‘blue pages’”, is that a references understandable outside of the US/Canada? Section 1. Per “In the United States, industry organizations have proposed …”, is there a citation for this activity? Section 4. Typo. s/equipement/equipment/ Section 8.1. ‘Confidence’ appears to be missing from the list of new parameters to register in "Header Field Parameters and Parameter Values" under “Call-Info”. Section 8.3. Per idnits, RFC 5226 is obsoleted by RFC 8126 Section 9. Per “Thus, a UAS SHOULD NOT trust the information … unless … the UAS is protected by TLS [RFC8446]”, is this text explicitly saying only TLS v1.3 is trusted (i.e., TLS v1.2 or a future TLS v2 would not be trusted)? I’d recommend indicating a TLS version number (e.g., TLS 1.2+ or per RFC7525) Section 9. Nit. /the called party is mislead/the called party is misled/
I agree with Alissa about the missing privacy considerations. Section 1 In many countries, an increasing number of calls are unwanted [RFC5039], as they might be fraudulent, telemarketing or the receiving party does not want to be disturbed by, say, surveys or solicitation by charities. nit: the list structure is not parallel, as "fraudulent" and "telemarketing" apply to the call themselves, but "the receiving party does not want to be disturbed" describes the callee. if the registrar is part of a PBX. Thus, the entity inserting the Call-Info header field and the UAS relying on it SHOULD be part of the same trust domain [RFC3324]. Conversely, the entity signing the I'm not sure if this ("SHOULD") is an attribute that one or more parties is expected to take action to ensure is the case, or merely a description of what the scenario is already expected to be. Section 4 confidence The 'confidence' parameter carries an estimated [...] specification. If a 'type' is not specified, this parameter estimates the likelihood that the call is unwanted spam by the called party. If the confidence level is not specified, the The 'type' parameter is mandatory, so I don't see how this situation could arise. Section 5 treated as a hint or estimate. Each entity inserting type information will need to define its own policy as to the level of certainty it requires before it inserts type information. It's probably okay to leave this unspecified, since the header is in some sense largely for use between callees and their SIP providers, but do we want to give some indication that these two parties could exchange information about what policy is being used? business Calls placed by businesses, i.e., an entity or enterprise entered into for profit. This type is used if no other, more precise, category fits. Aren't we supposed to have some reasonable level of confidence in classification before applying any label at all? It's not clear to me that this text about catch-all/fallback usage is appropriate. Section 7 If we felt like it, we could tighten up ci-confidence to not allow, e.g., a percentage value of 999. Section 9 capability. B2BUAs or proxies that maintain user registrations MUST remove any parameters defined in this document that were provided by untrusted third parties. Is the intent to impose this requirement on all B2BUAs globally (including those that do not otherwise implement this specification) or just ones that are adding Call-Info header fields or something else? Thus, a UAS SHOULD NOT trust the information in the "Call-Info" header field unless the SIP session between the entity inserting the header field and the UAS is protected by TLS [RFC8446]. I agree with the secdir reviewer that we need to say more about how the server is authenticated for this TLS connection. If we describe this as "SIPS" then the RFC 3261 requirement for "mutual TLS authentication" (still underspecified, but no longer this document's responsibility) kicks in.
I have a number of minor comments that I hope you'll consider. — Section 3 — SIP request MAY contain several Call-Info header instances of purpose "info", either as a single header with a comma-separated list of header values or separate headers, or some combination. Nit: Correctly used, “either” selects one of two choices, not from among three or more. I suggest this: NEW SIP request MAY contain several Call-Info header instances of purpose "info", as a single header with a comma-separated list of header values or as multiple headers, each with one or more header values. END If the entity inserting the header field does not have information it wants to link to, it MUST use an empty data URL [RFC2397] as a placeholder, as in "data:,". (The Call-Info header field syntax makes the URI itself mandatory.) Nit: The parenthesized bit struck me as oddly placed; I suggest this: NEW Because the Call-Info header field syntax makes the URI mandatory, if the entity inserting the header field does not have information it wants to link to, it MUST use an empty data URL (“data:,”) [RFC2397] as a placeholder. END — Section 4 — All of the parameters listed below are optional and may appear in any combination and order. Their ABNF is defined in Section 7. All except the 'type' parameter are optional. The third sentence contradicts the first (I’m guessing it’s a paste error). I suggest this: NEW Call-Info header field parameters are listed below. Their ABNF is defined in Section 7, and they may appear in any combination and order. The ‘type’ parameter is REQUIRED, and all others are OPTIONAL. END Or, if I guessed wrong about the ‘type’ parameter, the last sentence would be “All parameters are OPTIONAL.” source The source parameter identifies the entity, by host name, domain or IP address, that inserted the 'confidence', 'origin' and 'type' parameters. It uses the "host" ABNF syntax. Where is the “host” ABNF syntax defined? Perhaps a citation here would help. — Section 5 — generally based on the caller's telephone number or possibly an assertion by a trusted caller, as the content cannot be not known. What does “as the content cannot be not known” mean? Can you please rephrase this? — Section 8.1 — The first entry in the table is incorrectly formatted: it has the reference field first instead of last. — Section 9 — as otherwise spoofed calls would likely be mislabeled and thus increase the likelihood that the called party is mislead, “misled” Thus, this information MUST only be added calls with an attestation level of "Full Attestation" [RFC8588] or for calls where the SIP entity inserting the header knows to have correct calling number information, e.g., because the call originated within the same PBX or the same carrier and the operating entity ensures that caller ID spoofing is highly unlikely within their realm of responsibility. “only be added to calls” “or to calls” “knows it has correct calling number information” Actually, the sentence is too long anyway, so I suggest splitting it. How about this?: NEW Thus, this information MUST only be added to calls with an attestation level of "Full Attestation" [RFC8588] or to calls where the SIP entity inserting the header knows it has correct calling number information. An example of how it might know that is if the call originated within the same PBX or the same carrier, and the operating entity ensures that caller ID spoofing is highly unlikely within their realm of responsibility. END
Thank you for this document. I agree with Barry’s comments. One extra nit from myself: In 8.1. SIP Call-Info Header Field Parameters: The order of fields in the first registration is rotated by one field. I don’t think this was intended.
I support Alissa's DISCUSS.
Please expand B2BUA on first use.
Thank you for the work put into this document. Please find a couple of COMMENTs and NITs below. Regards, -éric == COMMENTS == -- Section 1 -- C.1) I suggest to remove or explain "blue pages" as it probably a USA thing (I have no clue what are those pages being based in Belgium). -- Section 4 -- C.2) the word "probability" is used with a range of 0 to 100. This is somehow confusing as the word "probability" has a mathematical definition which is not applicable here, "confidence" or "certainty' could be a better wording. C.3) using an IP address as the source may not be very useful for most applications/users/consumers of this header. Why not having a FQDN as a MUST? -- Section 5 -- C.4) In the first paragraph, I cannot figure out how to both have "Other strings may be used" and "Additional labels are registered with IANA." in the same paragraph. -- Section 6.2 -- C.5) is there a reason why "http" is used rather than "https" ? == NITS == -- Section 5 -- N.1) in the enumeration of labels, adding a ":" after the label would improve the readability. -- Section 8.1 -- The table is misaligned.