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

H.225.0V2 comment
by Karl Klaghofer 24 Sep '97

24 Sep '97

Glen, Joerg, Pete, Amotz and others, In the Sunriver Meeting, the type for the element h4501SupplementaryService in the H323-UU-PDU was changed from "SEQUENCE OF H4501SupplementaryService OPTIONAL" to "OCTET STRING OPTIONAL". We request to modify the current definition in H.225.0V2 Draft as follows (including a short comment): ******** "h4501SupplementaryService SEQUENCE OF OCTET STRING OPTIONAL" -- each sequence of octet string is defined as one H4501SupplementaryService APDU -- as defined in TABLE3/H.450.1 ******** Reason for change: With the previous definition (SEQUENCE OF H450SupplementaryService) it was possible to signal multiple H450SupplementaryService APDUs within one User-user information element. This is required if APDUs which require different NetworkFacilityExtension and/or EntityType encoding have to be sent within one single message. With just using "OCTET STRING", we see compatibility problems between different vendors Supplementary Service implementations in case of multiple H4501SupplementaryService APDUs beeing used. Remark: The alternative - to change the H.4501SupplementaryService APDU structure - should be avoided at this stage. The comment "-- each sequence ....." as proposed above shall give at least textual linkage between H.225.0V2 and the corresponding H.450.1 module. Regards, Karl Klaghofer //////////////////////////////////////////////////////////////// Siemens AG Munich Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488 Fax.: +49 89 722 23977 email: karl.klaghofer(a)mch.pn.siemens.de ////////////////////////////////////////////////////////////////

2 1

H.235 Draft
by Jim Toga 23 Sep '97

23 Sep '97

Greetings, I have placed the latest version of H.235 White paper at the Incoming directory of the ITU-T ftp site. (H235White.zip) any comments appreciated. Regards, jimt. ************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************

1 0

Re: H.323V2 draft
by Lior Moscovici 23 Sep '97

23 Sep '97

Gary, There is a slight misunderstanding with the responses to IRR: in H.323 they are called ICF & IRJ, while in H.225.0 they are called IACK & INAK respectively. I don't care how they are called, as long as it is consistent... Lior Moscovici -------- On 09/22/97 12:06 PM MST gthom(a)DELTA-INFO.COM wrote: All, H323v2i.doc has been uploaded to the gctech ftp site. It is complete except for the text on empty capability sets (TD-27) and Annex C on H.323 over ATM. Let me know if any of your changes have been missed, or have not been incorporated properly. Gary ------------------------------------- Name: Gary Thom Company: Delta Information Systems, Inc. Phone: +1-215-657-5270 x23 Fax : +1-215-657-5273 E-mail: gthom(a)delta-info.com Date: 09/22/97 Time: 08:57:14 -------------------------------------

1 0

Re: Req: Clarification on fast setup
by Jim Toga 23 Sep '97

23 Sep '97

