December 1997 - sg16-avd - lists.packetizer.com

Re: Limitation of nonStandardData
by Bancroft Scott 05 Dec '97

05 Dec '97

On Thu, 4 Dec 1997, Paul Long wrote: > Paul Long wrote: > > > 4. As I understand it, for some strange reason, because the order of the > > > members of a SET OF is intended to be un-important the compiler takes it > > > upon itself to sort the values entered into some form of order!!! This > > > seems a waste of time and is a step best avoided by using SEQUENCE OF. > > > > I've never heard of this before. I'll check with Bancroft. Sounds like a > > bug in the OSS compiler, which by the way we don't use for reasons like > > this. > > [Bancroft's response follows. Apparently there is no reason _not_ to use > SET OF, because H.245, and H.225.0, and presumably H.450 use BASIC PER, > not CANONICAL PER, so there is no sorting.] > > This is true in the case of DER, which mandates this behavior. DER > encoders does not take it upon themselves to do this; it is required in > order to produce a valid DER encoding. This is also true in the case of > CER and the canonical variants of PER. It is not true for the > non-canonical variants of PER or for BER. > > As far as the OSS ASN.1 Tools go, DER is supported, so here SET OF's are > sorted as required. The OSS ASN.1 Tools at this time does not support > the canonical variants of PER, so no such sorting occurs for PER. Since > all the sorting algorithms are in place for DER, it is easy to provide > canonical PER support if it is required. I rarely recommend use of SET OF, for I can never tell when an existing standard is going to be used in the future for the base of another standard that happens to use DER, CER or canonical PER. Sticking to a semantically pure choice (i.e., SET OF) at this point can thus later result in either redefinition of the standard you are creating or in the future standard taking the CPU hit. On the other hand, if one is creating a standard that they *know* makes sense only using DER, CER or canonical PER (e.g., X.509), then a SET OF is actually a good thing for types whose values for some reason should be sorted in ascending order. In these cases SET OF is a good idea because based on the toolkit you are using the sort will be performed for you without your having to write added code. What I say here also applies to SET, which requires no sort of any kind in PER, but which can have unnecessary CPU and coding overhead for DER encoders which are required to sort it, and for BER decoders which have unnecessary CPU and coding overhead because the SET components can appear in any order. Most folks don't think that their ASN.1 specs will see life beyond their immediate application, but in practice the more successfully specs get used over and over again, often in ways that the authors never imagined. To allow such reuse is the reason I don't suggest use of SET, ever, and of SET OF only after serious thought. -------------------------------------------------------------------------- Bancroft Scott Toll Free :1-888-OSS-ASN1 Open Systems Solutions, Inc. International:1-609-987-9073 baos(a)oss.com Tech Support :1-732-249-5107 http://www.oss.com Fax :1-732-249-4636

1 0

Re: Limitation of nonStandardData
by Pete Cordell 05 Dec '97

05 Dec '97

Jim, Scott, Douglas, Paul,..... To answer Paul's question about the need for the change first: We are mainly interested in gatekeepers. We have a need to ship nonStandard information between cooperating gatekeepers, particularly in the SETUP message. However, endpoints may also wish to ship their own nonStandard information which the gatekeeper doesn't want to stamp on (because I'm a nice guy!). Hence we both have a need to use a field that is only intended to carry one value. This helps identify a suitable syntax for the data that goes into the data part of nonStandard data, as I believe we need to cater for both the nested form (for backwards compatibility) and multiple pieces of nonStandard data without any particular order. To do this, I propose that the piece of ASN.1 put in the data part of nonStandardParameter should be: ExtendedNonStandardData ::= SEQUENCE { previousNonStandard NonStandardParameter OPTIONAL, extraNonStandard SEQUENCE OF NonStandardParameter, ... } This would be used as follows: A V1 endpoint could put its own piece of nonStandardData into the existing nonStandard field. When a gatekeeper (or something else) received it, it would take the data from the existing nonStandard field and put it in the previousNonStandard field of the above SEQUENCE. It would then add whatever nonStandard stuff it needed to the extraNonStandard bit. It would put the combined nonStandard data in the data part of the nonStandardParameter and give it the tag that we decide on. On the other side a gatekeeper could see that the extraNonStandard related to it, and remove parts the parts that it needed to. If all that was left was the previousNonStandard part, then it would use this to recover what was the original format of the nonStandard message. This allows endpoints to send nonStandardData transparently, but also allows gatekeepers to get in on the act. As far as how this is captured in the standard, this seems a fairly important feature for H.225. I think we should include this as a separate root in the H.225 ASN.1 and give a fairly official OBJECT IDENTIFIER (e.g. {itu-t (0) recommendation (0) h(8) 2250} which shouldn't clash with anything in the context that we are using it). I've used an unconstrained SEQUENCE OF for the following reasons: 1. No other SEQUENCE OFs are bounded within H.225. 2. Size constraints on SEQUENCE OF are not always that useful (especially in the case of H.245!) 3. We have no other SET OFs in H.225 4. As I understand it, for some strange reason, because the order of the members of a SET OF is intended to be un-important the compiler takes it upon itself to sort the values entered into some form of order!!! This seems a waste of time and is a step best avoided by using SEQUENCE OF. Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Paul Long[SMTP:plong@SMITHMICRO.COM] >Sent: 02 December 1997 21:05 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Limitation of nonStandardData > >Scott Petrack wrote: >> This problem has bothered me for a long time. I considered many times >> introducing into the VoIP Forum an OID which would be used precisely as Jim >> suggests, so that the entire industry could signal a SEQUENCE of >> NonStandardParameter. > >So do you mean something like this?: > > NonStandardParameter ::=SEQUENCE > { > nonStandardIdentifier NonStandardIdentifier, -- e.g., VoIP OID > data OCTET STRING > } > >where data contains the following: > > SET SIZE (1..256) OF NonStandardParameter > >BTW, I believe that it should be a SET OF and not a SEQUENCE OF, >because >SEQUENCE OF implies that the order is important, and I don't think that >is the intent here. Or is it? > >One way to handle this for _future_ syntax is to define a type that is >itself a set of NonStandardParameters, as in: > > NonStandardParameters ::=SEQUENCE > { > nonStandardParameters SET SIZE (1..256) OF NonStandardParameter > } > >> One example of why this is necessary is so that when someone else uses our >> stack we can both pass non-standard parameters. > >Just to play devil's advocate, can you give an example of a specific >need for this? A quick review of H.245 didn't turn up very many >situations where aggregation isn't handled already at a higher level or >where it just doesn't make sense in the first place. > >Here is an example of where iteration is expressed at a higher level. >The capability table contains multiple capabilities, so there is no >need >for a single capability containing multiple NonStandardParameters--just >add more nonStandard capabilities. Case in point: it makes no sense, >IMO, for UserInputCapability to have a nonStandard CHOICE of multiple >NonStandardParameters, when multiple nonStandard UserInputCapabilities >would have served just as well. I agree with Dykstra--_I don't like >more >than one way of doing the same thing._ > >An example of where multiple NonStandardParameters may not make sense >in >the first place is in the NonStandardMessage type. Is there ever a need >to combine several NonStandardParameters in the same RequestMessage, >for >example? IOW, these uses are atomic. > >-- >Paul Long___________________________http://www.cmpu.net/public/plong >Smith Micro Software, Inc.__________http://www.smithmicro.com/ >

3 3

Re: Limitation of nonStandardData
by Pete Cordell 04 Dec '97

04 Dec '97

Douglas, I couldn't have said it better... As far as constraints and SETs etc.... Paul, It's funny you mentioned 32MB because that's exactly how big an H.245 structure came out when we compiled it! Perhaps we did something wrong, but now we have gone to linked lists and its all hunky dory. My feeling is that if you use the fixed size constraints you are guaranteed to waste memory in systems that can't afford to waste it. What you need is a size constraint for the entire decoded message. Unfortunately ASN.1 does not give you such a feature. Woops, I have to take back what I said about the encoding of SET OF. It came from my hazy memory of the following paragraph from X.691: 21 Encoding the set-of type 21.1 For CANONICAL-PER the encoding of the component values of the set-of type shall appear in ascending order, the component encodings being compared as bit strings padded with as many as seven 0 bits to an octet boundary. NOTE - Any pad bits added to achieve octet alignment for the sort do not appear in the actual encoding. 21.2 For BASIC-PER the set-of shall be encoded as if it had been declared a sequence-of type. However, we are using the BASIC for so there shouldn't be a problem. For what it's worth, I agree that ERROR propagation is not a good thing, but, based on the premise that exceptional cases introduce bugs, SUB-OPTIMALITY propagation is not always a bad thing if it leads to consistency!!! Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Douglas Clowes[SMTP:dclowes@OZEMAIL.COM.AU] >Sent: 04 December 1997 01:22 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Limitation of nonStandardData > >Paul, > >There seems to be a mismatch in the understanding here and I'm not sure >that it isn't me. So I'll give my version the understanding and hope to >be >corrected where I'm wrong. (BTW, I don't understand what the '...' in >the >ASN.1 does and why it's in the middle of the H.323 V2 stuff.) > >At 13:25 3/12/97 -0800, Paul Long wrote: >>Pete Cordell wrote: >>> We are mainly interested in gatekeepers. We have a need to ship >>> nonStandard information between cooperating gatekeepers, particularly in >>> the SETUP message. >> >>Okay, I see that H.225.0 apparently wasn't engineered for multiple >>nonStandardParameters, whereas H.245 at least originally was, but at a >>higher level, not merely a SET OF NonStandardParameters. I agree that >>this is a problem in H.225.0, but I don't think there is a problem with >>H.245, unless someone can give me specific examples. >> > >The problem tends to arise in a channel where there are multiple nodes. >This could be true of RAS if there is a hierarchy of gatekeepers. It is >true of of the Call Signalling Channel and the H.245 Control Channel >when >going via one or more gatekeepers, proxies or other devices. > >An obvious problem arises in the following situation. Two endpoints >require >a NonStandardParameter in the Q.931 SETUP message so that they can >cooperative complete a connection. Two intermediate (to the endpoints) >and >cooperative gatekeepers require to add a NonStandardParameter for their >participation in the SETUP process. Two intermediate (to the >gatekeepers) >and cooperative proxies require to add a NonStandardParameter for their >own >use. The problem arises when the intermediaries throw away the >NonStandardParameter already in the message and substitute their own >because the syntax only allows one NonStandardParameter. > >I don't understand how H.245 intrinsically solves this problem for, >say, >OpenLogicalChannel. > >>> To do this, I propose that the piece of ASN.1 put in the data part of >>> nonStandardParameter should be: >>> >>> ExtendedNonStandardData ::= SEQUENCE >>> { >>> previousNonStandard NonStandardParameter OPTIONAL, >>> extraNonStandard SEQUENCE OF NonStandardParameter, >>> ... >>> } >> >>Please constrain this aggregate with something like this: >> extraNonStandard SET SIZE (0..255) OF NonStandardParameter, >> > >Given that a NonStandardParameter contains a data field that is an >unconstrained OCTET STRING, I don't see the point of arbitrarily >constraining the number of them. > >>> A V1 endpoint could put its own piece of nonStandardData into the >>> existing nonStandard field. When a gatekeeper (or something else) >>> received it, it would take the data from the existing nonStandard field >>> and put it in the previousNonStandard field of the above SEQUENCE. >> >>Copying it or moving it? IOW, would the original nonStandardData still >>be present? >> > >The original nonStandardData is moved, by the first gateway of the >above >example, into the previousNonStandard field. This allows the first >gateway >to add its own NonStandardParameter to the extraNonStandard field. > >The whole ExtendedNonStandardData is placed in the data field of the V1 >NonStandardParameter which is included in the original message in place >of >the original nonStandardData. > >The first proxy does exactly the same thing. > >The message is still V1 compliant so if it goes through anything else >that >cares, it still sees a standard V1 message with the single >NonStandardParameter allowed in the standard and, hopefully, passes it >on >to the second proxy. > >The second proxy recognizes the NonStandardparameter as its very own >and >unwraps it to reveal, in the previousNonStandard field, the >NonStandardParameter that the first proxy received from the first >gatekeeper. It takes its own stuff out and restores the >NonStandardparameter from the previousNonStandard field, places it in >the >outgoing message as the one and only NonStandardParameter allowed in >the >message and sends it to the second gatekeeper. > >The second gatekeeper does exactly the same thing. The message that it >sends to the second endpoint contains the original (from the first >endpoint) NonStandardparameter as received by the first gatekeeper. > >>> It would then add whatever nonStandard stuff it needed to the >>> extraNonStandard bit. It would put the combined nonStandard data in the >>> data part of the nonStandardParameter and give it the tag that we decide >>> on. >> >>I don't understand, why have "previousNonStandard?" Why not just have a >>single nonStandard SET SIZE (0..255) OF NonStandardParameter, and simply >>append any GK stuff to the end? Also, as someone said previously in this >>thread, what if a third-party stack uses the single, original >>NonStandardParameter, yet the layer above that stack also wishes to >>include NonStandardParameters. Sounds like NonStandardParameters can be >>added and removed at any point in the data path, not just by GKs. >> > >In V1, there is only a single nonStandard, not a set of them. To >include a >NonStandardParameter where there alreay is one requires the original to >be >discarded which is the root of the problem. To extend the standard to >have >a SET or SEQUENCE OF is a possible solution to the problem. If the >message >goes through something that only tollerates a single >NonStandardParameter >as specified in the standard, there could be a problem. > >[cut] > >>> I've used an unconstrained SEQUENCE OF for the following reasons: >>> 1. No other SEQUENCE OFs are bounded within H.225. >> >>They should have been, and this will cause implementation problems down >>the line. Each vendor guesses what the max should be. Although all >>guesses are equally "correct," some will be too low and could cause the >>system to fail through no fault of the vendor. Remember that not all >>implementations will have 32MB of RAM and all the virtual memory they >>need. >> > >I understand your concern but, again, the NonStandardParameter is >unbounded >(if I correctly interpret 'OCTET STRING') and so, limiting the number >of >them to 255 doesn't add a lot and imposes an arbitrary constraint. > >>> 2. Size constraints on SEQUENCE OF are not always that useful >>> (especially in the case of H.245!) >> >>I have no idea what you mean by this. There are always real size >>constraints--no system has infinite resources. It would just be nice if >>the constraints were agreed upon and stated up front in the >>Recommendation. >> > >If you impose limitations that fit the lowest hardware of today, they >will >be innappropriate for the hardware of this afternoon. If you set the >limits >to handle the growth, does it help today. Say we imposed a limit of a >4GB >today, would it help. If we made that limit 16K today, how would that >impact us later? > >>> 3. We have no other SET OFs in H.225 >> >>So error propagation is a good thing, right? :-) >> > >This bit I agree with, so it probably means I don't understand the >finer >points of difference between sequences and sets, right? :-) > >>> 4. As I understand it, for some strange reason, because the order of the >>> members of a SET OF is intended to be un-important the compiler takes it >>> upon itself to sort the values entered into some form of order!!! This >>> seems a waste of time and is a step best avoided by using SEQUENCE OF. >> >>I've never heard of this before. I'll check with Bancroft. Sounds like a >>bug in the OSS compiler, which by the way we don't use for reasons like >>this. >> > >Sounds like a problem with implementation in a particular compiler, not >a >good basis for setting the direction of a standard. I think that the >*best* >way to avoid such a problem is to fix or replace the compiler. > > >Regards, > >Douglas Clowes >

