Subject: Re: Supplying only a port on a ServiceChangeAddress

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 13 Sep 2000 09:52:55 -0400

Flemming and I favor (a).

Given the state of things, what I would like to propose is:
1) The implementation guide state that use of ServiceChangeAddress is not
encouraged
2) State in the implementation guide that MGCs must be able to cope with
ServiceChangeAddress with either a full address or just a port number.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Wednesday, September 06, 2000 3:40 PM
> To: [email-masked]
> Subject: Re: Supplying only a port on a ServiceChangeAddress
>
>
> OK, we have three choices:
> (a) deprecate use of ServiceChangeAddress in favour of
> ServiceChangeMgcId
> (and assume it is never used by the MG)
> (b) allow specification of port only, with the parser able to
> distinguish
> from other forms because of the lack of punctuation (seems feasible)
> (c) require that the full address be specified.
>
> (b) is basically the current situation, with a note in the
> Implementor's
> Guide to warn that the contents may consist of a bare port number and
> specifying that in that case the IP address to be used is the
> same as the
> address to which the receiver of the ServiceChangeAddress is currently
> sending its requests.
>
> > -----Original Message-----
> > From: Rosen, Brian [mailto:[email-masked]]
> > Sent: Wednesday, September 06, 2000 2:16 PM
> > To: Taylor, Tom-PT [NORSE:B901:EXCH]; 'Flemming Andreasen';
> > Bharat Kaul
> > Cc: [email-masked]
> > Subject: RE: Supplying only a port on a ServiceChangeAddress
> >
> >
> > One more thing:
> > >The ABNF syntax of ServiceChangeAddress is VALUE, which permits
> > >designation of a port only within a quoted string.  The
> > >difference between this and the ASN.1 syntax is what started this
> > >whole thread, but is irrelevant because the functionality is
> > >still available.
> >
> > Value allows 1*(SafeChar), which would permit a port number (no
> > punctuation).  One system did exactly that at the Interop
> > event.  Either we
> > have to allow that, or explicitly disallow it.
> >
> > Brian
> >
>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 13 Sep 2000 10:20:17 -0400

Considering everything, that seems like a reasonable way forward. Personally,
I wouldn't mind seeing 1 being even stronger in its language.

-- Flemming

--
Flemming Andreasen
Cisco Systems