Indeed, this is exactly correct.
 
Kevin

From: Yangbo Lin [mailto:linyangbo@huawei.com]
Sent: Tuesday, June 26, 2007 5:59 AM
To: Boyle, Kevin (NCRTP:3Z40); Schwarz Albrecht; Christian.Groves@nteczone.com
Cc: Jerker Zetterlund (TN/EAB; itu-sg16@lists.packetizer.com; Juergen.Stoetzer-Bradler@alcatel-lucent.de; CWaitzmann@alcatel-lucent.de
Subject: Re: [itu-sg16] C-277: H.248.1 Compatibility

Hello Kevin,
 
The "encoded" as version 1 may mean that the initial registration shouldn't contain items not subjected to version 1, otherwise it cannot be encoded as version 1, but the value of ServiceChange Version could be 1, 2 or 3. Is it correct?
 
                                                                                Regards, Yangbo
 
----- Original Message -----
From: Kevin Boyle
To: Yangbo Lin ; Schwarz Albrecht ; Christian.Groves@nteczone.com
Cc: Jerker Zetterlund (TN/EAB ; itu-sg16@lists.packetizer.com ; Juergen.Stoetzer-Bradler@alcatel-lucent.de ; CWaitzmann@alcatel-lucent.de
Sent: Tuesday, June 26, 2007 5:40 PM
Subject: RE: [itu-sg16] C-277: H.248.1 Compatibility

The initial registration command must be *encoded* as version 1 -- this is to ensure that the MG will not confuse a MGC that is on an earlier version of the protocol.  But once the protocol is negotiated, then all subsequent messaging can be in whatever the negotiated version happens to be.
 
Kevin

From: itu-sg16-bounces@lists.packetizer.com [mailto:itu-sg16-bounces@lists.packetizer.com] On Behalf Of Yangbo Lin
Sent: Tuesday, June 26, 2007 4:06 AM
To: Schwarz Albrecht; Christian.Groves@nteczone.com
Cc: Jerker Zetterlund (TN/EAB; itu-sg16@lists.packetizer.com; Juergen.Stoetzer-Bradler@alcatel-lucent.de; CWaitzmann@alcatel-lucent.de
Subject: Re: [itu-sg16] C-277: H.248.1 Compatibility

Hello Albrecht,
 
I have a question about one sentence in the added text proposed by you -- "Any MG registration is starting with protocol version 1", why is only version 1 instead of 2 or 3? In my understanding, it depends on the highest version implemented by MG.
 
                                                                                Regards, Yangbo
 
----- Original Message -----
From: Schwarz Albrecht
To: Christian.Groves@nteczone.com
Cc: itu-sg16@lists.packetizer.com ; linyangbo@huawei.com ; CWaitzmann@alcatel-lucent.de ; Juergen.Stoetzer-Bradler@alcatel-lucent.de ; Jerker Zetterlund (TN/EAB
Sent: Monday, June 25, 2007 7:43 PM
Subject: C-277: H.248.1 Compatibility

Hello Christian, all,

like the proposal concerning forward & backward compatibility rules. Did add some text with regards to the compatibilty mechanism(s), which are specific to H.248 (and thus worth to be mentioned).

Best regards,
Albrecht



<<T05-SG16-C-0277r1 H.248 Compatibility.doc>>
####

Hello Albrecht, Keith,

Thanks for the reference to Q.1400. I think it was these fundamentals of
compatibility for ISUP and DSS that lead to the original definition of
the version negotiation and protocol enhancement rules in H.248.1. At
the time of writing H.248.1v1 there was involvement from a number of
people involved in the work of SG11.

I think the general principles of Q.1400 are in-line with what is being
used in H.248.1 so at this level it can be used. I agree some of the
specific examples aren't relevant for H.248.1. I'll try to propose some
clarifying text for the Q.3/16 meeting. I don't intend to write a thesis
on the matter, I intend to stick making simple rules applicable for
protocol, packages and profiles.

Regards, Christian

Albrecht Schwarz wrote:
> [Like to open a separate thread on compatibility rules for H.248, think
> this is a more general topic in comparison to the Ia specific IP realm
> indication mechanism.]
>
> Keith, thanks for the pointer to Q.1400, believe that the clause about
> compatibility rules is a good baseline for correspondent definitions for
> H.248.
> I think additional explicit text about compatibility rules in H.248.1, e.g.
> in clause 12, would be beneficial.
>
> We may not directly reuse Q.1400 for H.248 (in my understanding) because
> a) Q.1400 is for ASN.1 defined protocols (and H.248 has also ANBF defined
> grammar for text encoding mode),
> b) Q.1400 focus is SS7 and DSS1, or
> c) H.248 integrated version/profile mechanisms.
>
> Christian, think that your proposal is a good baseline. Could you submit it
> as input to next Q.3/16 meeting?
>
> Albrecht
>
>
>
>                                                                                                                                        

>                       "Drage, Keith                                                                                                    

>                       \(Keith\)"               To:      "Schwarz, Albrecht \(Albrecht\)" <albrecht.schwarz@alcatel-lucent.de>,         

>                       <drage@alcatel-l         <TISPAN_WG3@LIST.ETSI.ORG>                                                              

>                       ucent.com>               cc:                                                                                     

>                                                Subject: RE: H.248 Ia Profile Version 2                                                 

>                       24.04.2007 12:07                                                                                                 

>                                                                                                                                        

>
>
>
>
> The compatibility definitions in ITU-T are all in Q.1400.
>
> Regards
>
> Keith
>
>  
>> -----Original Message-----
>> From: Albrecht Schwarz [mailto:Albrecht.Schwarz@ALCATEL-LUCENT.DE]
>> Sent: Tuesday, April 24, 2007 1:08 AM
>> To: TISPAN_WG3@LIST.ETSI.ORG
>> Subject: Re: H.248 Ia Profile Version 2
>>
>> Bruno
>>
>>    
>>> My understanding is that backward compatibility in the work item
>>>      
>> description was intended to refer to the ability
>>    
>>> for version n+1 to understand version n without requiring version
>>>      
>> negotiation to occur before. This is usually what
>>    
>>> is meant in other ITU-T and ETSI standards dealing with signalling.
>>>      
>> Couldn't find any appropriate definition for "backward
>> compatibility" in ITU-T & ETSI (like the one for codecs from H.262).
>>
>> There are signalling protocols with and without a version
>> negotiation mechanism. The understanding of "backward
>> compatibility" might be slightly different for both
>> categories. Guess the protocols without a version negotiation
>> method are the majority like the capability set based ITU-T
>> protocols like e.g. INAP, BICC or Q.2630.x.
>> H.248 belongs to the category with an
>> a) integral mechanism for protocol version negotiation and in
>> addition a
>> b) mechanism for profile negotiation
>> and also
>> c) a multi profile mode capability (H.248.18).
>>
>> The used protocol capabilities are related to the lifetime of
>> the H.248 Control Association (CA), starting the negotiation
>> at CA establishment.
>> Capability upgrade procedures may lead to a re-new or
>> re-establishment of the CA.
>>
>> A definition for "backward compatibility" for H.248 CAs might
>> therefore different to other protocols without such mechanisms.
>>
>> We got four WIs for H.248 Profiles, - a MG registration with
>> the correspondent ProfileID is part of a profile specification.
>> Saying that, the meaning of backward compatibility in the WI
>> description means that the MG registers with Ia/2 in my opinion.
>> In case of a fallback requirement to Ia/1, then current draft
>> my be extended for H.248.18 support (but this requires a
>> contribution).
>>
>> Albrecht
>>
>>
>>
>>
>>
>>
>>
>>                       Christian Groves
>>
>>
>>                       <Christian.Groves@NT         To:
>> TISPAN_WG3@LIST.ETSI.ORG
>>
>>                       ECZONE.COM>                  cc:
>>
>>
>>                                                    Subject:
>> Re: H.248 Ia Profile Version 2
>>
>>                       23.04.2007 09:55
>>
>>
>>                       Please respond to
>>
>>
>>                       Christian Groves
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Hello Bruno,
>>
>> What does "ability for version n+1 to understand version n"
>> mean? Even in the scenario we are talking about a MG with a
>> version n+1 control association will understand the version n
>> message because the encoding has not changed (thus backwards
>> compatible by the definition below) but it will reject it
>> because of new required functionality. Likewise it seems that
>> "before version negotiation" has been prompted by the email
>> discussion. For some, such mechanisms are integral for
>> compatibility mechanisms.
>>
>> Do you have a reference to a general description of "backwards
>> compatibility"?   The term is used alot but I don't know any
>> description
>> other than that in H.248.1. For example H.248.1 section 11.3
>> Negotiation of Protocol Version offers rules for new versions. ie.
>>
>>     /When extending the protocol with new versions, the
>> following rules
>>     should be followed:/
>>     /1) Existing protocol elements, i.e., procedures, parameters,
>>     descriptor, property, values, should/
>>     /not be changed unless a protocol error needs to be
>> corrected or it
>>     becomes necessary to/
>>     /change the operation of the service that is being
>> supported by the
>>     protocol./
>>     /2) The semantics of a command, a parameter, a descriptor, a
>>     property, or a value should not be/
>>     /changed./
>>     /3) Established rules for formatting and encoding messages and
>>     parameters should not be/
>>     /modified./
>>     /4) When information elements are found to be obsolete they can be
>>     marked as not used./
>>     /However, the identifier for that information element
>> will be marked
>>     as reserved. In that way/
>>     /it cannot be used in future versions./
>>
>> These rules were adopted to ensure backwards compatibility. I
>> think these rules are equally applicable to the case of
>> profiles. When the MGC and MG agree on the use of a control
>> association they agree on the
>> H.248.1 version and the profile (including version).
>>
>> Regards, Christian
>>
>> CHATRAS Bruno RD-CORE-ISS wrote:
>>    
>>> Hello Chirstian,
>>>
>>> My understanding is that backward compatibility in the work item
>>>      
>> description was intended to refer to the ability for version
>> n+1 to understand version n without requiring version
>> negotiation to occur before.
>> This is usually what is meant in other ITU-T and ETSI
>> standards dealing with signalling.
>>    
>>> Best Regards,
>>> Bruno
>>>
>>> -----Message d'origine-----
>>> De : Christian Groves [mailto:Christian.Groves@NTECZONE.COM]
>>> Envoyé : lundi 23 avril 2007 02:58
>>> À : TISPAN_WG3@LIST.ETSI.ORG
>>> Objet : Re: H.248 Ia Profile Version 2
>>>
>>> Hello Bruno,
>>>
>>> What was the definition of "backward compatibility" that
>>>      
>> the work item
>> description assumed? It seems that people have different
>> interpretations.
>>    
>>> Regards, Christian
>>>
>>> CHATRAS Bruno RD-CORE-ISS wrote:
>>>
>>>      
>>>> This is version negotiation, not backward compatibility.... Both
>>>>        
>> approaches are valid protocol design approaches and have
>> their pros and cons. However, the Work Item description
>> assumed "backward compatibility between version 1 and 2...
>>    
>>>> -----Message d'origine-----
>>>> De : Neal ZhuNing [mailto:zhuning@HUAWEI.COM] Envoyé : vendredi 20
>>>> avril 2007 04:09 À : TISPAN_WG3@LIST.ETSI.ORG Objet : Re: H.248 Ia
>>>> Profile Version 2
>>>>
>>>>    Agree Albrecht's state.
>>>>     When a BGF registers with a ProfileID "ETSI_BGF/1" 0r
>>>> "ETSI_BGF/2",
>>>>        
>> corresponding ia profile(ia/2 or ia/1) should be applied.
>>    
>>>>    I think the Profile-based backward compatibility
>>>>        
>> between ia/2 and
>> ia/1 is based on their functions. Ia/2 can realize all the
>> functions of Ia/1, but new better methods can be used, even
>> it is mandatory.
>>    
>>>> BR
>>>> Neal
>>>>
>>>>  -----Original Message-----
>>>> From: Albrecht Schwarz [mailto:Albrecht.Schwarz@ALCATEL-LUCENT.DE]
>>>> Sent: Thursday, April 19, 2007 6:50 PM
>>>> To: TISPAN_WG3@LIST.ETSI.ORG
>>>> Subject: Re: H.248 Ia Profile Version 2
>>>>
>>>> [Sorry for using your initials as abbreviation BC for backward
>>>> compatibility :-)]
>>>>
>>>> I do agree to your statement.
>>>>
>>>> Important here is the "scope of the protocol" in my understanding.
>>>> There would be a compatibility issue when the SPDF & BGF would
>>>> operate
>>>>        
>> Ia interface in the "NoProfile" mode, i.e. the BGF would not
>> include the ServiceChangeProfile parameter for registration.
>>    
>>>> But the protocol scope is limited when registering with a
>>>>        
>> ProfileID
>>    
>>>> (as
>>>>        
>> in case of ES 283 018). There are then only "ETSI_BGF/1" or
>> "ETSI_BGF/2"
>>    
>>>> H.248 Messages between a single SPDF-BGF tandem.
>>>>
>>>> I think that this is the crucial point concerning "protcol
>>>>        
>> scope" for
>>    
>>>> H.248
>>>> interface: "Profile-less" vs "Profile-based" operated H.248 Control
>>>>        
>> Associations.
>>    
>>>> Albrecht
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>                       "CHATRAS Bruno
>>>>
>>>>                       RD-CORE-ISS"                    To:
>>>>        
>>     "Neal
>>    
>>>> ZhuNing" <zhuning@huawei.com>, <Albrecht.Schwarz@ALCATEL-LUCENT.DE>
>>>>                       <bruno.chatras@orange-f         cc:
>>>> <TISPAN_WG3@LIST.ETSI.ORG>
>>>>
>>>>                       tgroup.com>
>>>>        
>> Subject: RE: H.248
>> Ia
>>    
>>>> Profile Version 2
>>>>
>>>>
>>>>                       19.04.2007 12:28
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Adding a mandatory parameter to version n+1 of a protocol
>>>>        
>> means that
>>    
>>>> a
>>>>        
>> message conforming to the version n of this protocol is not a
>> valid message for an implementation conforming to version n+1
>> of this protocol. Is not this a compatobility issue?
>>    
>>>> BC
>>>>
>>>> -----Message d'origine-----
>>>> De : Neal ZhuNing [mailto:zhuning@huawei.com] Envoyé :
>>>>        
>> jeudi 19 avril
>>    
>>>> 2007 11:55 À : Albrecht.Schwarz@ALCATEL-LUCENT.DE; CHATRAS Bruno
>>>> RD-CORE-ISS Cc : TISPAN_WG3@LIST.ETSI.ORG Objet : RE: H.248 Ia
>>>> Profile Version 2
>>>>
>>>> Hi Albrecht, Bruno,
>>>>    In Ia/1, the hierarchical termination name does not specifically
>>>>        
>> mention that it is used to identify the IP domain that a
>> termination is connected to, nor does it give an example of
>> the syntax associated with the "interface". So maybe there is
>> no backward compatibility on this issue.
>>    
>>>>   In Ia/2, the hierarchical termination name may still be used to
>>>>        
>> specify which physical or logical interface a termination
>> should be associated with in the MG.
>>    
>>>> So, the hierarchical termination name mechanism is same in Ia/1 and
>>>>        
>> Ia/2, there is no backward compatibility problem.
>>    
>>>> BR
>>>> Neal
>>>>
>>>> -----Original Message-----
>>>> From: Albrecht Schwarz [mailto:Albrecht.Schwarz@ALCATEL-LUCENT.DE]
>>>> Sent: Thursday, April 19, 2007 5:21 PM
>>>> To: TISPAN_WG3@LIST.ETSI.ORG
>>>> Subject: Re: H.248 Ia Profile Version 2
>>>>
>>>> Bruno,
>>>> when we discussed this, we couldn't see a violation of the backward
>>>>        
>> compatibility (BC) principle.
>>    
>>>> The MG is registering either with Ia/1 or Ia/2, but not with both
>>>>        
>> profile versions (like in a multiple profile mode), the used
>> IP realm/domain indication mechanism is unambiguous.
>>    
>>>> The profile principle is thus supporting BC targets.
>>>> A single H.248 Control Association is either operated with
>>>>        
>> Ia/1 or Ia/2.
>>    
>>>> Do I overlook sth?
>>>>
>>>> Albrecht
>>>>
>>>> PS
>>>> Above principle is/may also used for other "capability upgrades",
>>>> like H.248.10 replacement by H.248.11 in a next profile
>>>>        
>> version, etc
>>    
>>>> etc
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>                       CHATRAS Bruno
>>>>
>>>>                       RD-CORE-ISS                     To:
>>>> TISPAN_WG3@LIST.ETSI.ORG
>>>>
>>>>                       <bruno.chatras@ORANGE-F         cc:
>>>>
>>>>                       TGROUP.COM>
>>>>        
>> Subject: H.248 Ia
>>    
>>>> Profile Version 2
>>>>
>>>>
>>>>                       19.04.2007 11:12
>>>>
>>>>                       Please respond to
>>>>
>>>>                       CHATRAS Bruno
>>>>
>>>>                       RD-CORE-ISS
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Ray, Wayne,
>>>>
>>>> I just had a look to the Latest Draft of WI03098 (Ia
>>>>        
>> profile Release
>>    
>>>> 2)
>>>>        
>> and saw that support of the new IPDC package is mandatory
>> rather than optional.
>>    
>>>> This contradicts the Work Item description which says
>>>>        
>> explictly that
>> "The Ia profile version 2 shall maintain backwards
>> compatibility with version 1."  The meeting reports says that
>> adding the IPDC package was indeed agreed but does not say
>> whether it should be mandatory or optional.
>> I believe that we should either make this package optional or
>> made an attempt to modify the Work Item description. I assume
>> we can't approve a deliverable which explicitly contradicts a
>> Work Item description.
>>    
>>>> BTW, what is the procedure for TB approval of this modification.
>>>> There
>>>>        
>> does not seem to be any CR corresponding to this modification
>> (just a contribution).
>>    
>>>> Best regards
>>>> Bruno
>>>>
>>>>

####




        Christian Groves <Christian.Groves@nteczone.com>

        To:     CHATRAS Bruno RD-CORE-ISS <bruno.chatras@orange-ftgroup.com>
        cc:     "Wayne Cutler (CV/ETL)" <wayne.cutler@ericsson.com>, Neal ZhuNing <zhuning@huawei.com>, "Jerker Zetterlund (TN/EAB)" <jerker.zetterlund@ericsson.com>, seppo.kauntola@nsn.com, Albrecht.Schwarz@alcatel-lucent.de, CWaitzmann@alcatel-lucent.de, smaoui@nortel.com, Lin Yangbo <linyangbo@huawei.com>, Tommy Young <tommy@huawei.com>

        Subject:        Re: H.248 Ia Profile Version 2 


[attachment "iprealm_update.doc" deleted by Albrecht SCHWARZ/DE/ALCATEL]