1 0

Re: Limitation of nonStandardData
by Pete Cordell 04 Dec '97

04 Dec '97

Ernst, Firstly, I don't think there is a problem with H.245 and the changes proposed by Karl look good to me for H.450.x. Only H.225 needs attention. I had assumed that the gatekeepers knew about each other. I agree the solution I proposed doesn't work for the scenario you described, but I'm not sure that it is soluble within the constraints of the existing nonStandardData field. I had considered suggesting something like extraNonStandard in the H323-UU-PDU field, but I thought others might object. However, it makes sense to me! Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Ernst Horvath[SMTP:Ernst.Horvath@SIEMENS.AT] >Sent: 04 December 1997 10:35 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Limitation of nonStandardData > >Pete, > >maybe I misunderstand the whole matter, but I think all proposals so >far >have a problem with backward compatibility. Let me summarize how I see >the situation: > >If nonStandardData is essential for a call, the call will not succeed >unless both ends have a common understanding of the nonStandardData. > >But there may be cases where a rudimentary service can be provided >based >on standard data, and nonStandardData provide additional value if both >ends understand it. I.e., an endpoint can communicate with endpoints >from other vendors, but if it communicates with an endpoint from the >same vendor some additional proprietary features are available. This is >the idea behind the extension fields in H.450.x. > >Now, regarding the limitation problem: > >- In H.450.x the limitation concerns only Type NonStandardParameter, >extensions in the ISO style can already be repeated. If there is >sufficient justification, I am sure we remove the limitation before >publication, along the lines indicated by Karl. > >- In H.245, I noticed there are already SEQUENCE OF >NonStandardParameter >at various places, so I assume there is no problem. > >- In H.225.0, we should aim for backwards compatibility. This >eliminates >the possibilty to replace NonStandardParameter by a SET OF or SEQUENCE >OF NonStandardParameter. > >But your proposal of embedding a new structure into the data part of >NonStandardParameter has a similar problem: Suppose a V1 endpoint sends >nonStandardData, and a V2 gatekeeper replaces it with another element >(with another identifier), containing the original nonStandardData in >the previousNonStandard field. There is no guarantee that another GK >unwraps the original nonStandardData again, in which case the new >element will end up at the destination endpoint. If this is V1 it will >not recognize this element, although it may well understand the >original >nonStandardData wrapped inside it. So it cannot act on the information. > >In my opinion, the only way to achieve backwards compatibility is to >add >extraNonStandard as a new element, and there are many places where this >has to be done! > >Example: > >McuInfo ::= SEQUENCE >{ > nonStandardData NonStandardParameter OPTIONAL, > ..., > extraNonStandard SEQUENCE OF NonStandardParameter OPTIONAL >} > >Ernst >================================ >Ernst Horvath >Siemens AG >Tel: +43 1 1707 45897 >Fax: +43 1 1707 56992 >enail: ernst.horvath(a)siemens.at >================================ > >Pete Cordell wrote: >> >> Jim, Scott, Douglas, Paul,..... >> >> To answer Paul's question about the need for the change first: >> >> We are mainly interested in gatekeepers. We have a need to ship >> nonStandard information between cooperating gatekeepers, particularly >in >> the SETUP message. However, endpoints may also wish to ship their own >> nonStandard information which the gatekeeper doesn't want to stamp on >> (because I'm a nice guy!). Hence we both have a need to use a field >> that is only intended to carry one value. >> >> This helps identify a suitable syntax for the data that goes into the >> data part of nonStandard data, as I believe we need to cater for both >> the nested form (for backwards compatibility) and multiple pieces of >> nonStandard data without any particular order. >> >> To do this, I propose that the piece of ASN.1 put in the data part of >> nonStandardParameter should be: >> >> ExtendedNonStandardData ::= SEQUENCE >> { >> previousNonStandard NonStandardParameter OPTIONAL, >> extraNonStandard SEQUENCE OF NonStandardParameter, >> ... >> } >> >> This would be used as follows: >> >> A V1 endpoint could put its own piece of nonStandardData into the >> existing nonStandard field. When a gatekeeper (or something else) >> received it, it would take the data from the existing nonStandard >field >> and put it in the previousNonStandard field of the above SEQUENCE. It >> would then add whatever nonStandard stuff it needed to the >> extraNonStandard bit. It would put the combined nonStandard data in >the >> data part of the nonStandardParameter and give it the tag that we >decide >> on. >> >> On the other side a gatekeeper could see that the extraNonStandard >> related to it, and remove parts the parts that it needed to. If all >> that was left was the previousNonStandard part, then it would use this >> to recover what was the original format of the nonStandard message. >> This allows endpoints to send nonStandardData transparently, but also >> allows gatekeepers to get in on the act. >> >> As far as how this is captured in the standard, this seems a fairly >> important feature for H.225. I think we should include this as a >> separate root in the H.225 ASN.1 and give a fairly official OBJECT >> IDENTIFIER (e.g. {itu-t (0) recommendation (0) h(8) 2250} which >> shouldn't clash with anything in the context that we are using it). >> >> I've used an unconstrained SEQUENCE OF for the following reasons: >> 1. No other SEQUENCE OFs are bounded within H.225. >> 2. Size constraints on SEQUENCE OF are not always that useful >> (especially in the case of H.245!) >> 3. We have no other SET OFs in H.225 >> 4. As I understand it, for some strange reason, because the order of >the >> members of a SET OF is intended to be un-important the compiler takes >it >> upon itself to sort the values entered into some form of order!!! >This >> seems a waste of time and is a step best avoided by using SEQUENCE OF. >> >> Pete >> ================================= >> Pete Cordell >> BT Labs >> E-Mail: pete.cordell(a)bt-sys.bt.co.uk >> Tel: +44 1473 646436 >> Fax: +44 1473 645499 >> ================================= >> >

1 0

Re: Limitation of nonStandardData
by Ernst Horvath 04 Dec '97

04 Dec '97

Pete, maybe I misunderstand the whole matter, but I think all proposals so far have a problem with backward compatibility. Let me summarize how I see the situation: If nonStandardData is essential for a call, the call will not succeed unless both ends have a common understanding of the nonStandardData. But there may be cases where a rudimentary service can be provided based on standard data, and nonStandardData provide additional value if both ends understand it. I.e., an endpoint can communicate with endpoints from other vendors, but if it communicates with an endpoint from the same vendor some additional proprietary features are available. This is the idea behind the extension fields in H.450.x. Now, regarding the limitation problem: - In H.450.x the limitation concerns only Type NonStandardParameter, extensions in the ISO style can already be repeated. If there is sufficient justification, I am sure we remove the limitation before publication, along the lines indicated by Karl. - In H.245, I noticed there are already SEQUENCE OF NonStandardParameter at various places, so I assume there is no problem. - In H.225.0, we should aim for backwards compatibility. This eliminates the possibilty to replace NonStandardParameter by a SET OF or SEQUENCE OF NonStandardParameter. But your proposal of embedding a new structure into the data part of NonStandardParameter has a similar problem: Suppose a V1 endpoint sends nonStandardData, and a V2 gatekeeper replaces it with another element (with another identifier), containing the original nonStandardData in the previousNonStandard field. There is no guarantee that another GK unwraps the original nonStandardData again, in which case the new element will end up at the destination endpoint. If this is V1 it will not recognize this element, although it may well understand the original nonStandardData wrapped inside it. So it cannot act on the information. In my opinion, the only way to achieve backwards compatibility is to add extraNonStandard as a new element, and there are many places where this has to be done! Example: McuInfo ::= SEQUENCE { nonStandardData NonStandardParameter OPTIONAL, ..., extraNonStandard SEQUENCE OF NonStandardParameter OPTIONAL } Ernst ================================ Ernst Horvath Siemens AG Tel: +43 1 1707 45897 Fax: +43 1 1707 56992 enail: ernst.horvath(a)siemens.at ================================ Pete Cordell wrote: > > Jim, Scott, Douglas, Paul,..... > > To answer Paul's question about the need for the change first: > > We are mainly interested in gatekeepers. We have a need to ship > nonStandard information between cooperating gatekeepers, particularly in > the SETUP message. However, endpoints may also wish to ship their own > nonStandard information which the gatekeeper doesn't want to stamp on > (because I'm a nice guy!). Hence we both have a need to use a field > that is only intended to carry one value. > > This helps identify a suitable syntax for the data that goes into the > data part of nonStandard data, as I believe we need to cater for both > the nested form (for backwards compatibility) and multiple pieces of > nonStandard data without any particular order. > > To do this, I propose that the piece of ASN.1 put in the data part of > nonStandardParameter should be: > > ExtendedNonStandardData ::= SEQUENCE > { > previousNonStandard NonStandardParameter OPTIONAL, > extraNonStandard SEQUENCE OF NonStandardParameter, > ... > } > > This would be used as follows: > > A V1 endpoint could put its own piece of nonStandardData into the > existing nonStandard field. When a gatekeeper (or something else) > received it, it would take the data from the existing nonStandard field > and put it in the previousNonStandard field of the above SEQUENCE. It > would then add whatever nonStandard stuff it needed to the > extraNonStandard bit. It would put the combined nonStandard data in the > data part of the nonStandardParameter and give it the tag that we decide > on. > > On the other side a gatekeeper could see that the extraNonStandard > related to it, and remove parts the parts that it needed to. If all > that was left was the previousNonStandard part, then it would use this > to recover what was the original format of the nonStandard message. > This allows endpoints to send nonStandardData transparently, but also > allows gatekeepers to get in on the act. > > As far as how this is captured in the standard, this seems a fairly > important feature for H.225. I think we should include this as a > separate root in the H.225 ASN.1 and give a fairly official OBJECT > IDENTIFIER (e.g. {itu-t (0) recommendation (0) h(8) 2250} which > shouldn't clash with anything in the context that we are using it). > > I've used an unconstrained SEQUENCE OF for the following reasons: > 1. No other SEQUENCE OFs are bounded within H.225. > 2. Size constraints on SEQUENCE OF are not always that useful > (especially in the case of H.245!) > 3. We have no other SET OFs in H.225 > 4. As I understand it, for some strange reason, because the order of the > members of a SET OF is intended to be un-important the compiler takes it > upon itself to sort the values entered into some form of order!!! This > seems a waste of time and is a step best avoided by using SEQUENCE OF. > > Pete > ================================= > Pete Cordell > BT Labs > E-Mail: pete.cordell(a)bt-sys.bt.co.uk > Tel: +44 1473 646436 > Fax: +44 1473 645499 > ================================= >

1 0

Re: Limitation of nonStandardData and other issues related to H.450
by Karl Klaghofer 03 Dec '97

03 Dec '97

Some comments related to H.450.x have been placed to the reflector the last days. 1) H.450.2 Clause 10.5 (item 1 of Levin Orit´s comments, dated Dec.1) I agree, 2nd paragraph, third line: ...and conferenceGoal="invite"... should be deleted. 2) H.450.2 Clause 10.6.1.1 (item 4 of Levin Orit´s comments, dated Dec.1) The procedures defined for this gatekeeper active transfer case right now are very much based on the gatekeeper having H.225 as well as H.245 control (i.e. H.225 as well as H.245 routed via gk). The model you are referring to (H.225 via gk; H.245 direct routed) was not investigated in conjunction with active gk transfer, since this model is (as Pete sayd) still marked as "for further study" in H.323V2 ! Using the direct H.245 model in conjunction with active transfer by gatekeeper would introduce a further, alternative method of handling the logical channel closing and reopening issue at the transferred endpoint B. Remark: In Sunriver September meeting, the goal was to have just one method (we picked the "empty terminalCapabilitySet" method and dropped the "requestChannelClose with reopen" method in order to reach this goal. Proposal for further proceeding: First the H.245 direct model has to be investigated for H.323 (maybe H.323V3). Then, H.450.2 (maybe V2) might be updated to get this model also to work for active gk transfer. 3) Limitation of nonStandardData (Comment from Pete Cordell, dated Dec.2) Currently we have in H.450.x constructs like the following: argumentExtension CHOICE {extensionSeq ExtensionSeq, nonStandardData NonStandardParameter } OPTIONAL ExtensionSeq ::= SEQUENCE OF Extension{{ExtensionSet}} ExtensionSet EXTENSION ::= {...} -- Actual values defined by individual manufacturers This means: either one value nonStandardParameter or a SEQ of an arbitrary number of values of type Extension may be inserted. 1st possible change: allow more than one nonStandardParameter: argumentExtension CHOICE {extensionSeq ExtensionSeq, nonStandardData SEQUENCE OF NonStandardParameter } OPTIONAL which means either a SEQ of Extensions or a SEQ of NonStandardParameter may be inserted. This 1st possibility would be a H.450 change corresponding to Pete´s proposal for H.225/H.245. 2nd possible change: argumentExtension SEQUENCE OF MixedExtension OPTIONAL MixedExtension ::= CHOICE {extension Extension{{ExtensionSet}}, nonStandardData NonStandardParameter } This 2nd possibility would be a H.450 change corresponding to Pete´s proposal for H.225/H.245, which adds a further dimension of allowing mixing of any number of NonStandardParameter and ISO like Extensions within one pdu. This may have advantages e.g. in the case that an ISO like Extension is contained within a received pdu in a gk and the gk wants to add further extensions of the NonStandardParamter type (or vice versa) to the same pdu. Proposal for further proceeding. The 2nd possibility mentioned above should be added to a H.450V2. ================================================== Karl Klaghofer Siemens AG Munich, Hofmannstr. 51, D-81359 Munich, Germany Dptmnt: PN VS LP3, Building/Room: 1760/455 Tel.: +49 89 722 31488 Fax.: +49 89 722 23977 email: karl.klaghofer(a)mch.pn.siemens.de ==================================================