Pete, My comments are interspersed below.... Regards, jimt. At 05:27 PM 9/23/97 +0100, you wrote: >Jim, > >Looking at the fast start stuff, I'm confused about the format of the >FastCap field and how it is used. Is the intention to allow multiple >multiplexCapbility fields in the SETUP? How would this be used as H.245 >allows only one instance of the field? Perhaps the encoding below would Good point, your representation is marginally better.... although I think simply stating that it is only relevant once per FastCap entry is enough. I'm not sure that removing the OPTIONAL from Capabilty lends that much. >describe the intended use better. > >FastCap ::= SEQUENCE >{ > caps SEQUENCE OF Capability, > multiplexCap multiplexCapability OPTIONAL, > ... >} > >Setup-UUIE ::= SEQUENCE >{ > -- deleted fields > cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL, > fastStart SEQUENCE OF OpenLogicalChannel OPTIONAL, > fastCap FastCap OPTIONAL, > canOverlapSend BOOLEAN >} > >Perhaps the semantics could describe this better if this is the case. > >I also have a few questions: > >In Glen's text it mentions that the OpenLogicalChannel parameters in the >SETUP message indicate parameters to be used in the callee to caller >direction, i.e. the reverse sense to an H.245 OpenLogicalChannel. As >the text in H.323 says that these are the parameters "that would >normally be passed later in the H.245 OpenLogicalChannel" I'm wondering >if the statement is correct. If the sense truly is reversed, then this >should be brought out more in the text in H.323. The point is that 'normally' one shouldn't radically change their capabilites from the FastStart mechanism to the regular H.245 cap exchange.... > >Also, what I am not clear on is if a terminal can receive and transmit >G.723 and G.729 how it should indicate this in the fast channel mode. They would simply do this as with H.245 - by including a set of receive and transmit caps that indicate G.723 and G.729.....? >Negotiation is important for this as G.723 might be the safer bet, but >G.729 might be better for delivery of in-band DTMF tones (or simply have >lower delay). Also, future codecs that are better tailored to the >Internet may be developed, and you want to be able to use these as soon >as possible. Could you supply an example of this? I'm really not sure what you're getting at here? Any codepoints that are defined in H.245 can be utilized (along with nonStandard...) > >How well do you see the scheme working when MCs are involved. Is it the >case that MCs will have to use slow start, or have I missed something? In so far as MCs are callable entities which 'look like' endpoints it works fine. As soon as any multipoint operations are commenced, the expectation at this point, is that H.245 is utilized. >MCs won't be able to use communicationModeCommand so I guess they won't >be able to instruct endpoints what to do in any forcible way. Is this >correct? As we have much special text in H.323/H.225 on making MCs >work, perhaps some text on how MCs and fast start interwork should be >included. The original intent of this mechanism was not to provide a seamless solution in all situations - it was to provide a fast connection sequence for pt-pt calls. > >Perhaps some annotated ladder diagrams would be useful. I appreciate >that you haven't had much time though. As a question to the wider >community (Dale!), would it be possible to add extra clarifying text of >this nature in January if it was felt to be useful? > >Best regards, > >Pete >================================= >Pete Cordell >BT Labs >E-Mail: pete.cordell(a)bt-sys.bt.co.uk >Tel: +44 1473 646436 >Fax: +44 1473 645499 >================================= > > ************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************

1 0

Req: Clarification on fast setup
by Pete Cordell 23 Sep '97

23 Sep '97

Jim, Looking at the fast start stuff, I'm confused about the format of the FastCap field and how it is used. Is the intention to allow multiple multiplexCapbility fields in the SETUP? How would this be used as H.245 allows only one instance of the field? Perhaps the encoding below would describe the intended use better. FastCap ::= SEQUENCE { caps SEQUENCE OF Capability, multiplexCap multiplexCapability OPTIONAL, ... } Setup-UUIE ::= SEQUENCE { -- deleted fields cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL, fastStart SEQUENCE OF OpenLogicalChannel OPTIONAL, fastCap FastCap OPTIONAL, canOverlapSend BOOLEAN } Perhaps the semantics could describe this better if this is the case. I also have a few questions: In Glen's text it mentions that the OpenLogicalChannel parameters in the SETUP message indicate parameters to be used in the callee to caller direction, i.e. the reverse sense to an H.245 OpenLogicalChannel. As the text in H.323 says that these are the parameters "that would normally be passed later in the H.245 OpenLogicalChannel" I'm wondering if the statement is correct. If the sense truly is reversed, then this should be brought out more in the text in H.323. Also, what I am not clear on is if a terminal can receive and transmit G.723 and G.729 how it should indicate this in the fast channel mode. Negotiation is important for this as G.723 might be the safer bet, but G.729 might be better for delivery of in-band DTMF tones (or simply have lower delay). Also, future codecs that are better tailored to the Internet may be developed, and you want to be able to use these as soon as possible. Could you supply an example of this? How well do you see the scheme working when MCs are involved. Is it the case that MCs will have to use slow start, or have I missed something? MCs won't be able to use communicationModeCommand so I guess they won't be able to instruct endpoints what to do in any forcible way. Is this correct? As we have much special text in H.323/H.225 on making MCs work, perhaps some text on how MCs and fast start interwork should be included. Perhaps some annotated ladder diagrams would be useful. I appreciate that you haven't had much time though. As a question to the wider community (Dale!), would it be possible to add extra clarifying text of this nature in January if it was felt to be useful? Best regards, 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: reRouteIndication
by Callaghan, Robert 23 Sep '97

