Paul, Your logic is correct. I only attempted to provide you with a summary of the discussion in Santiago. There were a number of IEs that forbidden that were to be added in Berlin. This, in part, came about from one possible solution for transporting QSIG over H.323. Because there was no resolution to the primary question, the IE change was not accepted. This question is scheduled to return at Red Bank. That would be a good chance for your opinion to be heard. The worst case is that everything forbidden will be possible. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Business Communication Systems Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan@ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul Long [mailto:plong@SMITHMICRO.COM] Sent: Tuesday, September 07, 1999 3:13 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Pathological bearer cap changes in H.225.0v3 Bob, 1. But there has never been a requirement that components of IEs be treated like actual IEs. Where did this come from? This is a gross rationalization. The Recommendation clearly states that this octet shall not be encoded. Therefore, it is perfectly reasonable for an entity to assume that it will never encounter this octet. Geez, what are standards for? What other "shalls" will be relaxed in the future? 2. Even if IE components were to be treated like IEs--which they cannot--this would still not justify the removal of this requirement. H.225.0 says only that "unrecognized," e.g., new, IEs shall be ignored, not that well-known but otherwise clearly prohibited ones shall be ignored, which is what you are proposing. But please prove me wrong. Show me in the H.225.0 Recommendation where it says that 1. IE components, such as Octet 3a of bearer caps, shall be treated like IEs and 2. that well-known but otherwise prohibited IEs shall be ignored. BTW, our products in particular are okay in this regard--they will ignore optional IE fields, even the ones that are prohibited--so I'm not simply trying rationalize something to keep our products from becoming non-interoperable due to a bad design decision. It's just that I don't like the precedent this sets that it's okay to "change the rules once the game has started." I won't go on about this, though. I'm done. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Tuesday, September 07, 1999 12:58 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Pathological bearer cap changes in H.225.0v3 Paul, The question you present was covered in Santiago. The conclusion is that v1 and v2 devices should conform to the procedures for information elements that have content that is not understood. For information elements that are not defined as "must understand" (Calling party number is in this class) if the contents are not understood, then the information element shall be discarded and the connection is completed without this element. For the calling party number information element, if octet 3a is added in order to indicate "presentation restricted" and this in not understood; the calling party number ie is discarded and the connection is completed without this element. If the element is not present, then its contents may not be presented (No problem). Bob ------------------------------------------------------------------ Robert Callaghan Siemens Business Communication Systems Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan@ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul Long [mailto:plong@SMITHMICRO.COM] Sent: Tuesday, September 07, 1999 1:08 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Pathological bearer cap changes in H.225.0v3 I just took a look at the changes made to H.225.0v3 in Santiago. I noticed that whereas octet 3a of Calling Party Number in Bearer caps "Shall not be present" in H.225.0v1 and v2, it is allowed in v3! And this apparent oversight was not rectified in Berlin after discussion on this reflector. How will we now guarantee interoperability between v1, v2, and v3+ entities? What if some v1 or v2 entities were implemented according to the Recommendation and do not expect this octet to be present and indeed will fail through no fault of their own? Several alternatives were presented back in May. Why was the least interoperable solution kept? Paul Long Smith Micro Software, Inc.