2 1

uuencoded file
by Sakae Okubo 03 Dec '97

03 Dec '97

Dear Jim, I have noticed that my text file uuencoded on SPARC loses spaces at the end of line, which causes problem for uudecoding. I have confirmed that if it is returned from GCL server nothing happens. I wonder if this redundancy reduction is taking place at your server and if there is any setting to avoid this. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

2 1

Re: Limitation of nonStandardData and other issues related to H.450
by Pete Cordell 03 Dec '97

03 Dec '97

Karl, Your 2nd option looks good to me too... Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Karl Klaghofer[SMTP:karl.klaghofer@MCH.PN.SIEMENS.DE] >Sent: 03 December 1997 09:40 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Limitation of nonStandardData and other issues related to >H.450 > >Some comments related to H.450.x have been placed to the reflector the >last days. > >1) H.450.2 Clause 10.5 (item 1 of Levin Orit's comments, dated Dec.1) >I agree, 2nd paragraph, third line: ...and conferenceGoal="invite"... >should be deleted. > > >2) H.450.2 Clause 10.6.1.1 (item 4 of Levin Orit's comments, dated >Dec.1) >The procedures defined for this gatekeeper active transfer case right >now are very much based on the gatekeeper having H.225 as well as H.245 >control (i.e. H.225 as well as H.245 routed via gk). >The model you are referring to (H.225 via gk; H.245 direct routed) was >not investigated in conjunction with active gk transfer, since this >model is (as Pete sayd) still marked as "for further study" in H.323V2 >! >Using the direct H.245 model in conjunction with active transfer by >gatekeeper would introduce a further, alternative method of handling >the logical channel closing and reopening issue at the transferred >endpoint B. Remark: In Sunriver September meeting, the goal was to >have just one method (we picked the "empty terminalCapabilitySet" >method and dropped the "requestChannelClose with reopen" method in >order to reach this goal. >Proposal for further proceeding: First the H.245 direct model has to be >investigated for H.323 (maybe H.323V3). Then, H.450.2 (maybe V2) might >be updated to get this model also to work for active gk transfer. > > >3) Limitation of nonStandardData (Comment from Pete Cordell, dated >Dec.2) >Currently we have in H.450.x constructs like the following: > >argumentExtension CHOICE > {extensionSeq ExtensionSeq, > nonStandardData NonStandardParameter } OPTIONAL > >ExtensionSeq ::= SEQUENCE OF Extension{{ExtensionSet}} > >ExtensionSet EXTENSION ::= {...} -- Actual values defined by >individual >manufacturers > >This means: either one value nonStandardParameter or a SEQ of an >arbitrary number of values of type Extension may be inserted. > > >1st possible change: allow more than one nonStandardParameter: > >argumentExtension CHOICE > {extensionSeq ExtensionSeq, > nonStandardData SEQUENCE OF NonStandardParameter } >OPTIONAL > >which means either a SEQ of Extensions or a SEQ of NonStandardParameter >may be inserted. This 1st possibility would be a H.450 change >corresponding to Pete's proposal for H.225/H.245. > >2nd possible change: > >argumentExtension SEQUENCE OF MixedExtension OPTIONAL > >MixedExtension ::= CHOICE > {extension Extension{{ExtensionSet}}, > nonStandardData NonStandardParameter } > >This 2nd possibility would be a H.450 change corresponding to Pete's >proposal for H.225/H.245, which adds a further dimension of allowing >mixing of any number of NonStandardParameter and ISO like Extensions >within one pdu. >This may have advantages e.g. in the case that an ISO like Extension is >contained >within a received pdu in a gk and the gk wants to add further >extensions of the NonStandardParamter type (or vice versa) to the same >pdu. >Proposal for further proceeding. The 2nd possibility mentioned above >should be added >to a H.450V2. > >================================================== >Karl Klaghofer >Siemens AG Munich, Hofmannstr. 51, D-81359 Munich, Germany >Dptmnt: PN VS LP3, Building/Room: 1760/455 >Tel.: +49 89 722 31488 Fax.: +49 89 722 23977 >email: karl.klaghofer(a)mch.pn.siemens.de >================================================== >

1 0

Update of the APC-1305 H.245 based control
by Sakae Okubo 03 Dec '97

03 Dec '97