23 Sep '97

Pete, Not to judge the merits of your argument, but I think that there is a procedure problem. H.245, H.225.0, and the H.450.x series of specification were closed based on the input from Sun River. I consider the introduction of new feature requirement at this time is not acceptable. Major additions without a public hearing is not acceptable. This mail exploder does not constitute a public hearing. These proposals should be for the next version. Yes, minor editorial changes can be made in the January Geneva meeting. What you are proposing involves a major philosophical question, the level of support for features outside of H.450. Bob -------------------------------------- Robert Callaghan Siemens Business Communication Systems Email: Robert.Callaghan(a)Siemenscom.com Tel: +1.561.997.3756 >-----Original Message----- >From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] >Sent: Friday, September 19, 1997 1:17 PM >To: ITU-SG16(a)mailbag.jf.intel.com >Subject: Re: reRouteIndication > >Ernst, Glen, > >I was working on a TD in Sunriver to suggest that Notify should be used, >but I was advised that this was not the right message. It may be that >Notify is the closest message to what is required and so I have no >objections to it being used. > >Glen has also suggested that additional fields such as reRouteReason, >endpointAlias, originalDestination, and reRouteCounter should be added. >The first two I agree with. The second one I'm not sure of what it >means so don't know whether I agree with it or not. On reRouteCounter, >I'm not sure what it would be counting. For the Facility-UUIE based >re-route this is used so that the endpoint can check for infinite loops. > As this would be used as a notify that a re-route had already been >done, then the usefulness of this information is limited. > >As to whether we include an indication of this sort, I am very wary of >feature creep also. However, to me this seems such a fundamental call >control feature that it shouldn't require supplementary service support. > It should also be emphasized that this is not a replacement for >anything in H.450.2, and ctComplete should be used when H.450.2 is in >use. It is also light weight to implement; endpoints would not have to >process it on reception, and re-routers should generate it, but it >shouldn't be mandatory for them to generate it (for reasons such a >anonymity in security and things like that). > >Given these suggestions, a revised PDU might be: > >H323-UU-PDU ::= SEQUENCE >{ > h323-message-body CHOICE > { > setup Setup-UUIE, > callProceeding CallProceeding-UUIE, > connect Connect-UUIE, > alerting Alerting-UUIE, > userInformation UI-UUIE, > releaseComplete ReleaseComplete-UUIE, > facility Facility-UUIE, > ..., > progress Progress-UUIE, > dummy NULL, > notify CHOICE > { > reRouteIndication >ReRouteIndication, > ... > } > }, > nonStandardData NonStandardParameter OPTIONAL, > ..., >h4501SupplementaryService SEQUENCE OF H4501SupplementaryService >OPTIONAL >} > >ReRouteIndication ::= SEQUENCE >{ > -- display no longer needed as this is in Notify message > reRouteReason CHOICE > { > h4502Proxy NULL, > thirdPartyService NULL, > secondaryDialling NULL, > qSIGInterworking NULL, > ... > } > endpointAlias SEQUENCE OF AliasAddress, > endpointInfo EndpointType, > ... >} > >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: 19 September 1997 10:40 >>To: ITU-SG16(a)mailbag.jf.intel.com >>Subject: Re: reRouteIndication >> >>Dear Pete, >> >>some observations on your mail: >> >>> It has been mentioned that when a gatekeeper performs a re-route it >>> would be good for the client to know about it. After much >>> investigation, there seems to be no message in Q.931 that handles this >>> case. >> >>The Notify message could be used for that purpose (as an alternative to >>Facility), but again, its use is supplementary-service specific (and >>was >>removed from H.450.1). In QSIG we use Facility whenever the information >>is to be processed by the endpoint, which is nearly always the case. >>Notify is restricted to situations where (less important) information >>is >>passed to the user without acting on it, and loss of the information >>would not be of great concern for the overall working of a feature. >> >>> In the text that I proposed in Sunriver I suggested that a >>> Facility message with a H.450 ctComplete should be sent. >>> However, this is not much use to an entity that does >>> not support supplementary services. >> >>The same situation can arise in the ISDN and QSIG case. But that does >>not prevent the re-routing from taking place, it only means that this >>terminal cannot display the information. >> >>> Therefore it might be useful to add can extra case to the >>> H323-UU-PDU to cover this, e.g.: >>> >>> H323-UU-PDU ::= SEQUENCE >>> { >>> h323-message-body CHOICE >>> { >>> setup Setup-UUIE, >>> callProceeding CallProceeding-UUIE, >>> connect Connect-UUIE, >>> alerting Alerting-UUIE, >>> userInformation UI-UUIE, >>> releaseComplete ReleaseComplete-UUIE, >>> facility Facility-UUIE, >>> ..., >>> progress Progress-UUIE, >>> dummy NULL, >>> reRouteIndication ReRouteIndication >>> }, >>> nonStandardData NonStandardParameter OPTIONAL, >>> ..., >>> h4501SupplementaryService SEQUENCE OF H4501SupplementaryService >>OPTIONAL >>> } >>> >>> ReRouteIndication ::= SEQUENCE >>> { >>> display IA5String (SIZE( 0..255) ), >>> endpointInfo EndpointType, >>> ... >>> } >>> >>> This could then be sent by a gatekeeper when a re-route has been done. >>> >> >>Your proposal does not say which message you would use. If it is >>Facility, then the Facility-UUIE could be enhanced instead. >> >>However, I have a more general concern with this new proposal: >>An endpoint would still have to be upgraded to understand this coding. >>The only advantage compared to your original proposal (i.e. using an >>operation) might be slightly less complex coding. However, it goes >>against the intention of H.450.x. The idea behind the approach in H.450 >>is *not* to add new coding in H.225.0 whenever new functionality is >>created, but to use the *generic* container 'H4501 Supplementary >>Service >>APDU' and confine all new functionality plus coding to the >>supplementary >>service recommendation. This allows a neat modular approach where you >>tailor your system by choosing the right building blocks. >>Therefore I prefer using operations wherever possible. >> >>Kind Regards, >>Ernst >>================================ >>Ernst Horvath >>Siemens AG >>Tel: +43 1 1707 45897 >>Fax: +43 1 1707 56992 >>Email: ernst.horvath(a)siemens.at >>================================ >>

