T.38 potentially broken by recent Corrigendum

[James Rafferty]

Kevin , 
 
Glenn Parsons, Dave Duehren and I have all pointed out that the ellipsis was
supposed to be
there but was dropped by the TSB during publication.   We had a
Rapporteur's/ Working Party meeting in 
in Fall 1999 that confirmed the need to reinstate it.  The driver for the
reinstatement was based on 
the need we foresaw to extend T.38 to support new features such as V.34 fax.

 
And yes, we all tried to let people know about the issue at the time.   But,
it did take a while
for the ITU to document the change, which has created today's issue.   In a
related vein,
the fax question also saw that there were variations emerging as new T.38
features emerged, such
as the TPKT support for TCP/IP, so we agreed to start adding a version to
the T.38.   
 
New implementations will need to recognize that there are different versions
of T.38 in order to gain 
proper interoperation.   IP call control will also need to expose versions
during negotiations if
interoperability is to be assured.   
 
Given where we are, the relevant questions will need to sort this out at the
next SG16 meeting
in May.    Gaining a rough consensus on how to resolve it before then would
be a good thing.   
 
James

-----Original Message-----
From: Kevin Boyle [mailto:kboyle at nortelnetworks.com]
Sent: Friday, March 14, 2003 9:16 AM
To: ITU-SG16 at echo.jf.INTEL.COM
Subject: Re: T.38 potentially broken by recent Corrigendum


All,
 
It is my understanding that the ellipsis was intended to be there, and that
it wasn't until folks started implementing that it was noticed that it got
dropped somewhere between the editor's hands and publication. There was a TD
in the Feb 2000 meeting noting this typo.  I can produce it if anyone wants
to see it.
 
It is also my understanding that care was taken to ensure that all known
vendors were made aware of the change at the time.
 
Kevin

-----Original Message-----
From: Klaghofer Karl ICN EN HS D 11 [mailto:karl.klaghofer at SIEMENS.COM] 
Sent: Friday, March 14, 2003 3:44 AM
To: ITU-SG16 at echo.jf.INTEL.COM
Subject: AW: T.38 potentially broken by recent Corrigendum


Paul,
 
I fully agree with you, that the T.38 (1998) asn.1 and the Revision of T.38
(2002) asn.1 needs to be backwards compatible. 
 
Regards,
Karl Klaghofer
Siemens

-----Ursprüngliche Nachricht-----
Von: Paul E. Jones [mailto:paulej at PACKETIZER.COM]
Gesendet: Montag, 3. März 2003 03:21
An: ITU-SG16 at echo.jf.INTEL.COM
Betreff: T.38 potentially broken by recent Corrigendum



Folks,
 
I just recently discovered that the ITU-T published a corrigendum to T.38
(1998) that apparently breaks backward compatibility for all T.38 devices
currently deployed that follow the original 1998 specifications.  The
particular document in question is Corrigendum 1, which was approved in 2000
and subsequently published in May 2001.  You can download the corrigendum
document for free from this site:
http://www.itu.int/rec/recommendation.asp?type=folders
<http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-
T.38> &lang=e&parent=T-REC-T.38 
 
The issue at hand is a change in the ASN.1 syntax found in Annex A/T.38.
The particular data structure is shown here:
 

Data-Field ::= SEQUENCE OF SEQUENCE
{
    field-type ENUMERATED
    {
        hdlc-data,
        hdlc-sig-end,
        hdlc-fcs-OK,
        hdlc-fcs-BAD,
        hdlc-fcs-OK-sig-end,
        hdlc-fcs-BAD-sig-end,
        t4-non-ecm-data,
        t4-non-ecm-sig-end,
        ...
    },
    field-data OCTET STRING (SIZE(1..65535)) OPTIONAL
}
 

The syntactical change was the addition of an ellipsis at the end of the
ENUMERATED "field-type".  In the published 1998 specification, this ellipsis
did not exist.
 
What I would like to know is whether this change impacts your product or
not.  I am aware of many deployed devices on the market today that employs
the 1998 syntax without this ellipsis.  I would like to find out to what
extent this change is going to present problems for companies represented on
various lists and, if I get sufficient support, I want to take a
contribution to the ITU-T SG16 meeting in May to try to resolve this problem
in such a way as to not break backward compatibility and interoperability.
 
I am looking forward to your replies.
 
Kindest Regards,
Paul E. Jones
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For
help on this mail list, send "HELP ITU-SG16" in a message to
listserv at lists.intel.com 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For
help on this mail list, send "HELP ITU-SG16" in a message to
listserv at lists.intel.com 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For
help on this mail list, send "HELP ITU-SG16" in a message to
listserv at lists.intel.com 


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at lists.intel.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20030314/e3f9e245/attachment-0001.htm>