Re: [BLISS] Status of draft-ietf-bliss-call-completion-10

Shida Schubert <> Thu, 01 September 2011 06:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB19B21F87C9 for <>; Wed, 31 Aug 2011 23:56:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UXbOY7vu1PE2 for <>; Wed, 31 Aug 2011 23:56:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 279E321F87C5 for <>; Wed, 31 Aug 2011 23:56:22 -0700 (PDT)
Received: from [] (port=62583 helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <>) id 1Qz1Dk-0005iZ-SJ; Thu, 01 Sep 2011 01:57:53 -0500
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=windows-1252
From: Shida Schubert <>
In-Reply-To: <>
Date: Thu, 1 Sep 2011 15:57:56 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "Worley, Dale R (Dale)" <>
X-Mailer: Apple Mail (2.1244.3)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Source-Sender: ([]) []:62583
X-Email-Count: 2
X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t
Cc: "" <>
Subject: Re: [BLISS] Status of draft-ietf-bliss-call-completion-10
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Sep 2011 06:56:24 -0000

Hi Dale;

 Thanks for prompting this. 

 I did a thorough review of the draft before submitting 
to the IESG and I sent the following comments along 
with a draft with my suggested edits (all nits). 

 After some discussions, it was found that some change 
in normative text can be beneficial. Authors can probably 
provide us with more details but 

 Never the less below is the link to the new draft as well as 
to a diff. 


 Please provide comments if you have any issues with the 
changes and let me know if there is any issue with composing 
a proto-write up based on the draft referenced. 


** E-mails I sent to the authors in July ****

 A lot of the fixes were an attempt to unify the terminology 
used. This would come up at some point and cleaning this 
up before submitting to IESG or AD review would probably 
be a good idea. 

 For example, I tentatively chose caller's agent and callee's 
monitor as it indicates where the logical entity reside on the 
signaling path. 

Also, terminology like CC policy wasn't defined so I changed 
it to local policy of the callee's monitor etc.. 

Also some questions that need clarification.

1. Section 4.2 last paragraph.

What is the intent of "optionally with the possibility to update the subscription."? 

What is optional? I couldn't see what you were trying to say here. 

2.  Furthermore terminology section can use some re-arrangement in 
terms of order in which it is described. 

I would start with the entities (caller/callee/caller's agent/callee's monitor) ,  
followed by different state (cc recall, cc call), followed by the rest (cc event etc.)

It would be easier to understand each terminology if you have them in  
groups and in an order which aids people to get familiar with the terminology. 

3. Section 7.1

 Why is inserting a call-info with "purpse=call-info" not a MUST when entity supports 
this specification? 
 Also on the same paragraph, what is the "appropriate response"?

4. Section 7.1
"Implementations MUST accept CC operations in which the 'm' parameter is 
missing or has an.."

 All the values are optional, URI, purpose etc. so same should apply to all. IF this 
is not the case, URI and purpose should be changed to MUST insert.. 

5. Section 7.2 

 I feel that following paragraph actually belongs to the section which describes the 
behavior of the caller's agent. 

"The caller's agent MUST be prepared to receive multiple responses to

  the SUBSCRIBE and to have multiple subscriptions established.  The

  agent must also be prepared to have the SUBSCRIBE fail, in which

  case, CC cannot be invoked for this original call."

6. There is no mentioning of how to terminate the subscription.

I know you just do what RFC3265 does, but may be this should be voiced 
out if it is the case. 

e.g. SHOULD terminate the the subscription according to RFC3265 etc. 

7. When should "The callee’s monitor SHALL start a recall timer" ?? 

8. As for the reference.

I think the RFC3903(PUBLISH) SHOULD be added to a reference.
I also think that RFC5359 can be an informational reference instead of normative. 

I will have another close look at the IANA registration section and will get 
back to you. I know that MIME registration should contain more information. 




On Sep 1, 2011, at 3:07 AM, Worley, Dale R (Dale) wrote:

> What is the status of draft-ietf-bliss-call-completion?
> The last message I can find is
> (6
> May 2011) in which Martin H. uploaded the -10 version.  As far as I
> can remember, everyone has commented on -09 and -10a (even myself) and
> had their comments addressed.  That comment cycle was a WGLC, so we
> should be set to take it to the IESG.
> Dale
> _______________________________________________
> BLISS mailing list