Dear Ms. Li Yan and other Q.12/16 experts, To assist the H.bmultipoint Editor (Mr. Hidenobu Harasakai), I have undertaken to update your APC-1305 to reflect the Sunriver meeting discussions as attached. The file sct_X.doc is also placed at the Incoming directory of the GCL ftp site. At this stage, no new materials have been added, but obviously we need such efforts subsequently. Please review this update for inclusion in the draft H.bmultipoint which will soon be issued by Editor with other elaborations. Please also note the following: 1. Simple editorial corrections, such as subject-verb correspondence, have been made without change marks. 2. Another communication procedure section for video mixing? Perhaps not. We can easily extend Section X to cover video mixing from the procedure perspective. It would be better to address basic communication procedures with and without video mixing, but using H.245 and H.310 controls. 3. Another communication procedure section for point-to-multipoint configuration? 4. Add the following definitions: selected communication mode (SCM): a communication mode which MCU identifies to use in a particular multipoint communication session. See H.243. primary terminal: a terminal which supports the SCM. See H.243. secondary terminal: a terminal which does not support the SCM. See H.243. 5. In Section X.4c), I have changed "frame alignment is lost" to "video decoding process may be disrupted" because frame alignment may imply that of H.221. There is no corresponding "frame" in H.222.1/0. 6. In the bit rate symmetry description in Section X.5.1, "MCU may choose to send H.245 FlowControlCommand to achieve the bit-rate symmetry." has been stated according to the discussion in Sunriver (see Section 4.3.2/APC-1327). This is based on my understanding that audio, video and data rates can be controlled either by H.245 FlowControlCommand or RequestMode. However, the transfer rate can only be controlled by H.245 FlowControlCommand. Is my understanding correct? Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ******************************************************************** begin 666 sect_X.doc MT,\1X*&Q&N$ .P # /[_"0 & ! M 0 $ @ $ #^____ #_____________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_______________________]____)@ /[___\G !0 8 ' M" D * "P P - #@ \ 0 $0 !( 3 M % !4 6 %P !@ 9 &@ !L < '0 !X M ? ( "$ B (P "0 E * /[____^____*0 M "H K + "T N +P # Q ,@ #, T M-0 #8 W . #D #^________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_____________________________________________P!2 M M " 4 __________\# D" # 1@ M ( X73<# +T! P ( " 0!# &\ ;0!P $\ 8@!J M M !( @'_______________\ M 7 !7 &\ <@!D $0 ;P!C '4 ;0!E &X = M &@ " ?__ M__\$ _____P M 0 !Q9P $\ 8@!J &4 8P!T % ;P!O &P M 6 $! 0 ( #_ M____ HL0V P"] 0"BQ#8# +T! M 0 /[___\# ! 4 & !P @ ) _O__ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M______________________________\! /[_ @ ! /____\ "0( , M !&' $UI8W)O<V]F="!7;W)D(#8N,"!$;V-U;65N= #^____3D(V M5Q !7;W)D+D1O8W5M96YT+C8 [ /__@ ) 8 M 0 $ 0 /[_ #"@$ $ #R MGX7@3_D0:*N1" K)[/9, +T! / !P )@ " XP 0 M B 0 " #(! ! 0@$ P !( 0 "P %0! - 8 $ M \ !L 0 $ '0! * ? $ !( "( 0 #@ *,! ) MJP$ !, "U 0 ! 0 ! /__________'@ $, !- M86-I;G1O<V@@2$0Z07!P;&EC871I;VYS.H./@5N#:(-V@XV#6H-B@U0Z5V]R M9" V.E1E;7!L871E<SI.;W)M86P '@ #< !8+@E"87-I8R!C;VUM=6YI M8V%T:6]N('!R;V-E9'5R97,@=7-I;F<@2"XR-#4@8V]N=')O;', '@ @ M !A:V%S86MA !X ( 86MA<V%K80 " $2= ,2*'-RE: !# MP D$ &4 $ $ 0 # #,00 <6< M #*/@ 0 8@ Y@ M !B #F YF( #F8@ .9B $ ZF( @ #R8@ M% &QC ;&, !L8P &QC ;&, !L M8P (@ (YC ! ;&, !T9@ 30 1D !&0 M $9 1D $ "&0 (9 AD "&0 M !,9@ @ $YF 3F8 !.9@ $YF M3F8 !.9@ )@ ,%F !8 &6< %@ !T9@ M #F8@ AD B "< !0 * AD M"&0 "&0 (9 '1F M "&0 #F8@ .9B "&0 M SF, #8 (9 AD "&0 (9 M .9B "&0 #F8@ AD 3&8 M !F, "8 L8P 0 .9B YF( #F M8@ .9B "&0 !,9@ AD !$ @ "&0 M M %@) M0F%S:6,@8V]M;75N:6-A=&EO;B!P<F]C961U<F5S('5S:6YG($@N,C0U(&-O M;G1R;VQS#0U8+C$)1V5N97)A; T-5&AI<R!S96-T:6]N('-P96-I9FEE<R!T M:&4@;75L=&EP;VEN="!C;VYF97)E;F-E('-E<W-I;VX@8V]N=')O;"!U<VEN M9R!C;&%S<VEC86P@34-5*',I('=I=&AO=70@=FED96\@;6EX:6YG('=H97)E M(&5N9'!O:6YT<R!A<F4@=&EG:'1L>2UC;W5P;&5D+B!!=61I;R!I<R!C96YT M<F%L;'D@;6EX960@86YD('9I9&5O("AA;F0@9&%T82D@87)E(&-E;G1R86QL M>2!S=VET8VAE9"!A="!T:&4@34-5+B!4;R!P<F]V:61E(&)A<VEC(&-O;F9E M<F5N8V4@<V5S<VEO;B!C;VYT<F]L<RP@=&AE(&-O;6UU;FEC871I;VX@<')O M8V5D=7)E<R!A<F4@8F%S960@;VX@2"XR-#,@=7-I;F<@2"XR-#4@;65S<V%G M97,@86YD($@N,S$P(%9I9&5O($9R86UE(%-Y;F-H<F]N;W5S($,F22!S:6=N M86QL:6YG+@T-6"XR"5!R;V-E9'5R92!F;W(@9&5T97)M:6YI;F<@8V%P86)I M;&ET:65S(&%N9"!S96QE8W1E9"!C;VUM=6YI8V%T:6]N(&UO9&4-#51H92!- M0U4@<VAA;&P@<V5N9"!A<'!R;W!R:6%T92!C87!A8FEL:71I97,L(&%C8V]R M9&EN9R!T;R!T:&4@='EP92!O9B!C;VUM=6YI8V%T:6]N(&EN=&5N9&5D+B!& M;W(@96%C:"!C;VYF97)E;F-E(&-A;&P@82"3<V5L96-T960@8V]M;75N:6-A M=&EO;B!M;V1E("A30TTIE"!I<R!I9&5N=&EF:65D(&EN('1H92!-0U4N($1U M<FEN9R!T:&4@8V%L;"!T:&4@34-5('-T<FEV97,@=&\@;6%I;G1A:6X@=&AI M<R!30TT@87,@=&AA="!T<F%N<VUI='1E9"!B:2UD:7)E8W1I;VYA;&QY(&)E M='=E96X@:71S96QF(&%N9"!A;&P@=&5R;6EN86QS+"!A;F0@8F5T=V5E;B!I M='-E;&8@86YD(&]T:&5R($U#57,N( T-5&AE(&9O;&QO=VEN9R!A<F4@<&]S M<VEB;&4@;65T:&]D<R!T;R!D971E<FUI;F4@=&AE(%-#33H-#71H92!30TT@ M;6%Y(&)E(&9I>&5D(&%S(&$@<&5R;6%N96YT(&9E871U<F4@;V8@=&AE($U# M52!A<R!M86YU9F%C='5R960[#71H92!-0U4@;6%Y('!R;W9I9&4@9F]R('-E M=F5R86P@<&]S<VEB;&4@=F%L=65S(&]F(%-#32P@86YD(&]N92!O9B!T:&5S M92!I<R!S<&5C:69I960@8GD@=&AE('-E<G9I8V4@<')O=FED97(@;W(@870@ M=&AE('1I;64@;V8@8F]O:VEN9R!T:&4@8V%L;#L-=&AE(%-#32!I<R!S96QE M8W1E9"!A=71O;6%T:6-A;&QY('=I=&AI;B!T:&4@34-5(&%C8V]R9&EN9R!T M;R!T:&4@8V%P86)I;&ET:65S(&]F('1H92!T97)M:6YA;',@8V]N;F5C=&5D M.R!F;W(@97AA;7!L92P@=&AE(%-#32!I<R!S970@870@=&AE('9A;'5E('1R M86YS;6ET=&5D(&)Y('1H92!F:7)S="!T97)M:6YA;"!T;R!A8V-E<W,@=&AE M($U#53L@;W(@=&AE(&AI9VAE<W0@8V]M;6]N(&UO9&4@;V8@86QL('!R:6UA M<GD@=&5R;6EN86QS(&ES('-E;&5C=&5D.R!O<B!T:&4@4T--(&ES('-E="!A M="!T:&4@=F%L=64@=')A;G-M:71T960@8GD@=&AE(&-H86ER+6-O;G1R;VP@ M=&5R;6EN86PL(&EF(&%N>3L-=&AE(%-#32!I<R!S970@8GD@=71I;&EZ:6YG M('!R;V-E9'5R97,@969F96-T=6%T960@=7-I;F<@5"XQ,C @4V5R:65S('!R M;W1O8V]L<RX-#51O(&5N9F]R8V4@4T--+"!A="!T:&4@8F5G:6YN:6YG(&]F M(&$@8V]N9F5R96YC92P@34-5('-E;F1S(&UU;'1I<&]I;G1-;V1E0V]M;6%N M9"!T;R!A;&P@=&AE('1E<FUI;F%L<R!T;R!C;VUM86YD('1H870@82!T97)M M:6YA;"!I;B!R96-E:7!T('-H86QL(&-O;7!L>2!W:71H(&%L;"!R97%U97-T M36]D92!R97%U97-T<R!I<W-U960@8GD@=&AE($U#52P@:68@=&AE(')E<75E M<W1E9"!T<F%N<V9E<B!M;V1E(&ES('=I=&AI;B!T97)M:6YA;))S(&-A<&%B M:6QI='D@<V5T+@T-6"XS"4EN:71I86QI>F%T:6]N('!R;V-E9'5R97,@9F]R M(&5S=&%B;&ES:&EN9R!C;VUM=6YI8V%T:6]N(&)E='=E96X@<W1A;F1A<F0@ M=&5R;6EN86QS(&%N9"!A;B!-0U4-#5@N,RXQ"49I<G-T('1E<FUI;F%L(&%D M9&5D('1O(&-O;F9E<F5N8V4-#51H92!C;VUM=6YI8V%T:6]N(&]F('1H92!F M:7)S="!T97)M:6YA;" H5#$I(&%N9"!-0U4@9F]L;&]W<R!T:&4@9F]L;&]W M:6YG('!H87-E<SH-#5!H87-E($$Z($-A;&P@<V5T=7 @*$EN:71I86P@5D,M M4V5T=7 I.@T-26YI=&EA;"!60R!I<R!S971U<"!B971W965N('1H92!F:7)S M="!T97)M:6YA;"!A;F0@=&AE($U#52!V:6$@42XR.3,Q(%-%5%50(&UE<W-A M9V4N(%1H92!E>&%C="!P87)A;65T97)S(&%N9"!1+C(Y,S$@26YF;W)M871I M;VX@16QE;65N=',@*$E%<RD@=7-E9"!F;W(@=&AI<R!P:&%S92!A<F4@9&5S M8W)I8F5D(&EN($@N,S$P($%N;F5X($(N($EN('1H:7,@<&AA<V4L($U#52!C M86X@96ET:&5R(&ED96YT:69Y('1H92!T>7!E(&]F(')E;6]T92!(+C,Q,"!T M97)M:6YA;"!O<B!I;F9E<B!T:&%T('1H92!R96UO=&4@=&5R;6EN86P@:7,@ M;F]T($@N,S$P('1E<FUI;F%L('1Y<&4N(%1H:7,@:7,@9&]N92!B>2!U<VEN M9R!T:&4@0G)O861B86YD($)E87)E<B!#87!A8FEL:71Y("A"+4)#*2P@3F%R M<F]W+6)A;F0@0F5A<F5R($-A<&%B:6QI='D@*$XM0D,I(&%N9"!O=&AE<B!I M;F9O<FUA=&EO;B!E;&5M96YT<R!O9B!T:&4@42XR.3,Q(%-%5%50(&UE<W-A M9V4N($%N($@N8FUU;'1I<&]I;G0S,3 @34-5('-H86QL('-E="!T:&5S92!I M;F9O<FUA=&EO;B!E;&5M96YT<R!T;R!T:&4@87!P<F]P<FEA=&4@<&%R86UE M=&5R<R!W:&EC:"!I;F1I8V%T92!T:&4@2"XS,3 @=&5R;6EN86P@='EP92X@ M268@86X@2"YB;75L=&EP;VEN=#,Q,"!D;V5S(&YO="!R96-E:79E('1H92!. M+4)#(&EN9F]R;6%T:6]N(&5L96UE;G0@9G)O;2!T:&4@<F5M;W1E('1E<FUI M;F%L+"!T:&5N('1H92!(+C,Q,"!-0U4@8V%N(&%S<W5M92!T:&%T(&ET(&ES M(&YO="!C;VUM=6YI8V%T:6]N('=I=&@@86X@2"XS,C O2"XS,C$@=&5R;6EN M86PN#0U4:&4@:6YI=&EA;"!60R!S:&%L;"!H879E(&$@8FET(')A=&4@;V8@ M-C0@:V)I="]S(&%T('1H92!!04PM4T%0+"!F;W(@=&AE('1R86YS9F5R(&]F M($@N,C0U(&UE<W-A9V5S('5S:6YG('1H92!S97!A<F%T92!60R!S=&%C:R!D M97-C<FEB960@:6X@2"XS,3 @06YN97@@02X-#5!H87-E($(Z($EN:71I86P@ M8V]M;75N:6-A=&EO;B!A;F0@0V%P86)I;&ET>2!E>&-H86YG92 -#4U#52!S M96YD<R!M=6QT:7!O:6YT0V]N9F5R96YC92!A;F0@;75L=&EP;VEN=%IE<F]# M;VUM(&EN9&EC871I;VYS('1O('1H92!F:7)S="!T97)M:6YA;"!O=F5R('1H M92!I;FET:6%L(%9#('1H870@:&%S(&)E96X@97-T86)L:7-H960@:6X@4&AA M<V4@02P@:6YD:6-A=&EN9R!T:&%T(&$@8V]N9F5R96YC92!C86QL(&ES(&)E M:6YG('-E="!U<"P@=&AA="!N;R!O=&AE<B!T97)M:6YA;',@87)E('EE="!C M;VYN96-T960@86YD('1H92!U<V5R('-H;W5L9"!W86ET+B!5<VEN9R!(+C(T M-2 @<')O8V5D=7)E<RP@=&AE($U#52!A;F0@=&AE(&9I<G-T('1E<FUI;F%L M(&5X8VAA;F=E('1H96ER(&-A<&%B:6QI=&EE<RX@34-5(')E9VES=&5R<R!T M:&]S92!C87!A8FEL:71I97,@;V8@=&AE(&9I<G-T('1E<FUI;F%L('=H:6-H M(&ET(&-A;B!U;F1E<G-T86YD(&%N9"!U<V4N($9O<B!T:&]S92!C87!A8FEL M:71I97,@=&AA="!A<F4@;F]T('5N9&5R<W1O;V0L(&]R(&-A;B!N;W0@8F4@ M=7-E9"!B>2!-0U4@<VAA;&P@8F4@:6=N;W)E9"X@3F]T92!T:&%T($U#52!C M86X@9&5T97)M:6YE()-30TV4("!B87-E9"!O;B!T:&4@8V%P86)I;&ET:65S M(&5X8VAA;F=E(&]R('5S92!P<F5D971E<FUI;F5D()-30TV4(&%S(&1E<V-R M:6)E9"!I;B"D6"XS+C$N#0U-0U4@=&AE;B!S96YD<R!M=6QT:7!O:6YT36]D M94-O;6UA;F0@8V]M;6%N9"!T;R!R97%U97-T('1H92!F:7)S="!T97)M:6YA M;"!T;R!F;VQL;W<@86QL(&UO9&4@<F5Q=65S=',@9G)O;2!I="X@5&AE;B!- M0U4@<V5N9',@4F5Q=65S=$UO9&4@=VET:"!A(&QI<W0@;V8@<V5L96-T960@ M8V]M;75N:6-A=&EO;B!M;V1E<RX-#5!H87-E($,Z($5S=&%B;&ES:&UE;G0@ M;V8@875D:6]V:7-U86P@8V]M;75N:6-A=&EO;B H061D:71I;VYA;"!60R!3 M971U<"!A;F0@02]6(&-O;6TN*0T-26X@=&AI<R!P:&%S92P@86YD(&)A<V5D M(&]N('1H92!S96QE8W1E9"!C;VUM=6YI8V%T:6]N(&UO9&4@9&5T97)M:6YE M9"!A8F]V92P@=&AE(&-A;&QI;F<@<&%R='D@*&-A;B!B92!-0U4@;W(@=&AE M(&9I<G-T('1E<FUI;F%L*2P@=&AA="!I<RP@=&AE(&]N92!T:&%T(&EN:71I M871E9"!T:&4@9FER<W0@5D,@4T5455 @;65S<V%G92P@<VAA;&P@9FER<W1L M>2!I;F1I8V%T92!T:&4@8VAA<F%C=&5R:7-T:6-S(&]F('1H92!A9&1I=&EO M;F%L(%9#*',I('1O('1H92!R96UO=&4@96YD('5S:6YG('1H92!(+C(T-2!. M97=!5$U60TEN9&EC871I;VX@;65S<V%G92P@86YD('1H96X@<VAA;&P@<V5T M('5P('1H92!A9&1I=&EO;F%L(%9#*',I('=I=&@@=&AE(&%P<')O<')I871E M('!A<F%M971E<G,L('-U8V@@87,@8FET(')A=&4@86YD($%!3"!T>7!E+"!F M;W(@=&AE('1R86YS9F5R(&]F('1H92!A=61I;W9I<W5A;"!A;F0@;W1H97(@ M9&%T82!B971W965N('1H92!-0U4@86YD('1H92!F:7)S="!T97)M:6YA;"X@ M069T97(@97-T86)L:7-H;65N="!O9B!T:&4@861D:71I;VYA;"!60RAS*2P@ M=&AE('!R;V-E9'5R97,@;V8@2"XR-#4@<VAA;&P@8F4@=7-E9"!T;R!O<&5N M('1H92!D97-I<F5D('9I9&5O+"!A=61I;RP@9&%T82P@86YD+V]R(&-O;G1R M;VP@;&]G:6-A;"!C:&%N;F5L<R!U<VEN9R!L;V=I8V%L(&-H86YN96P@<VEG M;F%L;&EN9R!P<F]T;V-O;"!A;F0@8FDM9&ER96-T:6]N86P@;&]G:6-A;"!C M:&%N;F5L('-I9VYA;&QI;F<@<')O=&]C;VP@9&5F:6YE9"!I;B!(+C(T-2X- M#51O(&%V;VED(&)A9"!A=61I;RP@870@=&AE(&1I<V-R971I;VX@;V8@=&AE M(&UA;G5F86-T=7)E<BP@=&AE($U#52!S:&]U;&0@9&\@;VYE(&]F('1H92!F M;VQL;W=I;F<@9F]R(&%U9&EO.@T-<V5N9"!L;V=I8V%L0VAA;FYE;$EN86-T M:79E(&9O<B!T:&4@875D:6\@8VAA;FYE;"!T;R!T:&4@=&5R;6EN86P[#7-E M;F0@<VEL96YC92!O<B!A;B!O<'1I;VYA;"!A=61I;RUM97-S86=E('1O('1H M92!T97)M:6YA;"X-#51H92!V:61E;R!S965N(&)Y('1H92!F:7)S="!T97)M M:6YA;"!I<R!U<"!T;R!T:&4@9&ES8W)E=&EO;B!O9B!T:&4@34-5(&UA;G5F M86-T=7)E<BX-#51H92!D871A(')E8V5I=F5D(&)Y('1H92!F:7)S="!T97)M M:6YA;"!I<R!U<"!T;R!T:&4@9&ES8W)E=&EO;B!O9B!T:&4@34-5(&UA;G5F M86-T=7)E<BX-#5@N,RXR"5-E8V]N9"!T97)M:6YA;"!A9&1E9"!T;R!C;VYF M97)E;F-E#0U0:&%S92!!.B!#86QL('-E='5P("A);FET:6%L(%9#+5-E='5P M*3H-#4EN:71I86P@5D,@:7,@<V4@='5P(&)E='=E96X@34-5(&%N9"!T:&4@ M<V5C;VYD('1E<FUI;F%L("A4,BD@8GD@=7-I;F<@=&AE('-A;64@;65T:&]D M(&%S(&EN('1H92!F:7)S="!T97)M:6YA;"X-#5!H87-E($(Z($EN:71I86P@ M8V]M;75N:6-A=&EO;B!A;F0@0V%P86)I;&ET>2!E>&-H86YG90T-34-5('-E M;F1S(&UU;'1I<&]I;G1#;VYF97)E;F-E(&EN9&EC871I;VX@=&\@=&AE('-E M8V]N9"!T97)M:6YA;"!O=F5R('1H92!I;FET:6%L(%9#('1H870@:&%S(&)E M96X@97-T86)L:7-H960@:6X@4&AA<V4@02P@:6YD:6-A=&EN9R!T:&%T(&$@ M8V]N9F5R96YC92!C86QL(&ES(&)E:6YG('-E="!U<"X@57-I;F<@2"XR-#4@ M('!R;V-E9'5R97,L('1H92!-0U4@86YD('1H92!S96-O;F0@=&5R;6EN86P@ M97AC:&%N9V4@=&AE:7(@8V%P86)I;&ET:65S+B!-0U4@<F5G:7-T97)S('1H M;W-E(&-A<&%B:6QI='D@;V8@=&AE('-E8V]N9"!T97)M:6YA;',@=VAI8V@@ M:70@8V%N('5N9&5R<W1A;F0@86YD('5S92X@1F]R('1H;W-E(&-A<&%B:6QI M=&EE<R!T:&%T(&%R92!N;W0@=6YD97)S=&]O9"P@;W(@8V%N(&YO="!B92!U M<V5D(&)Y($U#52!S:&%L;"!B92!I9VYO<F5D+B!.;W1E('1H870@34-5(&-A M;B!D971E<FUI;F4@DU-#390@(&)A<V5D(&]N('1H92!C87!A8FEL:71I97,@ M97AC:&%N9V4@;W(@=7-E('!R961E=&5R;6EN960@DU-#390@87,@9&5S8W)I M8F5D(&EN(*18+C,N,2X-#4U#52!T:&5N('-E;F1S(&UU;'1I<&]I;G1-;V1E M0V]M;6%N9"!C;VUM86YD('1O(')E<75E<W0@=&AE('-E8V]N9"!T97)M:6YA M;"!T;R!F;VQL;W<@86QL(&UO9&4@<F5Q=65S=',@9G)O;2!I="X@5&AE;B!- M0U4@<V5N9',@<F5Q=65S=$UO9&4@=VET:"!T:&4@;&ES="!O9B!S96QE8W1E M9"!C;VUM=6YI8V%T:6]N(&UO9&5S+@T-4&AA<V4@0SH@17-T86)L:7-H;65N M="!O9B!A=61I;W9I<W5A;"!C;VUM=6YI8V%T:6]N("A!9&1I=&EO;F%L(%9# M(%-E='5P*0T-26X@=&AI<R!P:&%S92P@86YD(&)A<V5D(&]N('1H92!C;VUM M=6YI8V%T:6]N(&UO9&4@9&5T97)M:6YE9"!A8F]V92P@=&AE(&-A;&QI;F<@ M<&%R='DL('1H870@:7,L('1H92!O;F4@=&AA="!I;FET:6%T960@=&AE(&9I M<G-T(%9#(%-%5%50(&UE<W-A9V4L('-H86QL(&9I<G-T;'D@:6YD:6-A=&4@ M=&AE(&-H87)A8W1E<FES=&EC<R!O9B!T:&4@861D:71I;VYA;"!60RAS*2!T M;R!T:&4@<F5M;W1E(&5N9"!U<VEN9R!T:&4@2"XR-#4@3F5W051-5D-);F1I M8V%T:6]N(&UE<W-A9V4L(&%N9"!T:&5N('-H86QL('-E="!U<"!T:&4@861D M:71I;VYA;"!60RAS*2!W:71H('1H92!A<'!R;W!R:6%T92!P87)A;65T97)S M+"!S=6-H(&%S(&)I="!R871E(&%N9"!!04P@='EP97,L(&9O<B!T:&4@=')A M;G-F97(@;V8@=&AE(&%U9&EO=FES=6%L(&%N9"!O=&AE<B!D871A(&)E='=E M96X@=&AE($U#52!A;F0@=&AE('-E8V]N9"!T97)M:6YA;"X-#4%N($U#52!S M:&%L;"!O<&5N('1H92!D97-I<F5D('9I9&5O+"!A=61I;RP@9&%T82P@86YD M+V]R(&-O;G1R;VP@;&]G:6-A;"!C:&%N;F5L<R!U<VEN9R!T:&4@;&]G:6-A M;"!C:&%N;F5L('-I9VYA;&QI;F<@<')O=&]C;VP@86YD(&)I+61I<F5C=&EO M;F%L(&QO9VEC86P@8VAA;FYE;"!S:6=N86QL:6YG('!R;W1O8V]L(&1E9FEN M960@:6X@2"XR-#4N(%1H92!A=61I;R!A;F0@=FED96\@<&%T:',@87)E('-E M="!U<"!A<R!F;VQL;W=S.@T-075D:6\Z( U";W1H('1H92 H9&5C;V1E9"D@ M875D:6\@<VEG;F%L<R!A<F4@8V]N;F5C=&5D('1O('1H92!A=61I;R!M:7AE M<CL@=&AE('-Y;6)O;"!C86YC96Q-=6QT:7!O:6YT6F5R;T-O;6T@:7,@<V5N M="!T;R!T:&4@9FER<W0@=&5R;6EN86P@5#$[#51H92!M:7AE<B!O=71P=71S M(&%R92!S96YT('1O(%0Q(&%N9"!4,B!A;F0@=&AE(&UI>&EN9R!A;&=O<FET M:&T@=7-E9"!I<R!U<"!T;R!T:&4@34-5(&UA;G5F86-T=7)E<BX-5FED96\Z M( U)9B!V:61E;R!S:6=N86QS(&%R92!B96EN9R!R96-E:79E9"!F<F]M(&5I M=&AE<B!O<B!B;W1H('1E<FUI;F%L<RP@=FED96]&87-T57!D871E4&EC='5R M92!I<R!S96YT('1O=V%R9',@=&AE('1R86YS;6ET=&5R*',I(&]F('1H97-E M('-I9VYA;',@86YD('1H92!N97AT('9I9&5O(&9R86UE(&EN()-&87-T('5P M9&%T990@;6]D92!I<R!F;W)W87)D960@=&\@8F]T:"!T97)M:6YA;',[#4EF M('9I9&5O('-I9VYA;',@87)E(&)E:6YG(')E8V5I=F5D(&9R;VT@8F]T:"!T M97)M:6YA;',L('9I9&5O1F%S=%5P9&%T95!I8W1U<F4@:7,@<V5N="!T;R!B M;W1H('1E<FUI;F%L<RX@5#&2<R!V:61E;R!I<R!F;W)W87)D960@=&\@5#(L M(&%N9"!4,I)S('9I9&5O(&ES(&9O<G=A<F1E9"!T;R!4,3LN#4EF('9I9&5O M26YD:6-A=&5296%D>51O06-T:79A=&4@:7,@<F5C96EV960@9G)O;2!E:71H M97(@;W(@8F]T:"!T97)M:6YA;',L('1H:7,@:7,@9F]R=V%R9&5D+@U$871A M.B -268@8F]T:"!T97)M:6YA;',@87)E(%0N,3(P(&-A<&%B;&4@=&AE($U# M52!M87D@8V]N;F5C="!B;W1H('1O(&$@9&%T82!C;VYF97)E;F-I;F<@=6YI M="X-5&AE($U#52!M87D@9&5F97(@;W!E;FEN9R!O9B!D871A(&-H86YN96QS M('1O(&$@;&%T97(@=&EM92P@<W5C:"!A<R!W:&5N(&$@<')E9&5T97)M:6YE M9"!N=6UB97(@;V8@=&5R;6EN86QS(&ES('!R97-E;G0N#0U8+C,N,PE4:&ER M9"!T97)M:6YA;"!A9&1E9"!T;R!C;VYF97)E;F-E#0U0:&%S92!!.B!#86QL M('-E='5P("A);FET:6%L(%9#+5-E='5P*3H-#4EN:71I86P@5D,@:7,@<V5T M('5P(&)E='=E96X@34-5(&%N9"!T:&4@=&AI<F0@=&5R;6EN86P@8GD@=7-I M;F<@=&AE('-A;64@;65T:&]D(&%S(&EN('1H92!F:7)S='1H:7)D('1E<FUI M;F%L+@T-4&AA<V4@0CH@26YI=&EA;"!C;VUM=6YI8V%T:6]N(&%N9"!#87!A M8FEL:71Y(&5X8VAA;F=E#0U-0U4@<V5N9',@;75L=&EP;VEN=$-O;F9E<F5N M8V4@:6YD:6-A=&EO;B!T;R!T:&4@=&AI<F0@=&5R;6EN86P@;W9E<B!T:&4@ M:6YI=&EA;"!60R!T:&%T(&AA<R!B965N(&5S=&%B;&ES:&5D(&EN(%!H87-E M($$L(&EN9&EC871I;F<@=&AA="!A(&-O;F9E<F5N8V4@8V%L;"!I<R!B96EN M9R!S970@=7 N(%5S:6YG($@N,C0U("!P<F]C961U<F5S+"!T:&4@34-5(&%N M9"!T:&4@=&AI<F0@=&5R;6EN86P@97AC:&%N9V4@=&AE:7(@8V%P86)I;&ET M:65S+B!-0U4@<F5G:7-T97)S('1H;W-E(&-A<&%B:6QI=&EE<R!O9B!T:&4@ M=&AI<F0@=&5R;6EN86P@=VAI8V@@:70@8V%N('5N9&5R<W1A;F0@86YD('5S M92X@1F]R('1H;W-E(&-A<&%B:6QI=&EE<R!T:&%T(&%R92!N;W0@=6YD97)S M=&]O9"P@;W(@8V%N(&YO="!B92!U<V5D(&)Y($U#52!S:&%L;"!B92!I9VYO M<F5D+B!.;W1E('1H870@34-5(&-A;B!D971E<FUI;F4@DU-#390@(&)A<V5D M(&]N('1H92!C87!A8FEL:71I97,@97AC:&%N9V4@;W(@=7-E('!R961E=&5R M;6EN960@DU-#390@87,@9&5S8W)I8F5D(&EN(*18+C,N,2X-#4U#52!T:&5N M('-E;F1S(&UU;'1I<&]I;G1-;V1E0V]M;6%N9"!C;VUM86YD('1O(')E<75E M<W0@=&AE('1H:7)D('1E<FUI;F%L('1O(&9O;&QO=R!A;&P@;6]D92!R97%U M97-T<R!F<F]M(&ET+B!4:&5N($U#52!S96YD<R!R97%U97-T36]D92!W:71H M('1H92!L:7-T(&]F('-E;&5C=&5D(&-O;6UU;FEC871I;VX@;6]D97,N#0U0 M:&%S92!#.B!%<W1A8FQI<VAM96YT(&]F(&%U9&EO=FES=6%L(&-O;6UU;FEC M871I;VX@#0U);B!T:&ES('!H87-E+"!A;F0@8F%S960@;VX@=&AE(&-O;6UU M;FEC871I;VX@;6]D92!D971E<FUI;F5D(&%B;W9E+"!T:&4@8V%L;&EN9R!P M87)T>2P@=&AA="!I<RP@=&AE(&]N92!T:&%T(&EN:71I871E9"!T:&4@9FER M<W0@5D,@4T5455 @;65S<V%G92P@<VAA;&P@9FER<W1L>2!I;F1I8V%T92!T M:&4@8VAA<F%C=&5R:7-T:6-S(&]F('1H92!A9&1I=&EO;F%L(%9#*',I('1O M('1H92!R96UO=&4@96YD('5S:6YG('1H92!(+C(T-2!.97=!5$U60TEN9&EC M871I;VX@;65S<V%G92P@86YD('1H96X@<VAA;&P@<V5T=7 @=&AE(&%D9&ET M:6]N86P@5D,H<RD@=VET:"!T:&4@87!P<F]P<FEA=&4@<&%R86UE=&5R<RP@ M<W5C:"!A<R!B:70@<F%T92!A;F0@04%,('1Y<&5S+"!F;W(@=&AE('1R86YS M9F5R(&]F('1H92!A=61I;W9I<W5A;"!A;F0@;W1H97(@9&%T82!B971W965N M('1H92!-0U4@86YD('1H92!T:&ER9"!T97)M:6YA;"X-#4%N($U#52!S:&%L M;"!O<&5N('1H92!D97-I<F5D('9I9&5O+"!A=61I;RP@9&%T82P@86YD+V]R M(&-O;G1R;VP@;&]G:6-A;"!C:&%N;F5L<R!U<VEN9R!T:&4@;&]G:6-A;"!C M:&%N;F5L('-I9VYA;&QI;F<@<')O=&]C;VP@86YD(&)I+61I<F5C=&EO;F%L M(&QO9VEC86P@8VAA;FYE;"!S:6=N86QL:6YG('!R;W1O8V]L(&1E9FEN960@ M:6X@2"XR-#4N(%1H92!A=61I;R!A;F0@=FED96\@<&%T:',@87)E('-E="!U M<"!A<R!F;VQL;W=S.B -#4%U9&EO.B -5&AE("AD96-O9&5D*2!A=61I;R!S M:6=N86P@:7,@8V]N;F5C=&5D('1O('1H92!A=61I;R!M:7AE<CL@( U4:&4@ M;6EX97(@;W5T<'5T<R!A<F4@<V5N="!T;R!A;&P@=&AE('1E<FUI;F%L<R!A M;F0@=&AE(&UI>&EN9R!A;&=O<FET:&T@=7-E9"!I<R!U<"!T;R!T:&4@34-5 M(&UA;G5F86-T=7)E<BX-5FED96\Z( U)9B!V:61E;R!S:6=N86QS(&%R92!B M96EN9R!R96-E:79E9"!F<F]M(&%N>2!O;F4@;V8@=&AE('1E<FUI;F%L<R!4 M,2P@5#(L(&%N9"!4,RP@;W(@86QL(&]F('1H92!T97)M:6YA;',L('9I9&5O M(&ES('-W:71C:&5D('5S:6YG('1H92!P<F]C961U<F5S(&1E<V-R:6)E9"!I M;B"D6"XU+@U$871A.@U)9B!T:&4@;F5W('1E<FUI;F%L(&ES(%0N,3(P(&-A M<&%B;&4L('1H92!-0U4@8V]N;F5C=',@:70@=&\@=&AE(&1A=&$@8V]N9F5R M96YC:6YG('5N:70N#0U8+C,N- E&;W5R=&@@86YD('-U8G-E<75E;G0@8V%L M;',@861D960@=&\@8V]N9F5R96YC90T-5&AE('!R;V-E9'5R92!F;VQL;W=E M9"!I<R!E<W-E;G1I86QL>2!T:&%T(&]F('-E8W1I;VX@,R!A8F]V92X-#5@N M,RXU"4-L;W-U<F4@;V8@8V]N9F5R96YC90T-268@=&AE(&-O;F9E<F5N8V4@ M:7,@8VQO<V5D(&)Y('-E<75E;G1I86QL>2!D<F]P<&EN9R!T97)M:6YA;',L M('1H96X@=VAE;B!O;FQY(&]N92!R96UA:6YS(&-O;FYE8W1E9"!I="!S:&]U M;&0@8F4@<V5N="!M=6QT:7!O:6YT6F5R;T-O;6T@=&\@86QL;W<@=&AE('5S M97(@=&\@=6YD97)S=&%N9"!E>'!L:6-I=&QY('1H92!R96%S;VX@9F]R(&QO M<W,@;V8@=FED96\L(&5T8RX@5&AE('1E<FUI;F%L(&1R;W!P960@9F]L;&]W M<R!T:&4@9F]L;&]W:6YG(&-A;&P@<F5L96%S92!P<F]C961U<F5S('1O(&-L M;W-E('1H92!C;VYN96-T:6]N.@U,;V=I8V%L(&-H86YN96QS(')E;&5A<V4Z M($EN('1H:7,@<&AA<V4L(&%L;"!L;V=I8V%L(&-H86YN96QS(&%R92!C;&]S M960@86YD($5N9%-E<W-I;VY#;VUM86YD(&ES('1R86YS;6ET=&5D+"!U<VEN M9R!T:&4@<')O8V5D=7)E<R!D97-C<FEB960@:6X@2"XR-#4N#59I<G1U86P@ M0VAA;FYE;',@<F5L96%S93H@26X@=&AI<R!P:&%S92P@86QL($%432!60W,@ M87)E(')E;&5A<V5D('5S:6YG('1H92!P<F]C961U<F5S(&1E<V-R:6)E9"!I M;B!1+C(Y,S$N#0U8+C0)5FED96\@4W=I=&-H:6YG( T-5VAE;B!I="!I<R!D M96-I9&5D('=I=&AI;B!T:&4@34-5('1H870@=&5R;6EN86P@02P@8W5R<F5N M=&QY(')E8V5I=FEN9R!T:&4@=FED96\@<VEG;F%L(&9R;VT@=&5R;6EN86P@ M0BP@<VAO=6QD(&EN<W1E860@8F4@<V5N="!F<F]M('1E<FUI;F%L($,L('1H M92!F;VQL;W=I;F<@<')O8V5D=7)E(&ES('5S960Z#0U4:&4@34-5('1R86YS M;6ET<R!V:61E;T9R965Z95!I8W1U<F4@=&\@=&5R;6EN86P@02!A="!A;B!A M<'!R;W!R:6%T92!M;VUE;G0L(&%N9"!T:&5N('-W:71C:&5S('9I9&5O(%1R M86YS<&]R="!3=')E86T@<&%C:V5T<R!S=6-H('1H870@=&AE('!I8W1U<F4@ M9G)O;2!#(&ES('1R86YS;6ET=&5D('1O=V%R9',@03L-5&5R;6EN86P@02!R M96-E:79E<R!V:61E;T9R965Z95!I8W1U<F4L(&%N9"!F<F5E>F5S(&ET<R!C M=7)R96YT;'D@9&ES<&QA>65D('!I8W1U<F4[(&ET(&EG;F]R97,@<W5B<V5Q M=65N="!D96-O9&5D('9I9&5O(&EN9F]R;6%T:6]N+"!B=70@8V]N=&EN=65S M('1O('1R86-K('1H92!V:61E;R!E;&5M96YT87)Y('-T<F5A;2!F;W(@=&AE M(&9R965Z92!P:6-T=7)E(')E;&5A<V4@8V]N=')O;"!C;VUM86YD.PU7:&5N M(&EN8V]M:6YG('9I9&5O('1O($$@8VAA;F=E<R!F<F]M($(M<&EC='5R92!T M;R!#+7!I8W1U<F4L('9I9&5O(&1E8V]D:6YG('!R;V-E<W,@;6%Y(&)E(&1I M<W)U<'1E9&9R86UE(&%L:6=N;65N="!I<R!L;W-T+"!A;F0@=VEL;"!T86ME M(&$@=&EM92!4('1O(')E8V]V97(L(&1E<&5N9&5N="!O;B!T:&4@=FED96\@ M8FET(')A=&4@86YD(&]T:&5R(&9A8W1O<G,[#4%F=&5R(&$@=&EM92!G<F5A M=&5R('1H86X@5"P@=&AE($U#52!T<F%N<VUI=',@=FED96]&87-T57!D871E M4&EC='5R92!T;R!T97)M:6YA;"!#.PU/;B!R96-E:7!T(&]F('9I9&5O1F%S M=%5P9&%T95!I8W1U<F4L('1E<FUI;F%L($,@<V5N9',@:71S(&YE>'0@=FED M96\@9G)A;64@:6X@DV9A<W0M=7!D871EE"!M;V1E+"!T;V=E=&AE<B!W:71H M('1H92!(+C,Q,"!6:61E;RU&<F%M92U3>6YC:')O;F]U<R!#)DD@=FED96]& M<F5E>F50:6-T=7)E4F5L96%S94-O;G1R;VP@<VEG;F%L8V]M;6%N9#L-3VX@ M<F5C96EP="!O9B!T:&4@1G)E97IE(%!I8W1U<F4@4F5L96%S92!S:6=N86QC M;VUM86YD+"!T97)M:6YA;"!!(')E=F5R=',@=&\@9&ES<&QA>6EN9R!T:&4@ M:6YC;VUI;F<@9&5C;V1E9"!P:6-T=7)E+@T-6"XU"4UO9&4@<W=I=&-H:6YG M(&%N9"!D871A(&)R;V%D8V%S="!P<F]C961U<F5S#0U8+C4N,0E":70M<F%T M92!S>6UM971R>0T-26X@82!P;VEN="UT;RUP;VEN="!C86QL+"!A;B!(+C,Q M,"!T97)M:6YA;"!C86X@<F5Q=65S="!A(&YE=R!M;V1E(&]F(&%U9&EO=FES M=6%L(&-O;6UU;FEC871I;VX@;W9E<B!T:&4@9&EF9F5R96YT(&QO9VEC86P@ M8VAA;FYE;',@=7-I;F<@=&AE(&UO9&4@<F5Q=65S="!S:6=N86QI;F<@<')O M=&]C;VP@9&5F:6YE9"!I;B!(+C(T-2!A<R!D97-C<FEB960@:6X@4V5C=&EO M;B X+CDV+C0N-"P@86YD(&-A;B!S=VET8V@@=&\@82!N97<@;6]D92!U<VEN M9R!T:&4@;&]G:6-A;"!C:&%N;F5L('-I9VYA;&EN9R!P<F]T;V-O;"!A;F0@ M8FDM9&ER96-T:6]N86P@;&]G:6-A;"!C:&%N;F5L('-I9VYA;&EN9R!P<F]T M;V-O;"P@86YD(&%I9&5D(&)Y('1H92!C;&]S92!L;V=I8V%L(&-H86YN96P@ M<VEG;F%L:6YG('!R;W1O8V]L+"!D969I;F5D(&EN($@N,C0U(&%S(&1E<V-R M:6)E9"!I;B!396-T:6]N<R X+C0M."XV-BXT+C,N("!(;W=E=F5R+"!I;B!A M(&UU;'1I<&]I;G0@8V%L;"P@=&AE<F4@87)E(&%D9&ET:6]N86P@=&5M<&]R M86P@8V]N<W1R86EN=',Z#0UB96-A=7-E('1H92!O=71P=70@<&%C:V5T<R!F M<F]M('1H92!-0U4@8V%N;F]T(&)E('-Y;F-H<F]N;W5S('=I=&@@86QL(&EN M<'5T('!A8VME=',L('1H97)E('=I;&P@=7-U86QL>2!B92!A="!L96%S="!S M;VUE(&1E;&%Y(&EN('1R86YS;6ET=&EN9R!A(&YE8V5S<V%R>2!C;VUM86YD M(&-O9&4[(&EN(&$@;6]R92!E>'1R96UE(&-A<V4@=&AE($U#52!M87D@86QR M96%D>2!B92!E;F=A9V5D(&EN(&$@8V%P86)I;&ET>6-A<&%C:71Y(&5X8VAA M;F=E('=I=&@@86YO=&AE<B!T97)M:6YA;"P@86YD('-O(&)E('5N86)L92!I M='-E;&8@=&\@;6]D92!S=VET8V@@9F]R('-O;64@=&EM93L-=&EM92!I<R!N M965D960@9F]R('1H92!-0U4@=&\@<')O8V5S<R!C87!A8FEL:71Y(&-O9&5S M(&%N9"!C;VUM86YD<R!T;R!E;G-U<F4@=&AA="!T:&4@<F5S=6QT:6YG(&UO M9&5S(&%R92!A8V-E<'1A8FQE('1O(&%L;"!T97)M:6YA;',@86YD(&%R92!I M;7!O<V5D(&EN(&-O;W)D:6YA=&EO;BP@=VET:&]U="!C;W)R=7!T:6]N(&]F M(&%N>2!V:61E;R!B96EN9R!T<F%N<VUI='1E9"X-#51O(&5N<W5R92!T:&%T M(&%N($U#52!H87,@861E<75A=&4@8V]N=')O;"P@86YD(&EN('!A<G1I8W5L M87(@=&AA="!I="!C86X@9')I=F4@=FED96\@<VEG;F%L('1R86YS;6ES<VEO M;B!T;R!A(&-O;6UO;B!R871E("AN;W1I;F<@=&AA="!I;B!T:&4@8V%S92!T M<F5A=&5D(&AE<F4@=&AE($U#52!H87,@;F\@<&]W97(@=&\@=')A;G-C;V1E M('1H92!V:61E;RDL(&)I="UR871E(&-H86YG97,@<VAA;&P@8F5A<F4@:6YI M=&EA=&5D('-O;&5L>2!F<F]M('1H92!-0U4N(%1E<FUI;F%L<RP@869T97(@ M:&%V:6YG(')E8V5I=F5D(&UU;'1I<&]I;G1#;VYF97)E;F-E(&9R;VT@34-5 M+"!S:&%L;"!N;W0@8VAA;F=E(&)I="UR871E(&5X8V5P="!I;B!R97-P;VYS M92!T;R!S=6-H(&$@8VAA;F=E(&EN8V]M:6YG(&9R;VT@=&AE($U#52X@34-5 M(&UA>2!C:&]O<V4@=&\@<V5N9"!(+C(T-2!&;&]W0V]N=')O;$-O;6UA;F0@ M=&\@86-H:65V92!T:&4@8FET+7)A=&4@<WEM;65T<GDN(%1H:7,@87!P;&EE M<R!T;R!B:70M<F%T97,@9F]R(&%U9&EO+"!D871A+"!V:61E;RP@86YD('1H M92!T<F%N<V9E<B!R871E.R!A=61I;R!A;F0@=FED96\@;6]D92!C:&%N9V5S M(&YO="!I;G9O;'9I;F<@8FET+7)A=&4@8VAA;F=E<R!M87D@<W1I;&P@8F4@ M:6YI=&EA=&5D(&)Y('1E<FUI;F%L<RX@5VAE;B!T:&4@8FET(')A=&4@:6YC M;VUI;F<@9G)O;2!-0U4@8VAA;F=E<RP@=&AE('1E<FUI;F%L<R!S:&%L;"!F M;VQL;W<@<W5I="!A<R!P<F]M<'1L>2!A<R!O=&AE<B!P<F]C961U<F5S(&%L M;&]W+"!A<R!A;GD@9&5L87D@;6%Y('!R96-L=61E('1H92!T97)M:6YA;))S M('1R86YS;6ES<VEO;B!F<F]M(&)E:6YG(')E8V5I=F5D(&)Y('1H92!O=&AE M<B!P87)T:65S(&EN(&$@8V]N9F5R96YC92X-#5@N-2XR"4UO9&4@<W=I=&-H M:6YG(&9O<B!D871A(&1I<W1R:6)U=&EO;B!I;B!M=6QT:7!O:6YT(&-O;F9E M<F5N8V5S#0U5;F1E<B!W;W)K:6YG+@T-6"XV"4U#52U-0U4@26YT97)C;VYN M96-T:6]N<PT-56YD97(@=V]R:VEN9RX-#5@N-PE%>&-E<'1I;VYA;"!P<F]C M961U<F5S#0U5;F1E<B!W;W)K:6YG+@T-#5DN"4%D=F%N8V5D(&-O;6UU;FEC M871I;VX@<')O8V5D=7)E<R!U<VEN9R!4+C$R,"]4+C$S,"!C;VYT<F]L<PT- M1F]R(&9U<G1H97(@<W1U9'DN#0T-+2TM+2TM+2TM+2TM+2TM+2TM/"!/:W5B M;]5S(&YO=&5S(#XM+2TM+2TM+2TM+2TM+2TM+2T-#3$N"5-I;7!L92!E9&ET M;W)I86P@8V]R<F5C=&EO;G,L('-U8V@@87,@<W5B:F5C="UV97)B(&-O<G)E M<W!O;F1E;F-E+"!H879E(&)E96X@;6%D92!W:71H;W5T(&-H86YG92!M87)K M<PT-,BX)06YO=&AE<B!C;VUM=6YI8V%T:6]N('!R;V-E9'5R92!S96-T:6]N M(&9O<B!V:61E;R!M:7AI;F<_(%!E<FAA<',@;F]T+B!792!C86X@96%S:6QY M(&5X=&5N9"!396-T:6]N(%@@=&\@8V]V97(@=FED96\@;6EX:6YG(&9R;VT@ M=&AE('!R;V-E9'5R92!P97)S<&5C=&EV92X@270@=V]U;&0@8F4@8F5T=&5R M('1O(&%D9')E<W,@8F%S:6,@8V]M;75N:6-A=&EO;B!P<F]C961U<F5S('=I M=&@@86YD('=I=&AO=70@=FED96\@;6EX:6YG+"!B=70@=7-I;F<@2"XR-#4@ M86YD($@N,S$P(&-O;G1R;VQS+@T-,RX)06YO=&AE<B!C;VUM=6YI8V%T:6]N M('!R;V-E9'5R92!S96-T:6]N(&9O<B!P;VEN="UT;RUM=6QT:7!O:6YT(&-O M;F9I9W5R871I;VX_#0TT+@E!9&0@=&AE(&9O;&QO=VEN9R!D969I;FET:6]N M<SH-#7-E;&5C=&5D(&-O;6UU;FEC871I;VX@;6]D92 H4T--*3H@82!C;VUM M=6YI8V%T:6]N(&UO9&4@=VAI8V@@34-5(&ED96YT:69I97,@=&\@=7-E(&EN M(&$@<&%R=&EC=6QA<B!M=6QT:7!O:6YT(&-O;6UU;FEC871I;VX@<V5S<VEO M;BX@4V5E($@N,C0S+@T-<')I;6%R>2!T97)M:6YA;#H@82!T97)M:6YA;"!W M:&EC:"!S=7!P;W)T<R!T:&4@4T--+B!3964@2"XR-#,N#0US96-O;F1A<GD@ M=&5R;6EN86PZ(&$@=&5R;6EN86P@=VAI8V@@9&]E<R!N;W0@<W5P<&]R="!T M:&4@4T--+B!3964@2"XR-#,N#0TU+@E);B"D6"XT8RDL($D@:&%V92!C:&%N M9V5D(-)F<F%M92!A;&EG;FUE;G0@:7,@;&]S=-,@=&\@TG9I9&5O(&1E8V]D M:6YG('!R;V-E<W,@;6%Y(&)E(&1I<W)U<'1E9-,@8F5C875S92!F<F%M92!A M;&EG;FUE;G0@;6%Y(&EM<&QY('1H870@;V8@2"XR,C$N(%1H97)E(&ES(&YO M(&-O<G)E<W!O;F1I;F<@TF9R86UETR!I;B!(+C(R,BXQ+S N#0TV+@E);B!T M:&4@8FET(')A=&4@<WEM;65T<GD@9&5S8W)I<'1I;VX@:6X@I%@N-2XQ+"#2 M34-5(&UA>2!C:&]O<V4@=&\@<V5N9"!(+C(T-2!&;&]W0V]N=')O;$-O;6UA M;F0@=&\@86-H:65V92!T:&4@8FET+7)A=&4@<WEM;65T<GDNTR!H87,@8F5E M;B!S=&%T960@86-C;W)D:6YG('1O('1H92!D:7-C=7-S:6]N(&EN(%-U;G)I M=F5R("AS964@I#0N,RXR+T%00RTQ,S(W*2X@5&AI<R!I<R!B87-E9"!O;B!M M>2!U;F1E<G-T86YD:6YG('1H870@875D:6\L('9I9&5O(&%N9"!D871A(')A M=&5S(&-A;B!B92!C;VYT<F]L;&5D(&5I=&AE<B!B>2!(+C(T-2!&;&]W0V]N M=')O;$-O;6UA;F0@;W(@4F5Q=65S=$UO9&4N($AO=V5V97(L('1H92!T<F%N M<V9E<B!R871E(&-A;B!O;FQY(&)E(&-O;G1R;VQL960@8GD@2"XR-#4@1FQO M=T-O;G1R;VQ#;VUM86YD+B!)<R!M>2!U;F1E<G-T86YD:6YG(&-O<G)E8W0_ M#0T-14Y$#0T-&@". )SA IWA J2%+J7"0::*!:>*!:BY ZF;!'P @ P M $@ 2 #+@(Z__+_\@,\ D4#1P5[ ^ @ $@ 2 "V (H $ M !D 0 # P, _P !)P\ 0 ! 8 @ &0&0 M 0 #0SQ'@H;$:X0 M .P #__X "0 & $ ! $ " M ?____X /______________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________!0!3 '4 ;0!M &$ M<@!Y $D ;@!F &\ <@!M &$ = !I &\ ;@ M "@ @#_______________\ M " [0$ M M /_______________P M M ____ M____________ M M #_____________ M__\ M # +T!0 " =M/RS.<!0 #$BAP# +T! P # M $ !X 3 36EC<F]S;V9T(%=O<F0@-BXP , M '@ ( R , /__@ ) 8 M '____^ #_________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_____________________________P # " P -0, #8# W P .P, M $(# !# P M@, %($ !3! 500 ,T$ #1! V00 .P$ 9!0 M5P4 '<% "N!0 M 4 *D& "J!@ A < (4' #@" X0@ &\) "% M"0 U@D .$) ="@ 'PH $(* !'"@ I@H *<* "M"@ ^0H /X* M E"P 3 L )0+ "9"P \@L /4+ ]#0 2 T $L- ###0 S@T M -$- "3#@ E X ,\. #0#@ UPX -@. 2#P 20\ %4/ !I#P M;@\ ( / #&$ R1 ,X1 #4$0 YA$ /@1 #[$0 /!( #T2 _ M$@ 01( /[W_@#^\/X [0#M /[I_NGM .WC[0#MZ>WI[>GMZ>T [0#I[0#M MW>W8[>GM .W2RNW$O.T [0#M .W8[>GMZ>T [0#MZ?[M .T .08%% 0!& M0!0<1DD! "D*!10$ 1D 4'$8 #D&!10$ 1CL4'$9) 0 I"@44! $8[ M%!Q& A6@5X!20$ *0H%% 0!&FA0<1@ *0H%% 0!&'Q0<1@ &58%) 0 M 1) 0 Q"@44! $8>%!Q&58$ #$*!10$ 1AT4'$95@0 "58%*01( %82 M !A$@ 9Q( '$2 ",$@ C1( ) 2 #G$@ #A0 " 4 \% /10 M ($4 ""% IQ4 *@5 #>%0 WQ4 &46 !F%@ :Q8 &P6 !R%@ MB!8 )T7 "A%P R!< .\7 !& A@ "H8 O& 8Q@ )D8 "E M& N1@ ,0: #*&@ W!H .X: #Q&@ ,QL #0; V&P .!L $T; M !8&P 8AL &H; "%&P AAL (D; #2&P S1P -\< #[' _!P M $ = !!'0 )!X "4> !;'@ 7!X *L> "L'@ Q\ !L? G'P M.A\ -L? #C'P [A\ 0@ #!( UR #,A T(0 _?G]\_WS_>[] M^?T _0#] /T _0#] /WY_0#][OT _>C][OWY_0#]^>;] /T _?G]X/W@_>[] M^?T _0#] /T _0#]^?W8_=+]^?WY_<P "D*! M10$ 1KL4'$8 "D*!10$ 1K<4'$8 #D&!10$ 1IL4'$9) 0 I"@44! $:5 M%!Q& )5@0 *0H%% 0!&FQ0<1@ (5H%> 4D! "D*!10$ 1EP4'$8 !E6! M20$ $20$ $TT(0 -2$ #DA !5(0 ?R$ ),A ":(0 FR$ &\B M !Q(@ <B( '4B "9(@ P"( -,B #4(@ '2, "(C G(P ,R, M &DC !U(P B2, )(E "8)0 JB4 +PE "_)0 "8 $F #)@ M!28 !HF E)@ +R8 #<F !2)@ 4R8 %8F "+)@ A2< )<G #W M)P ^"< -HH #;* $2D !(I !B*0 8RD +XJ #"*@ )"L "@K M I*P *BL )LK "?*P H"L *$K O+ 02P #DM !*+0 \2T M /4M &+@ N"X +DN #,+@ WRX !\O X+P ^/+JY-[; -L VP#; MUML V]#(V];;Q-L V\3"VP#; -O$V[S;O-O6V\3; -L VP#; -L VP#; -L MVP#;Q-O$V\+$VP#;Q-NV"D*!10$ 1B$;'&8 "D*!10$ 1L44'$8 E6! 95 M@4D! #D&!10( 1L 4'$9) 0 I"@44! $; %!Q& A6@5X!20$ $ M20$ *0H%% 0!&NQ0<1@ *0H%% 0!&NA0<1@ .0H%% 0!&NA0<1DD! M"D*!10$ 1KD4'$8 #D&!10$ 1KL4'$9) 0 2#@O ""+P E2\ )8P "< M, O3 -0P !;,0 <3$ (\Q "E,0 ]3$ !,R 4,@ &#( #@R M Y,@ /S( $8R !Q,@ =S( 'XR "_,@ P#( ,HR #3,@ YC( M / R #Q,@ \C( /@R F,P )S, ,HS #7,P XC, .4S #J,P MN30 ,DT #0- T30 -(T #9- WC0 "HU K-0 $38 !LV C M-@ -C@ #XX !!. @C@ )8X #]^?WS[>7]^?WY_=_]W_G]V=']V='] M ,_YR,'Y_0#] /VY_;.Y_;G]K?VMI?T _9^7_9&)_?D.08%% 0!&D1L<9DD! M "D*!10$ 1I$;'&8 #D&!10$ 1HL;'&9) 0 I"@44! $:+&QQF Y! M@44! $9@&QQF20$ *0H%% 0!&8!L<9@ *0H%% 0!&7QL<9@ .08%% 0!& M7QL<9DD! #$*!10$ 1DD;'&95@0 ,0H%% 0!&2!L<9E6! )5@0 .08%% M 0!&-!L<9DD! "D*!10$ 1C0;'&8 "D*!10$ 1C,;'&8 #D&!10$ 1H@; M'&9) 0 I"@44! $:(&QQF I"@44! $:*&QQF 95@4D! !$D! V MEC@ /8X 3.0 )3D $@Y #6.@ USH -TZ K.P +#L "T[ Q M.P 2CL $L[ !9.P 6SL %\[ !U.P A3L (@[ #5.P VCL -P[ M 6/@ -SX *@^ "X/@ Z3X /L^ !+0 74 #5! !'00 2T$ M %9! "300 I4$ ,I! #+00 S$$ &1" #]]_#W_0#JY #]XMX _0#B MWOT V-+8 .( X@#B .( X@#> .( #0 M M M M M "=0$ "D*!10$ 1NT;'&8 "D*!10$ 1C44'$8 !E6!20$ M "58$ "D*!10$ 1ED;'&8 "D*!10$ 1DH;'&8 #$*!10$ 1LD;'&95@0 * M0H%% 0!&R1L<9@ $20$ "@ P -@, #<# !# P 1 , ,P$ #-! M& 4 !D% !P!@ <08 *H& "K!@ \P8 (4' #A" ,@D #,) !" M"@ 0PH *8* "G"@ _@ /X #^ _@ /X M #^ X0 .$ #A X0 .$ M #A P , # P /X #^ M _@ *, "& M ' ##0 (X @ " !0 0!H 0 "X@ M !P PT ". ( @ 4 ( M: $ N( @ - M"A%H 1.8_@PT ". ( @ 4 $ : $ I( M < ,- 0@ /__ ! &@! +@ M 0 %:<* #0"@ T0H M "0+ E"P 30L $X+ !S#@ = X !$/ 2#P 2@\ $L/ #6$0 MUQ$ (\2 "0$@ Z!( .D2 #^%0 _Q4 &P6 !M%@ L!8 .L6 #C M Q@ ,8 #& Q@ ,8 #& M Q@ ,8 #& Q@ ,8 #& MQ@ ,8 "H Q@ *@ #& Q@ M ,8 #& AP (< " T+$6@!$YC^ M##3_ 0 ( ! 0!H 0 +< M !T T,##3_ 0 ( ! 0!H 0 +< M !P PT_P$ " 0 $ : $ M "W < ,- " M 3@" ( % ! &@! ,BX@ M 8ZQ8 .P6 !"%P 0Q< )P7 "=%P QQ< ,@7 #P%P \1< M &(8 !C& FA@ )L8 #,&@ S1H (@; ")&P TQL -0; "Q'0 MLAT *P> "M'@ XP ., #C XP ., M #& J ., #C XP ., #C M B@ ., #C XP ., #C M B@ ., #C %X(_ XP #>"/P ., 7@C\ M '0 #0P,-/\! @ $ ! &@! MP M '0 #0P,- " 3@" ( % " M &@! ,BX@ ' M##0 @$X @ " !0 @!H 0 #(N( M !P PT_P$ " 0 $ : $ "W M !>M'@ M1X #X? "C'P JQ\ (@@ M V(0 E"$ )LA #U(0 ;B( &\B "8(@ F2( -\ "^ M O@ ">"/P -\ "^ O@ #>"/P +X G@C\ #? MO@ +X G@C\ "A A &< M M !P PT (!. ( @ 4 $ : $ R+B M < ,- " 3@" ( % " &@! ,BX@ M ' ##3_ 0 X @ # !0 M 0!H 0 &X " M T+$6X$$U?^##3_ 0 X @ # !0 0!H 0 &X M " T+$6@!$YC^##3_ 0 ( ! 0!H M 0 +< #9DB #! M(@ PB( #(C S(P :B, &LC ":)0 FR4 %4F !6)@ BR8 (PF M !G* :"@ &,I !D*0 ;"D *HI #C XP !>"/P ., G@C M\ #C %X(_ XP !>"/P ,4 #C XP !>"/P ., W@C\ "H M XP ,4 #C XP !>"/P ., W@C\ #C %X M(_ AP &8 " T+$6X$$U?^##3_ 0 X @ # !0 0!H M 0 &X " T+ M$6@!$YC^##3_ 0 ( ! 0!H 0 +< M !P PT (!. ( @ 4 $ : $ R+B M = -# PT_P$ " 0 M $ : $ "W < M ,-/\! @ $ ! &@! MP M 2JBD !<J ?*@ Q"H ,HJ C*P )"L %HK !; M*P FBL -\ "^ WP +X #? H0 M (0 !G 2@ M !P PT (!. ( @ 4 $ : $ M R+B < ,- " M 3@" ( % ! &@! ,RX@ M ' ##0 @$X @ " !0 ! !H 0 #,N( M !P PT_P$ . ( P 4 $ : $ !N M @ -"Q%H 1.8_@PT M_P$ " 0 $ : $ "W M @ -"Q%N!!-7_@PT_P$ . ( P 4 $ : $ !N M F:*P FRL +<K "X*P M["P (0M #P+0 \2T 8N '+@ N2X +HN #C Q@ M *D "I 1X(_ B (@$_W@C, *I :P $X M !. )X(_ 3@ !>"/P M < ,- $ 3@" ( % ! &@! -"XQ+B M ' ##0 (X @ " !0 P!H 0 "X@ M " T+$6@!$YC^##3_ M 0 ( ! 0!H 0 +< M !P PT (!. ( @ 4 $ : $ R+B M < ,- " 3@" ( % & &@! M,BX@ ' ##0 ! $X @ " M !0 0!H 0 #(N-2X@ M"[HN !O+P 6# "PQ "!,0 2#( +\R # ,@ \3( /(R *,P M"S, "LU L-0 >C8 %4W !6-P UCH -<Z #? WP #>"/P M -\ W@C\ #? %X(_ WP #>"/P -\ G@C\ #= P *, M #= A@ (8 !G@C\ "& %X(_ WP -\ W@C M\ !I :0 *>"/P &D 7@C\ !P PT! !" 8 M $ : $ I < M ,- " 3@" ( % ! &@! -2X@ M ' ##0 (X @ " !0 0!H 0 "X@ M !P PT ". H @ 4 4 : $ M N( ! ( M#0H1: $3F/X,- 0 0@ & ! &@! *0 M 2USH !P[ =.P +#L "T[ !*.P 2SL M %H[ !;.P =CL '<[ "&.P ASL (@[ #(.P R3L -P[ #=.P MWCL !0\ 5/ ?SP ( \ "?/0 H#T /(] #S/0 %3X !8^ "G M/@ J#X .@^ #I/@ ,S\ #0_ #C XP !>"/P ., 7@C\ #C M %X(_ Q@ ,0 #$ %X(_ Q !>"/P ., 7@C\ #C %X M(_ Q ,0 7@C\ #$ %X(_ Q !>"/P ,0 7@C\ #$ %X(_ MQ !>"/P ,0 7@C\ #! %X(_ Q ,0 G@C\ #$ %X(_ Q $ M>"/P ,0 7@C\ #$ %X(_ Q !>"/P ,0 7@C\ #$ %X(_ Q ">"/P M ,0 7@C\ #$ %X(_ Q !>"/P ,0 7@C\ #$ %X(_ " M % 0 ! ' ##0 @$X @ " !0 !0!H 0 #,N( M !P PT! !" 8 $ : $ M I "(T/P ^3\ /H_ M #$00 Q4$ ,9! #*00 RT$ ,Q! #^ -X(_ _@ !>"/P /X !G@C M\ #^ %X(_ _@ !>"/P /X 7@C\ #^ _@ !>"/P M M M M M M M M M M 0 " X $0 ( $ 2P / ! < ! \?\" !P !DYO<FUA; " M!@!A"01C& B $% \O^A "( %D1E9F%U;'0@ M4&%R86=R87!H($9O;G0 #P 'F ! /( / /06YN;W1A=&EO M;B!497AT 7 \ !0,5B /#@ $&@.G!#0&P0< 8 70 8Q0 .@#^ M;P$ @$Z AE;G5M;&5V,0 = ! !0,1IP03<_X55@ /#@ $&@.G!#0&P0< M 8 70 8Q0 S#X # ,P^ ' ,Q! ' .A! & M 0!__\! __\" 0 __\# __\$ 0 __\% __\& A#@ ML1H &0F L,@ ^3P ,P^ +4 ! $ " @ # $X! $ M $ % P 01( #0A X+P EC@ &1" B ", ) E "8 M , *<* #K%@ K1X )DB "J*0 FBL +HN #7.@ -#\ ,Q! G M "@ *0 J "L + M "X +P P #8 !U5N:VYO=VX =A:V%S86MA 0 =075T M:&]R:7IE9"!5<V5R =5;FMN;W=N % , !$ @=A:V%S86MA.TUA M8VEN=&]S:"!(1#I$97-K=&]P($9O;&1E<CI7;W)K(&9O;&1E<CI396-T:6]N M(%@@;V8@2"YB;7!T!V%K87-A:V$R36%C:6YT;W-H($A$.E1E;7!O<F%R>2!) M=&5M<SI7;W)D(%=O<FL@1FEL92!!(#$S-C8'86MA<V%K83)-86-I;G1O<V@@ M2$0Z5&5M<&]R87)Y($ET96US.E=O<F0@5V]R:R!&:6QE($$@,3,V-@=A:V%S M86MA,DUA8VEN=&]S:"!(1#I496UP;W)A<GD@271E;7,Z5V]R9"!7;W)K($9I M;&4@02 Q,S8V!V%K87-A:V$R36%C:6YT;W-H($A$.E1E;7!O<F%R>2!)=&5M M<SI7;W)D(%=O<FL@1FEL92!!(#$S-C8'86MA<V%K83M-86-I;G1O<V@@2$0Z M1&5S:W1O<"!&;VQD97(Z5V]R:R!F;VQD97(Z4V5C=&EO;B!8(&]F($@N8FUP M= =A:V%S86MA.TUA8VEN=&]S:"!(1#I$97-K=&]P($9O;&1E<CI7;W)K(&9O M;&1E<CI396-T:6]N(%@@;V8@2"YB;7!T!V%K87-A:V$:4D%-((-F@T*#6(-. M.E-E8W1I;VY?6"YD;V,'86MA<V%K83M-86-I;G1O<V@@2$0Z1&5S:W1O<"!& M;VQD97(Z5V]R:R!F;VQD97(Z4V5C=&EO;B!8(&]F($@N8FUP= =A:V%S86MA M&E)!32"#9H-"@UB#3CI396-T:6]N7U@N9&]C_T #@ $ %3D !4Y ' $ M 5.0 !4Y ! /__?0-W DT %0:0 4T 5&EM97,@3F5W(%)O;6%N M P&D $" %-Y;6)O; +!I !30!!<FEA; /!I ! @!7:6YG9&EN9W, "P:0 M 4T 5&EM97, (@ $ #$(C!@ - " !H 0 #R&QQF\AL<9@ " M 0 @Q M *0E %@ V6"X)0F%S:6,@8V]M;75N:6-A=&EO;B!P<F]C961U<F5S M('5S:6YG($@N,C0U(&-O;G1R;VQS !V%K87-A:V$'86MA<V%K80 M #0SQ'@H;$:X0 .P #__X "0 & M $ ! $ " ?____X /______ M____________________________________________________________ -____________________ end

1 0

GCL ftp site has got back to operation
by Sakae Okubo 03 Dec '97

03 Dec '97

Dear Q.12-14/16 experts, GCL ftp site (ftp://itu-t:sg15!avc@ftp.gctech.co.jp) has been restored; it is now accessible. Please Mr. Webber resume your mirroring. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

1 0