Subject: Re: [sipcore] New Version Notification for draft-ietf-sipcore-rejected-04.txt

From: Eric Burger <[email-masked]>
Date: Wed, 27 Mar 2019 11:41:19 -0400

Updated all instances of SHOULD xxx UNLESS yyy language to IF NOT yyy MUST xxx and took out my annual screed against SHOULD without UNLESS.

> On Mar 27, 2019, at 11:39 AM, [email-masked] wrote:
> 
> 
> A new version of I-D, draft-ietf-sipcore-rejected-04.txt
> has been successfully submitted by Eric W. Burger and posted to the
> IETF repository.
> 
> Name:		draft-ietf-sipcore-rejected
> Revision:	04
> Title:		A Session Initiation Protocol (SIP) Response Code for Rejected Calls
> Document date:	2019-03-27
> Group:		sipcore
> Pages:		22
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-sipcore-rejected-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-sipcore-rejected-04
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rejected
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rejected-04
> 
> Abstract:
>   This document defines the 608 (Rejected) SIP response code.  This
>   response code enables calling parties to learn that an intermediary
>   rejected their call attempt.  The call will not be answered.  As a
>   6xx code, the caller will be aware that future attempts to contact
>   the same UAS will likely fail.  The present use case driving the need
>   for the 608 response code is when the intermediary is an analytics
>   engine.  In this case, the rejection is by a machine or other
>   process.  This contrasts with the 607 (Unwanted) SIP response code,
>   which a human at the target UAS indicated the call was not wanted.
>   In some jurisdictions this distinction is important.  This document
>   also defines the use of the Call-Info header in 608 responses to
>   enable rejected callers to contact entities that blocked their calls
>   in error.  This provides a remediation mechanism for legal callers
>   that find their calls blocked.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Mar 2019 16:18:29 +0000

Hi Eric,

It seems like you haven’t fixed the Feature-Caps examples, based on the earlier discussion (the name of the thread was ‘Syntax of Feature-Caps header’, but I guess you were not made aware that it affected the sipcore-rejected draft).

The correct way is: Feature-Caps: *;+sip.608

Regards,

Christer

From: sipcore <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Wednesday, 27 March 2019 at 17.41
To: "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] New Version Notification for draft-ietf-sipcore-rejected-04.txt

On Mar 27, 2019, at 11:39 AM, [email-masked]<mailto:[email-masked]> wrote:

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: Eric Burger <[email-masked]>
Date: Wed, 27 Mar 2019 21:15:21 -0400

Thanks! I totally missed the thread. One question, besides updating the example, what should I say in the text? Since Feature-Caps is a list, should I say:

   Name:  sip.608

   Description:  This feature capability indicator, when included in a
      Feature-Caps header field of an INVITE request, indicates that the
      entity that inserted the sip.608 Feature-Caps value will be
      responsible for indicating to the caller any information contained
      in the 608 SIP response code, specifically the value referenced by
      the Call-Info header

or

   Name: *;+sip.608

   Description:  This feature capability indicator, when included in a
      Feature-Caps header field of an INVITE request, indicates that the
      entity that inserted the *;+sip.608 Feature-Caps value will be
      responsible for indicating to the caller any information contained
      in the 608 SIP response code, specifically the value referenced by
      the Call-Info header

> On Mar 27, 2019, at 12:18 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Eric,
>

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Thu, 28 Mar 2019 08:05:06 +0100

Thanks for making the changes, Eric. I'll finish up my Doc Shepherd 
review when I get back from the IETF meeting.

I understand being frustrated with the normative terminology 
boilerplate. Maybe you could take the UNLESS idea to IETF General 
mailing list ;-)

Jean

On 3/27/19 4:41 PM, Eric Burger wrote:
> Updated all instances of SHOULD /xxx/ UNLESS /yyy/ language to IF NOT 
> /yyy/ MUST /xxx/ and took out my annual screed against SHOULD without 
> UNLESS.
> 
>> Name:draft-ietf-sipcore-rejected
>> Revision:04
>> Title:A Session Initiation Protocol (SIP) Response Code for Rejected Calls
>> Document date:2019-03-27
>> Group:sipcore
>> Pages:22
>> URL: 
>> https://www.ietf.org/internet-drafts/draft-ietf-sipcore-rejected-04.txt
>> Htmlized: 
>> https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rejected
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Mar 2019 07:31:46 +0000

Hi,

>  Thanks! I totally missed the thread. One question, besides updating the example, what should I say in the text? 
> Since Feature-Caps is a list, should I say:
>    
>       Name:  sip.608
  
This is the correct way.

>          in the 608 SIP response code, specifically the value referenced by
  
I suggest the following modified text:

           Description:  This feature capability indicator, when included in a
             Feature-Caps header field of an INVITE request, indicates that the
             entity associated with the indicator, will be responsible for indicating to
             the caller any information contained in the 608 SIP response code, specifically 
             the value referenced by the Call-Info header
  
That way you don't need to repeat the value in the description text.

Regards,

Christer