Re: [sipcore] Comments on draft-mohali-sipcore-reason-call-forwarding-00

[<[e-mail]>]

Hi Dale,

My new response inline [MM2] 

Marianne

> -----Message d'origine-----
> De : Worley, Dale R (Dale) [mailto:[e-mail]] 
> Envoyé : jeudi 21 octobre 2010 21:47
> À : MOHALI Marianne RD-CORE-ISS; [e-mail]
> Objet : RE: [sipcore] Comments on 
> draft-mohali-sipcore-reason-call-forwarding-00
> 
> >> From: Dale Worley
> 
> > From: Marianne Mohali
> 
> > > Section 3 does not give any BNF for CDIV, though it quotes all of 
> > > the established BNF for the Reason header. Clearly, what 
> is intended 
> > > (but not stated) is:
> > >
> > >     protocol  =/  "CDIV"
> > 
> > [MM] What is just after the established BNF is not good? I've used
> > RFC4411 as a model.
> 
> It is good to describe the change in words, but it is better 
> to describe the change in both words and in BNF -- some 
> people find one method easier to understand than the other 
> method.  And since the two methods are vulnerable to 
> different kinds of errors, using both makes it easier to 
> discover errors in the definition.
> 
> As far as I can tell, RFC 4411 contains no BNF at all, so it 
> is not a good model of how to update BNF.
> 
[MM2] You're right, in the next version I will make the new proposed syntax clearer. 

> > > In regard to listing the CDIV cause values, it seems to me that 
> > > there should be an existing encoding of call diversion reasons 
> > > somewhere within the 3GPP specification, and it would be more 
> > > effective for the draft to reference that table (which would be 
> > > maintained by 3GPP) rather than defining a new IANA 
> registry (which 
> > > would be used almost exclusively by 3GPP).
> > 
> > [MM] Right, but the existing CDIV cause values (described 
> in 3GPP) are 
> > a corruption of SIP response codes and brings confusion. It is the 
> > initial reason of this draft. Your idea of mixing both 
> sound good to 
> > me: register a new protocol value "CDIV" but keep the 
> reasons values 
> > as in 3GPP. The problem I see is that reason values are 
> described in 
> > RFC4458 not for the Reason header but for an URI parameter and I'me 
> > not sure it is possible to re-use it. An other way could be to 
> > registering cause values but with the same values as today 
> instead of 
> > (1 to 8). Let's think about it...
> 
> The ideal situation would be if 3GPP had a clear taxonomy of 
> diversion situations, and the CDIV cause values were an 
> encoding of those categories.  In particular, we expect CDIV 
> to be generated by a 3GPP system, and so 3GPP would clearly 
> specify the diversion situations which are described by the 
> cause values.
> 
> It is not ideal if Sipcore defines these cause values, 
> because our understanding of call diversion services probably 
> differs from the understanding of 3GPP.
[MM2] Before raising a debate on sipcore, I first launch a discussion with 3GPP people to have their feedback and to see if they are also interested in simplification of CDIV implementation. For the time being, 3GPP specification is based on RFCs (4244 and 4458), that the reason why I think a change should be done via IETF (and also because current debates on the Reason header escaped in the H-I are very close to this topic). 
 
> 
> Dale
>