Re: Interoperability Problems due to Open Type encoding of Null t ypes (fwd)
Hi All,
I am resending this mail as there does not seem to be a consensus on the defintion of "outermost" value as defined in X.691 specification. Any additional information which would help solve this issue is appreciated. It will help to mitigate one of the important issues affecting the interoperability across H.323 implementations. thanks Manoj.
-----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Friday, January 19, 2001 10:21 AM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Interoperability Problems due to Open Type encoding of Null t ypes (fwd)
Hi Scott,
We agree to your interpretation for case (1). However, for case (2) we believe that only Foo SEQUENCE should be considered the outermost value. And since it would not generate an empty bit string, no additional 0x00 octet should be added to the field-list. Why should v (NULL element) also considered as outermost value in this context since it appears within the extension root of Foo, isn't it? -Manoj
-----Original Message----- From: Bancroft Scott [mailto:baos@OSS.COM] Sent: Wednesday, January 17, 2001 8:58 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Interoperability Problems due to Open Type encoding of Null types (fwd)
On Wed, 17 Jan 2001, Manoj Paul wrote:
Experts,
We have come across a specific problem which has been the root cause of interoperability failures across different implementations of H.323 stack. The problem is related to the
- Encoding and decoding of NULL data types when they appear as
extension IEs. 2) Encoding and decoding of extension IEs which have NULL as the outermost ASN type.
There have been different interpretations of the PER rules that apply to the above conditions causing interop failures at encode/decode level. Although the implementations would encode/decode (1) and (2) according to Open Type elements, some subtle differences come as mentioned below:
In case of (1), some implementations would not encode an extra 0x00 octet for NULL data type and would just encode the length of the open type element as 0x00. This idea probably stems from the fact that a NULL data type has no encoding when they appear in the root of the ASN.1 type. However, as per 10.1.3 and 10.2.1 of X.691, the correct encoding for such a case would be 0x01 0x00, where 0x01 is the uncosntrained length of the NULL data type encoding and 0x00 is the value of NULL data type in extension.
Your understanding of the encoding is correct.
In case of (2), some implementations would encode the extension IE as per it's rules (e.g as a Choice/Sequence etc.), but would not add a 0x00 for the outermost NULL data type in it's encode tree. This would change the value of length field to be appended to this open type. Whereas some implementations do add 0x00 octet for the outermost NULL data type.
There appears to be a confusion as to what is meant by the "outermost" value in 10.1.3 of X.691. I would appreciate clarification on this clause as it would save a lot of interop overhead at encode/decode level.
"outermost" value refers to a value of a type that is either directly nested in an open type or is a complete application message unto itself. For example, if you had:
Foo ::= SEQUENCE { b BOOLEAN, v TYPE-IDENTIFIER.&Type, ..., i NULL }
bar Foo ::= {b TRUE, v NULL : NULL, i NULL}
The value of Foo, bar, is an outermost value. The value of v (NULL : NULL) is encoded as an outermost value, so in this case since NULL encodes to 0 bits it is replaced with eight 0-bits, and this is prefixed with a length of 1. Similarly, the value of i is encoded as an outermost value, so the resulting encoding in this case will have a length of 1 followed by eight 0-bits.
------------------------------------------------------------------------- Bancroft Scott Toll Free :1-888-OSS-ASN1 OSS Nokalva International:1-732-302-0750 baos@oss.com Tech Support :1-732-302-9669 x-1 1-732-302-9669 x-200 Fax :1-732-302-0023 http://www.oss.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Manoj,
Given Bancroft's role in the development of ASN.1, I'd say that whatever he says is probably true and most likely the intent if the text is not clear.
In any case, I would venture to guess that OSS is more widely used than any other ASN.1 PER encoder/decoder on the market. While it may not be appropriate to call their tools the "de facto" standard, they very much are (no disrespect intended to anyone). I would suggest that the text be clarified according to Bancroft's recommendation and that Implementers follow his advise, as I believe it would result in the widest possible interoperability.
Paul
----- Original Message ----- From: "Paul, Manoj" mpaul@TRILLIUM.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Thursday, February 01, 2001 3:34 PM Subject: Re: Interoperability Problems due to Open Type encoding of Null t ypes (fwd)
Hi All,
I am resending this mail as there does not seem to be a consensus on the defintion of "outermost" value as defined in X.691 specification. Any additional information which would help solve this issue is appreciated. It will help to mitigate one of the important issues affecting the interoperability across H.323 implementations. thanks Manoj.
-----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Friday, January 19, 2001 10:21 AM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Interoperability Problems due to Open Type encoding of Null t ypes (fwd)
Hi Scott,
We agree to your interpretation for case (1). However, for case (2) we believe that only Foo SEQUENCE should be considered the outermost value. And since it would not generate an empty bit string, no additional 0x00 octet should be added to the field-list. Why should v (NULL element) also considered as outermost value in this context since it appears within the extension root of Foo, isn't it? -Manoj
-----Original Message----- From: Bancroft Scott [mailto:baos@OSS.COM] Sent: Wednesday, January 17, 2001 8:58 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Interoperability Problems due to Open Type encoding of Null types (fwd)
On Wed, 17 Jan 2001, Manoj Paul wrote:
Experts,
We have come across a specific problem which has been the root cause of interoperability failures across different implementations of H.323 stack. The problem is related to the
- Encoding and decoding of NULL data types when they appear as
extension IEs. 2) Encoding and decoding of extension IEs which have NULL as the outermost ASN type.
There have been different interpretations of the PER rules that apply to the above conditions causing interop failures at encode/decode level. Although the implementations would encode/decode (1) and (2) according to Open Type elements, some subtle differences come as mentioned below:
In case of (1), some implementations would not encode an extra 0x00 octet for NULL data type and would just encode the length of the open
type
element as 0x00. This idea probably stems from the fact that a NULL data type has no encoding when they appear in the root of the ASN.1
type.
However, as per 10.1.3 and 10.2.1 of X.691, the correct encoding for such a case would be 0x01 0x00, where 0x01 is the uncosntrained length of the NULL data type encoding and 0x00 is the value of NULL data type
in
extension.
Your understanding of the encoding is correct.
In case of (2), some implementations would encode the extension IE as
per
it's rules (e.g as a Choice/Sequence etc.), but would not add a 0x00 for the outermost NULL data type in it's encode tree. This would change the value of length field to be appended to this open type. Whereas some implementations do add 0x00 octet for the outermost NULL data type.
There appears to be a confusion as to what is meant by the "outermost" value in 10.1.3 of X.691. I would appreciate clarification on this clause as it would save a lot of interop overhead at encode/decode
level.
"outermost" value refers to a value of a type that is either directly nested in an open type or is a complete application message unto itself. For example, if you had:
Foo ::= SEQUENCE { b BOOLEAN, v TYPE-IDENTIFIER.&Type, ..., i NULL } bar Foo ::= {b TRUE, v NULL : NULL, i NULL}The value of Foo, bar, is an outermost value. The value of v (NULL : NULL) is encoded as an outermost value, so in this case since NULL encodes to 0 bits it is replaced with eight 0-bits, and this is prefixed with a length of 1. Similarly, the value of i is encoded as an outermost value, so the resulting encoding in this case will have a length of 1 followed by eight 0-bits.
Bancroft Scott Toll Free :1-888-OSS-ASN1 OSS Nokalva International:1-732-302-0750 baos@oss.com Tech Support :1-732-302-9669 x-1 1-732-302-9669 x-200 Fax :1-732-302-0023 http://www.oss.com
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.comFor 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
On Fri, 2 Feb 2001, Paul E. Jones wrote:
Manoj,
Given Bancroft's role in the development of ASN.1, I'd say that whatever he says is probably true and most likely the intent if the text is not clear.
I have inputted this to the ASN.1 meeting that was held at the ITU-T in Geneva January 22 - February 2, and this will be clarified in an upcoming corrigendum.
In any case, I would venture to guess that OSS is more widely used than any other ASN.1 PER encoder/decoder on the market. While it may not be appropriate to call their tools the "de facto" standard, they very much are (no disrespect intended to anyone). I would suggest that the text be clarified according to Bancroft's recommendation and that Implementers follow his advise, as I believe it would result in the widest possible interoperability.
I'm cc'ing the ITU-T ASN.1 Rapporteur, Olivier Dubuisson, and the ISO/IEC ASN.1 Rapporteur, John Larmouth, in case they have anything to add.
Bancroft
Paul
----- Original Message ----- From: "Paul, Manoj" mpaul@TRILLIUM.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Thursday, February 01, 2001 3:34 PM Subject: Re: Interoperability Problems due to Open Type encoding of Null t ypes (fwd)
Hi All,
I am resending this mail as there does not seem to be a consensus on the defintion of "outermost" value as defined in X.691 specification. Any additional information which would help solve this issue is appreciated. It will help to mitigate one of the important issues affecting the interoperability across H.323 implementations. thanks Manoj.
-----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Friday, January 19, 2001 10:21 AM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Interoperability Problems due to Open Type encoding of Null t ypes (fwd)
Hi Scott,
We agree to your interpretation for case (1). However, for case (2) we believe that only Foo SEQUENCE should be considered the outermost value. And since it would not generate an empty bit string, no additional 0x00 octet should be added to the field-list. Why should v (NULL element) also considered as outermost value in this context since it appears within the extension root of Foo, isn't it? -Manoj
-----Original Message----- From: Bancroft Scott [mailto:baos@OSS.COM] Sent: Wednesday, January 17, 2001 8:58 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Interoperability Problems due to Open Type encoding of Null types (fwd)
On Wed, 17 Jan 2001, Manoj Paul wrote:
Experts,
We have come across a specific problem which has been the root cause of interoperability failures across different implementations of H.323 stack. The problem is related to the
- Encoding and decoding of NULL data types when they appear as
extension IEs. 2) Encoding and decoding of extension IEs which have NULL as the outermost ASN type.
There have been different interpretations of the PER rules that apply to the above conditions causing interop failures at encode/decode level. Although the implementations would encode/decode (1) and (2) according to Open Type elements, some subtle differences come as mentioned below:
In case of (1), some implementations would not encode an extra 0x00 octet for NULL data type and would just encode the length of the open
type
element as 0x00. This idea probably stems from the fact that a NULL data type has no encoding when they appear in the root of the ASN.1
type.
However, as per 10.1.3 and 10.2.1 of X.691, the correct encoding for such a case would be 0x01 0x00, where 0x01 is the uncosntrained length of the NULL data type encoding and 0x00 is the value of NULL data type
in
extension.
Your understanding of the encoding is correct.
In case of (2), some implementations would encode the extension IE as
per
it's rules (e.g as a Choice/Sequence etc.), but would not add a 0x00 for the outermost NULL data type in it's encode tree. This would change the value of length field to be appended to this open type. Whereas some implementations do add 0x00 octet for the outermost NULL data type.
There appears to be a confusion as to what is meant by the "outermost" value in 10.1.3 of X.691. I would appreciate clarification on this clause as it would save a lot of interop overhead at encode/decode
level.
"outermost" value refers to a value of a type that is either directly nested in an open type or is a complete application message unto itself. For example, if you had:
Foo ::= SEQUENCE { b BOOLEAN, v TYPE-IDENTIFIER.&Type, ..., i NULL } bar Foo ::= {b TRUE, v NULL : NULL, i NULL}The value of Foo, bar, is an outermost value. The value of v (NULL : NULL) is encoded as an outermost value, so in this case since NULL encodes to 0 bits it is replaced with eight 0-bits, and this is prefixed with a length of 1. Similarly, the value of i is encoded as an outermost value, so the resulting encoding in this case will have a length of 1 followed by eight 0-bits.
Bancroft Scott Toll Free :1-888-OSS-ASN1 OSS Nokalva International:1-732-302-0750 baos@oss.com Tech Support :1-732-302-9669 x-1 1-732-302-9669 x-200 Fax :1-732-302-0023 http://www.oss.com
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.comFor 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Sorry folks, but the basic question seems to be buried deep in the e-mail, and given we are hitting inter-working problems, it is clearly important.
What actually is the issue? Was it resolved last Friday? If not, can someone give a clear statement of the issue?
John L
Bancroft Scott wrote:
On Fri, 2 Feb 2001, Paul E. Jones wrote:
Manoj,
Given Bancroft's role in the development of ASN.1, I'd say that whatever he says is probably true and most likely the intent if the text is not clear.
I have inputted this to the ASN.1 meeting that was held at the ITU-T in Geneva January 22 - February 2, and this will be clarified in an upcoming corrigendum.
In any case, I would venture to guess that OSS is more widely used than any other ASN.1 PER encoder/decoder on the market. While it may not be appropriate to call their tools the "de facto" standard, they very much are (no disrespect intended to anyone). I would suggest that the text be clarified according to Bancroft's recommendation and that Implementers follow his advise, as I believe it would result in the widest possible interoperability.
I'm cc'ing the ITU-T ASN.1 Rapporteur, Olivier Dubuisson, and the ISO/IEC ASN.1 Rapporteur, John Larmouth, in case they have anything to add.
Bancroft
Paul
----- Original Message ----- From: "Paul, Manoj" mpaul@TRILLIUM.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Thursday, February 01, 2001 3:34 PM Subject: Re: Interoperability Problems due to Open Type encoding of Null t ypes (fwd)
Hi All,
I am resending this mail as there does not seem to be a consensus on the defintion of "outermost" value as defined in X.691 specification. Any additional information which would help solve this issue is appreciated. It will help to mitigate one of the important issues affecting the interoperability across H.323 implementations. thanks Manoj.
-----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Friday, January 19, 2001 10:21 AM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Interoperability Problems due to Open Type encoding of Null t ypes (fwd)
Hi Scott,
We agree to your interpretation for case (1). However, for case (2) we believe that only Foo SEQUENCE should be considered the outermost value. And since it would not generate an empty bit string, no additional 0x00 octet should be added to the field-list. Why should v (NULL element) also considered as outermost value in this context since it appears within the extension root of Foo, isn't it? -Manoj
-----Original Message----- From: Bancroft Scott [mailto:baos@OSS.COM] Sent: Wednesday, January 17, 2001 8:58 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Interoperability Problems due to Open Type encoding of Null types (fwd)
On Wed, 17 Jan 2001, Manoj Paul wrote:
Experts,
We have come across a specific problem which has been the root cause of interoperability failures across different implementations of H.323 stack. The problem is related to the
- Encoding and decoding of NULL data types when they appear as
extension IEs. 2) Encoding and decoding of extension IEs which have NULL as the outermost ASN type.
There have been different interpretations of the PER rules that apply to the above conditions causing interop failures at encode/decode level. Although the implementations would encode/decode (1) and (2) according to Open Type elements, some subtle differences come as mentioned below:
In case of (1), some implementations would not encode an extra 0x00 octet for NULL data type and would just encode the length of the open
type
element as 0x00. This idea probably stems from the fact that a NULL data type has no encoding when they appear in the root of the ASN.1
type.
However, as per 10.1.3 and 10.2.1 of X.691, the correct encoding for such a case would be 0x01 0x00, where 0x01 is the uncosntrained length of the NULL data type encoding and 0x00 is the value of NULL data type
in
extension.
Your understanding of the encoding is correct.
In case of (2), some implementations would encode the extension IE as
per
it's rules (e.g as a Choice/Sequence etc.), but would not add a 0x00 for the outermost NULL data type in it's encode tree. This would change the value of length field to be appended to this open type. Whereas some implementations do add 0x00 octet for the outermost NULL data type.
There appears to be a confusion as to what is meant by the "outermost" value in 10.1.3 of X.691. I would appreciate clarification on this clause as it would save a lot of interop overhead at encode/decode
level.
"outermost" value refers to a value of a type that is either directly nested in an open type or is a complete application message unto itself. For example, if you had:
Foo ::= SEQUENCE { b BOOLEAN, v TYPE-IDENTIFIER.&Type, ..., i NULL } bar Foo ::= {b TRUE, v NULL : NULL, i NULL}The value of Foo, bar, is an outermost value. The value of v (NULL : NULL) is encoded as an outermost value, so in this case since NULL encodes to 0 bits it is replaced with eight 0-bits, and this is prefixed with a length of 1. Similarly, the value of i is encoded as an outermost value, so the resulting encoding in this case will have a length of 1 followed by eight 0-bits.
Bancroft Scott Toll Free :1-888-OSS-ASN1 OSS Nokalva International:1-732-302-0750 baos@oss.com Tech Support :1-732-302-9669 x-1 1-732-302-9669 x-200 Fax :1-732-302-0023 http://www.oss.com
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.comFor 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
On Sat, 3 Feb 2001, John Larmouth wrote:
Sorry folks, but the basic question seems to be buried deep in the e-mail, and given we are hitting inter-working problems, it is clearly important.
What actually is the issue? Was it resolved last Friday? If not, can someone give a clear statement of the issue?
This pertains to the fact that "outermost" value is used in X.691 but not clearly defined. Below I indicate that this was discussed the first week of our meeting in Geneva and will be clarified in an upcoming corrigendum.
Bancroft
John L
Bancroft Scott wrote:
On Fri, 2 Feb 2001, Paul E. Jones wrote:
Manoj,
Given Bancroft's role in the development of ASN.1, I'd say that whatever he says is probably true and most likely the intent if the text is not clear.
I have inputted this to the ASN.1 meeting that was held at the ITU-T in Geneva January 22 - February 2, and this will be clarified in an upcoming corrigendum.
In any case, I would venture to guess that OSS is more widely used than any other ASN.1 PER encoder/decoder on the market. While it may not be appropriate to call their tools the "de facto" standard, they very much are (no disrespect intended to anyone). I would suggest that the text be clarified according to Bancroft's recommendation and that Implementers follow his advise, as I believe it would result in the widest possible interoperability.
I'm cc'ing the ITU-T ASN.1 Rapporteur, Olivier Dubuisson, and the ISO/IEC ASN.1 Rapporteur, John Larmouth, in case they have anything to add.
Bancroft
Paul
----- Original Message ----- From: "Paul, Manoj" mpaul@TRILLIUM.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Thursday, February 01, 2001 3:34 PM Subject: Re: Interoperability Problems due to Open Type encoding of Null t ypes (fwd)
Hi All,
I am resending this mail as there does not seem to be a consensus on the defintion of "outermost" value as defined in X.691 specification. Any additional information which would help solve this issue is appreciated. It will help to mitigate one of the important issues affecting the interoperability across H.323 implementations. thanks Manoj.
-----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Friday, January 19, 2001 10:21 AM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Interoperability Problems due to Open Type encoding of Null t ypes (fwd)
Hi Scott,
We agree to your interpretation for case (1). However, for case (2) we believe that only Foo SEQUENCE should be considered the outermost value. And since it would not generate an empty bit string, no additional 0x00 octet should be added to the field-list. Why should v (NULL element) also considered as outermost value in this context since it appears within the extension root of Foo, isn't it? -Manoj
-----Original Message----- From: Bancroft Scott [mailto:baos@OSS.COM] Sent: Wednesday, January 17, 2001 8:58 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Interoperability Problems due to Open Type encoding of Null types (fwd)
On Wed, 17 Jan 2001, Manoj Paul wrote:
Experts,
We have come across a specific problem which has been the root cause of interoperability failures across different implementations of H.323 stack. The problem is related to the
- Encoding and decoding of NULL data types when they appear as
extension IEs. 2) Encoding and decoding of extension IEs which have NULL as the outermost ASN type.
There have been different interpretations of the PER rules that apply to the above conditions causing interop failures at encode/decode level. Although the implementations would encode/decode (1) and (2) according to Open Type elements, some subtle differences come as mentioned below:
In case of (1), some implementations would not encode an extra 0x00 octet for NULL data type and would just encode the length of the open
type
element as 0x00. This idea probably stems from the fact that a NULL data type has no encoding when they appear in the root of the ASN.1
type.
However, as per 10.1.3 and 10.2.1 of X.691, the correct encoding for such a case would be 0x01 0x00, where 0x01 is the uncosntrained length of the NULL data type encoding and 0x00 is the value of NULL data type
in
extension.
Your understanding of the encoding is correct.
In case of (2), some implementations would encode the extension IE as
per
it's rules (e.g as a Choice/Sequence etc.), but would not add a 0x00 for the outermost NULL data type in it's encode tree. This would change the value of length field to be appended to this open type. Whereas some implementations do add 0x00 octet for the outermost NULL data type.
There appears to be a confusion as to what is meant by the "outermost" value in 10.1.3 of X.691. I would appreciate clarification on this clause as it would save a lot of interop overhead at encode/decode
level.
"outermost" value refers to a value of a type that is either directly nested in an open type or is a complete application message unto itself. For example, if you had:
Foo ::= SEQUENCE { b BOOLEAN, v TYPE-IDENTIFIER.&Type, ..., i NULL } bar Foo ::= {b TRUE, v NULL : NULL, i NULL}The value of Foo, bar, is an outermost value. The value of v (NULL : NULL) is encoded as an outermost value, so in this case since NULL encodes to 0 bits it is replaced with eight 0-bits, and this is prefixed with a length of 1. Similarly, the value of i is encoded as an outermost value, so the resulting encoding in this case will have a length of 1 followed by eight 0-bits.
Bancroft Scott Toll Free :1-888-OSS-ASN1 OSS Nokalva International:1-732-302-0750 baos@oss.com Tech Support :1-732-302-9669 x-1 1-732-302-9669 x-200 Fax :1-732-302-0023 http://www.oss.com
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.comFor 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--
Prof John Larmouth1 Blueberry Road, Bowdon, Altrincham, Cheshire WA14 3LS, England. j.larmouth @ salford.ac.uk Tel: +44 161 928 1605 Fax (work): +44 161 745 8169 Tel (work): +44 161 295 5657
participants (5)
-
Bancroft Scott -
Bancroft Scott
-
John Larmouth -
Paul E. Jones -
Paul, Manoj