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

From: Eric Burger <[email-masked]>
Date: Sun, 3 Feb 2019 21:13:05 -0500

1. Addressed /most/ of Tolga's nits. I decided to leave ‘intermediary’ as is. If the WG disagrees, I won’t fall on my sword for it and will do a global substitution.

2. Fixed some unclear language Bhavik found when implementing the draft.

3. BTW, that means we have an open-source prototype at https://github.com/nagdab/608_Implementation

I think we’re done. What do *you* think?

- Eric

>> On Feb 3, 2019, at 2:50 PM, [email-masked] wrote:
>> 
>> 
>> A new version of I-D, draft-ietf-sipcore-rejected-03.txt
>> has been successfully submitted by Eric W. Burger and posted to the
>> IETF repository.
>> 
>> Name:		draft-ietf-sipcore-rejected
>> Revision:	03
>> Title:		A Session Initiation Protocol (SIP) Response Code for Rejected Calls
>> Document date:	2019-02-03
>> Group:		sipcore
>> Pages:		22
>> URL:            https://www.ietf.org/internet-drafts/draft-ietf-sipcore-rejected-03.txt
>> Status:         https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/
>> Htmlized:       https://tools.ietf.org/html/draft-ietf-sipcore-rejected-03
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rejected
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rejected-03
>> 
>> 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
>> 
>