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

[Christer Holmberg <[e-mail]>]

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.

>       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
  
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
    
    
    > On Mar 27, 2019, at 12:18 PM, Christer Holmberg <[e-mail]> wrote:
    > 
    > 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 <[e-mail]> on behalf of "[e-mail]" <[e-mail]>
    > Date: Wednesday, 27 March 2019 at 17.41
    > To: "[e-mail]" <[e-mail]>
    > Subject: Re: [sipcore] New Version Notification for draft-ietf-sipcore-rejected-04.txt
    > 
    > 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, [e-mail] 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
    >>