H.248 Annex C Codepoint Information
H.248 Annex C is by concept derivative in nature -- it provides the means to reuse codepoints from a variety of other standards. As it currently stands, it reproduces these codepoints in the "Value" column. I am concerned that this could present a maintenance nightmare. It would make more sense to point the user to the specific reference in the other standard and leave it at that. Tom Taylor Phone and FAX: +1 613 736 0961 E-mail: taylor@nortelnetworks.com
Hello Tom, References are included in Annex C and the text at the start says that the reference is the normative text. I personally would envision that most changes to codepoints would be contained in packages. ie. if we use packages for defining properties then we align the text and binary encodings of H248. That way we don't need to continuously update SDP and Annex C to match. Regards, Christian Tom-PT Taylor wrote:
H.248 Annex C is by concept derivative in nature -- it provides the means to reuse codepoints from a variety of other standards. As it currently stands, it reproduces these codepoints in the "Value" column. I am concerned that this could present a maintenance nightmare. It would make more sense to point the user to the specific reference in the other standard and leave it at that.
Tom Taylor Phone and FAX: +1 613 736 0961 E-mail: taylor@nortelnetworks.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Hi, I was going to say the same thing as Christian (but strange telephone sockets in the UK kept me from doing so): if a reference is provided, the values listed in the value column serve as examples only; normative text is in the references as indicated at the start of the annex. The second point Christian mentioned is an interesting one. Is the idea that if one defines a package for which there is already an annex C codepoint, the package would just refer to that instead of defining a new codepoint? If that is the intention, we'd better give annex C a package name... Cheers, John Christian Groves wrote:
Hello Tom,
References are included in Annex C and the text at the start says that the reference is the normative text. I personally would envision that most changes to codepoints would be contained in packages. ie. if we use packages for defining properties then we align the text and binary encodings of H248. That way we don't need to continuously update SDP and Annex C to match.
Regards, Christian
Tom-PT Taylor wrote:
H.248 Annex C is by concept derivative in nature -- it provides the means to reuse codepoints from a variety of other standards. As it currently stands, it reproduces these codepoints in the "Value" column. I am concerned that this could present a maintenance nightmare. It would make more sense to point the user to the specific reference in the other standard and leave it at that.
Tom Taylor Phone and FAX: +1 613 736 0961 E-mail: taylor@nortelnetworks.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
-- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
G'Day John, In the binary Annex C already has a packageID '0'. If people want a package name then I'm not adverse to that. My second point was that new packages could redefine the parameters in an appropriately grouped package. This way we get over the problems associated with a Q.931v7 problem Tom was alluding to. Annex C was a toolkit of parameters that could be used in the early stages of the protocol. To achieve true interoperability for applications and symmetry between text and binary I believe that Profiles containing packages and options is the only way to go. Cheers, Christian John Segers wrote:
Hi,
I was going to say the same thing as Christian (but strange telephone sockets in the UK kept me from doing so): if a reference is provided, the values listed in the value column serve as examples only; normative text is in the references as indicated at the start of the annex.
The second point Christian mentioned is an interesting one. Is the idea that if one defines a package for which there is already an annex C codepoint, the package would just refer to that instead of defining a new codepoint? If that is the intention, we'd better give annex C a package name...
Cheers,
John
Christian Groves wrote:
Hello Tom,
References are included in Annex C and the text at the start says that the reference is the normative text. I personally would envision that most changes to codepoints would be contained in packages. ie. if we use packages for defining properties then we align the text and binary encodings of H248. That way we don't need to continuously update SDP and Annex C to match.
Regards, Christian
Tom-PT Taylor wrote:
H.248 Annex C is by concept derivative in nature -- it provides the means to reuse codepoints from a variety of other standards. As it currently stands, it reproduces these codepoints in the "Value" column. I am concerned that this could present a maintenance nightmare. It would make more sense to point the user to the specific reference in the other standard and leave it at that.
Tom Taylor Phone and FAX: +1 613 736 0961 E-mail: taylor@nortelnetworks.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
-- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (3)
-
Christian Groves -
John Segers -
Tom-PT Taylor