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

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 7 Jun 2018 18:20:43 -0400

Thanks. Will appear in -04 shortly.

(Updating the draft, finally, so this is just for the record.)

On Fri, Feb 16, 2018 at 7:20 AM, Dale R. Worley <[email-masked]> wrote:

> 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
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 7 Jun 2018 18:42:34 -0400

Not great, but here's my new wording:

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 instances of purpose "info" in one request, either
as a single header with a comma-separated list or separate headers, or some
combination.

Let me know if that's sufficiently clear.

Henning

On Thu, Feb 15, 2018 at 9:37 PM, Dale R. Worley <[email-masked]> wrote:

> "A. Jean Mahoney" <[email-masked]> writes:
> > 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?
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 7 Jun 2018 20:38:57 -0400

Example fixed. Glad you caught this.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 7 Jun 2018 20:46:17 -0400

Thanks; fixed.

On Mon, Feb 12, 2018 at 10:23 AM, Paul Kyzivat <[email-masked]>
wrote:

> On 2/12/18 6:42 AM, A. Jean Mahoney wrote:
>
>> Hi all,
>>
>> Working Group Last Call starts today for draft-ietf-sipcore-callinfo-sp
>> am.
>>
>> https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-spam/
>>
>> Please provide any feedback to the sipcore mailing list by Monday,
>> February 26th.
>>
>
> I have some issues with the example in 6.1. It has:
>
> AFAIK it should be:
>    Feature-Caps: *;+sip.call-info.spam
>
> Otherwise I think this is in good shape.
>
>         Thanks,
>         Paul
>