1 0

[Federico.Tosco@CSELT.IT: SG 16 future meetings]
by Sakae Okubo 23 Sep '97

23 Sep '97

Return-Path: <Federico.Tosco(a)CSELT.IT> Return-Receipt-To: Tosco Federico <Federico.Tosco(a)CSELT.IT> Date: Fri, 19 Sep 1997 17:30:30 +0200 From: Tosco Federico <Federico.Tosco(a)CSELT.IT> Subject: SG 16 future meetings To: "Blaschitz, Michael" <michael.blaschitz(a)infonova.at>, "DeGrasse, Bruce" <b.degrasse(a)mci2000.com>, "Geary, Tom" <tom.geary(a)nb.rockwell.com>, "Okubo, Sakae" <okubo(a)gctech.co.jp>, "Robin-Champigneul, Yves" <yves.robin-champigneul(a)issy.cnet.fr>, "Skran, Dale" <Dale.Skran(a)ascend.com>, "Thom, Gary" <gthom(a)delta-info.com> X-Envelope-To: okubo(a)gctech.co.jp Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Content-Transfer-Encoding: 7BIT X-Priority: 3 Dear colleagues, During the SG 16 coordination meeting in Sunriver Mr. Bigi has given the tentative dates of the future meetings of SG 16 in 1999 and 2000: March 1999 February 2000 The delay between the two meetings is very long. It would be good if we could have an invitation for a SG 16 (or Joint WPs) meeting in between. As you know the 1998 meetings are scheduled as follows: 26 January - 6 February 14-25 September Best regards Federico

