Subject: [sipcore] WGLC: draft-ietf-sipcore-callinfo-spam

From: "A. Jean Mahoney" <[email-masked]>
Date: Mon, 12 Feb 2018 05:42:08 -0600

Hi all,

Working Group Last Call starts today for draft-ietf-sipcore-callinfo-spam.

https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-spam/

Please provide any feedback to the sipcore mailing list by Monday, 
February 26th.

Thanks!

Jean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Feb 2018 10:23:10 -0500

> Please provide any feedback to the sipcore mailing list by Monday, 

I have some issues with the example in 6.1. It has:

    Feature-Caps: *sip.call-info.spam

AFAIK it should be:

    Feature-Caps: *;+sip.call-info.spam

Otherwise I think this is in good shape.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 15 Feb 2018 21:37:00 -0500

> Working Group Last Call starts today for draft-ietf-sipcore-callinfo-spam.

   3.  Overview of Operation

   SIP proxies or B2BUAs MUST add a new Call-Info "info" header field
   instance, rather than add parameters to an existing one.  Thus, there
   MAY be several Call-Info header fields of purpose "info" in one
   request.

This is correct, but I misread it the first time.  The grammar of
Call-Info is:

    Call-Info   =  "Call-Info" HCOLON info *(COMMA info)
    info        =  LAQUOT absoluteURI RAQUOT *( SEMI info-param)
    info-param  =  ( "purpose" EQUAL ( "icon" / "info"
                   / "card" / token ) ) / generic-param

and the above text means that a device may not add further info-param's
to an existing info.  But it may add additional info's to an existing
Call-Info, rather than using separate header fields.

However, it's easy to misread as meaning that the following is not
allowed:

   Call-Info: <http://wwww.example.com/
       5974c8d942f120351143> ;source=carrier.example.com
       ;purpose=info ;confidence=85 ;type=fraud ;reason="FTC list",
       <data:> ;source=other.example.com
       ;purpose=info ;confidence=20 ;type=prison

Is there a way to phrase this that is less easy to misread?

   6.1.  REGISTER Response
   ...
   SIP/2.0 200 OK
   ...
   From: Bob <sips:[email-masked]>;tag=a73kszlfl
   To: Bob <sips:[email-masked]>;tag=34095828jh
   ...
   Feature-Caps: *sip.call-info.spam

Having recently made the same mistake, I notice that the Feature-Caps
header should be:

   Feature-Caps: * ;sip.call-info.spam

See the BNF in RFC 6809 section 6.2.1.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 16 Feb 2018 07:20:08 -0500

I forgot to check this nit last night:

   ... it MUST use an empty data URL [RFC2397] as a placeholder, as in
   "data:".

The placeholder URL MUST be "data:," (with a final comma).  See RFC 2397
section 3.

Dale