Subject: RE: [Sigtran] SUA: Filler in Global Title Address

From: "Ong, Lyndon" <[email-masked]>
Date: Mon, 26 Aug 2002 16:48:35 -0700

Ditto request on my part - sorry I'm a bit late on this
discussion.  If there is in fact an incompatibility that
people have found in their implementation and the text
in the spec can be improved, we should use the 
implementation guide method for clarifications.

Cheers,

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, August 20, 2002 9:16 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Sigtran] SUA: Filler in Global Title Address

Hi Vince,

Could you provide some sample text that you think would help?

Thanks,
John

> -----Original Message-----
> From: ext Vince Deters [mailto:[email-masked]]
> Sent: 19 August, 2002 19:55
> To: [email-masked]
> Cc: [email-masked]; Loughney John (NRC/Helsinki);
> [email-masked]; Asif Patel
> Subject: Re: [Sigtran] SUA: Filler in Global Title Address
> 
> 
> Ok, I'm going to graciously cease my participation in this 
> futile discussion. You simply don't want to help when
> help is needed. Thanks.
> Vince
> 
> "Brian F. G. Bidulock" wrote:
> 
> > Vince,
> >
> > Vince Deters wrote:                                         
>                        (Mon, 19 Aug 2002 12:00:44)
> > >
> > > That would not be sufficient? That is the complete address signal
> > > description from Q.713 section 3.4.2.3.1, which is the 
> reference in the
> > > draft that you quoted above. You've just confirmed that 
> the draft is
> > > deficient.
> > >
> >
> > The entire Q.713 document is normative, so it is not deficient.
> >
> > --brian
> >
> > --
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> 
> 

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Vince Deters <[email-masked]>
Date: Mon, 26 Aug 2002 20:00:58 -0400

Hi Lyndon,

I posted some text last Tuesday, but it's now obvious that the list server
must have been down or something. So here it is again -

Section 3.10.2.3 currently says:

   "Global Title:

    Octets contain a number of address signals and possibly filler as
    shown:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |2 addr.|1 addr.|4 addr.|3 addr.|6 addr.|5 addr.|8 addr.|7 addr.|
     |  sig. | sig.  |  sig. | sig.  |  sig. | sig.  |  sig. | sig.  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        .............          |filler |N addr.|   filler      |
     |                               |if req | sig.  |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   All filler bits SHOULD be set to 0.

   Address signals to be coded as defined in ITU-T Q.713 Section
   3.4.2.3.1."

Here's what we propose:

   "Global Title:

    Octets contain a number of address signals and possibly filler as
    shown:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |2 addr.|1 addr.|4 addr.|3 addr.|6 addr.|5 addr.|8 addr.|7 addr.|
     |  sig. | sig.  |  sig. | sig.  |  sig. | sig.  |  sig. | sig.  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    .......    |filler |N addr.|   filler      |
     |               |if req | sig.  |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   All filler bits SHOULD be set to 0 and MUST be included in the
   sub-parameter length. An arbitrary number of filler octets MAY be
   present after the last address signal."

The diagram change indicates that filler does not necessarily extend the
sub-parameter to a 4 byte boundary. This addresses the
confusion that caused our interoperability problem. The additional text
serves the same purpose.

The reference to ITU-T Q.713 Section 3.4.2.3.1 is removed for two reasons:

1) As Brian stated previously, the address signal description in Section
3.4.2.3.1 is not sufficient, and I agree. The normative
references cover this.

2) Section 3.4.2.3.1 defines filler as one nibble inserted after the last
address signal in the case of an odd number of digits, and thus
conflicts with the description above. This had me confused for a long time.
Again, removing this specific reference leaves the
definition to the existing normative references.

Thanks,
Vince