1 0

Re: TD-27 text for h.323
by Pete Cordell 23 Sep '97

23 Sep '97

Gary, I forgot to mention where I thought TD-27 text should go. I think the best place for it would be 8.4.6 (a new section in the Sunriver version) after the MC cascading part. This brings it in as part of Phase D: Call Services. Of the other options you mentioned, the first seems a bit tutorially, and the second is too early in the sequence of events. 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: gthom[SMTP:gthom@DELTA-INFO.COM] >Sent: 19 September 1997 19:47 >To: ITU-SG16(a)mailbag.jf.intel.com >Subject: TD-27 text for h.323 > >Pete and others, > >I took some editorial liberty with the text of TD-27. It is contained >below. I expect >to put this in 6.2.8.1 Capability Exchange. Alternatively, I could put >it into 8.2. >Any suggestions, changes, clarifications??? > >Thanks > Gary > >****************************************** > >"To allow gatekeepers to re-route connections from endpoints that do >not support >supplementary services, endpoints shall support the reception of empty >capability >sets (i.e. Terminal Capability sets that indicate that the endpoint >sending the >message has no receive capabilities). This feature also allows >'network' elements >such as PBXs, call centers, and IVR systems to re-route connections >independent >of supplementary services and facilitates pre-connect announcements. >It can also >be used to delay H.245 media establishment when features such as >Gatekeeper >based user location is being used. It is also highly recommended that >Version 1 >endpoints support this feature. > >On reception of an empty capability set an endpoint shall enter a >paused state. If >media stream or data logical channels were previously opened by the >endpoint, >they should be closed. In this state an endpoint shall accept the >opening of logical >channels from the remote end based on the usual rules and continue to >receive >media from open logical channels from the remote end. This allows >endpoints to >receive announcements (e.g. pre-connect call progress) where the >announcing >entity does not wish to receive media from the endpoint. > >On reception of a non-empty capability set in this paused state an >endpoint shall >reset its H.245 state to that which it was in prior to entering the >paused state. >This allows an endpoint to be connected to a different endpoint when it >is >released from the paused state. Note that the non-empty capability set >shall not >be sent to an endpoint until all its transmit and receive logical >channels have been >closed. A switching entity should also send an H.450 redirection >indication Facility >message if the endpoint is being re-routed. The endpoint shall then >proceed with >normal H.245 connection establishment signalling. When leaving the >paused state >an endpoint shall take part in master/slave determination signalling, >and may >proceed with normal open logical channel signalling procedures. When >an MC >receives a release from the paused state it shall act as if a new >endpoint has >entered the conference. > >Unless its capabilities have changed, an endpoint need not resend a >capability set >as the gatekeeper will have supplied this to remove any paused state in >the >remote endpoint. This option of not sending a capability set enables >faster >reconnection. > >------------------------------------- >Name: Gary Thom >Company: Delta Information Systems, Inc. >Phone: +1-215-657-5270 x23 >Fax : +1-215-657-5273 >E-mail: gthom(a)delta-info.com >Date: 09/19/97 >Time: 11:47:19 >------------------------------------- >

1 0

Re: reRouteIndication
by Scott Petrack 23 Sep '97

23 Sep '97

