For the record, I agree with Paul. The rational given for allowing octet 3a
is not sufficient to allow backward compatibility with an endpoint
conforming to v1, v2.
Perhaps it was wrong to not allow octet 3a.
It is wrong to allow something that was previously not allowed.
Two wrongs don't make a right!!!
Just for the record, I think in my implementation, it will be happy to have
as many octet 3a, 3b as you care to give it, but will just ignore them. As
the standard says there WILL BE NO octet 3as etc, IMO that's quite a
legitimate implementation (just a case of being tolerant of what you get).
However, as it doesn't know about octet 3as, it will present the information
anyway.
Thus a valid set of decisions (made without hindsight) doesn't give the
results that are desired. How can that be backward compatible???
Pete
=============================================
Pete Cordell
pete(a)tech-know-ware.com
=============================================
-----Original Message-----
From: Paul Long <plong(a)SMITHMICRO.COM>
To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM>
Date: 07 September 1999 20:20
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(a)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(a)ICN.Siemens.com
>------------------------------------------------------------------
>
>
>-----Original Message-----
>From: Paul Long [mailto:plong@SMITHMICRO.COM]
>Sent: Tuesday, September 07, 1999 1:08 PM
>To: ITU-SG16(a)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.
>