I think I understand, thanks for the clarification. (Of course maybe the next sentence will prove that I don't understand ;-)): I did not want to change anything about either the dummy/empty issue nor the *content* of the reRouteIndication issue. I was just saying that IF {there are possibilities for the h323-message-body that don't appear in the UUIEs-requested structure in TD-28a} then {these new types should be added to the UUIEs-requested structure mentioned in TD-28a} We agreed to allow a GK to monitor what an endpoint does in this way, and I just wanted it to be complete. Please let me know if this doesn't make sense (and I didn't understand). Scott pete.cordell(a)BT-SYS.BT.CO.UK on 09/22/97 12:56:49 PM Please respond to ITU-SG16(a)mailbag.jf.intel.com To: ITU-SG16(a)mailbag.jf.intel.com cc: (bcc: Scott Petrack) Subject: Re: reRouteIndication Joerg, Scott, To clarify, dummy is a Hertzliya addition and nothing to do with reRouteIndication. It's needed because if you send a supplementary service message in a FACILITY you may not want to invoke the Facility-UUIE. The optimum case would be to make the UUIE h323-body-message part OPTIONAL, but this is not possible at this stage. Hence adding the dummy field. As to the name.... dummy, empty, emptyChoice, noChoice, blankChoice, void,... would be OK with me (I'm sure we have bigger sins than this!). As for text to describe the field, maybe... empty - This option is used when a FACILITY message is sent, but the Facility-UUIE is not to be invoked. This may occur when transporting supplementary service messages. reRouteIndication is a different issue. As re-routing can take place independent of supp services, it seems reasonable that an endpoint should be able to get notification of this event independent of supp services. Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Joerg Ott[SMTP:jo@TZI.ORG] >Sent: 20 September 1997 08:54 >To: ITU-SG16(a)mailbag.jf.intel.com >Subject: Re: reRouteIndication > >Pete and all, > >two comments on this mail: >> >> It has been mentioned that when a gatekeeper performs a re-route it >> would be good for the client to know about it. After much >> investigation, there seems to be no message in Q.931 that handles this >> case. In the text that I proposed in Sunriver I suggested that a >> Facility message with a H.450 ctComplete should be sent. However, this >> is not much use to an entity that does not support supplementary >> services. Therefore it might be useful to add can extra case to the >> H323-UU-PDU to cover this, e.g.: >> >> H323-UU-PDU ::= SEQUENCE >> { >> h323-message-body CHOICE >> { >> setup Setup-UUIE, >> callProceeding CallProceeding-UUIE, >> connect Connect-UUIE, >> alerting Alerting-UUIE, >> userInformation UI-UUIE, >> releaseComplete ReleaseComplete-UUIE, >> facility Facility-UUIE, >> ..., >> progress Progress-UUIE, >> dummy NULL, > >First: > >I must have missed the "dummy" parameter before. I assume the need for >an empty parameter comes from supplementary services, and I suggest to >call >it "empty NULL" (this is not an implementation but a standard after >all) >and to describe it somewhere in H.225.0. Searching through the >document, >the ASN.1 was the only place where "dummy" was used. >(Should I be saying something about puzzles right now? :-) >> reRouteIndication ReRouteIndication >> }, >> nonStandardData NonStandardParameter OPTIONAL, >> ..., >> h4501SupplementaryService SEQUENCE OF H4501SupplementaryService >OPTIONAL >> } >> >> ReRouteIndication ::= SEQUENCE >> { >> display IA5String (SIZE( 0..255) ), >> endpointInfo EndpointType, >> ... >> } >> >> This could then be sent by a gatekeeper when a re-route has been done. >> > >Second: > >Overall, I agree with the mail from Ernst Horvath on this issue: we >should >not add such functionality to H.225.0, not even to version two. > >Joerg >

1 0

New Mailing List for H323-URLs
by Scott Petrack 23 Sep '97

23 Sep '97

As discussed at the recent rapporteurs meeting in SunRiver, we have opened a new mailing list (reflector) to be devoted to the subject H.323 URLs. It is called h323-url(a)vocaltec.com. To subscribe, you send mail to: h323-url-request(a)vocaltec.com and put subscribe in a line of the message. It makes no difference what the subject line is. 2. If you want to subscribe to a different address than the return address, you put subscribe userid(a)domain.name on a line of the body of the letter. It is a usual majordomo server. Sincerely, Scott Petrack

1 0