Subject: RE: Is the name of option "T33S" correct?

From: James Rafferty <[email-masked]>
Date: Fri, 19 May 2000 09:41:47 -0400

To all - 

ITU-T T.33 is basically a profile which describes the use of the T.30
subaddress 
in some particular applications, such as use of extensions that go beyond
phone numbers.    T.33 does refer to all of the characters that
are defined in the T.30 subaddress, and just explains how to use them 
in certain situations, particularly the numeric, # and SPACE characters.   

As for this discussion, the decision to use the terminology  /T33S
was made a long time ago after a great deal of mailing list discussion.  

In the context of RFC 2303 and 2304, only a single subaddress is supported
per mailing address and only the numeric characters would be used, since
it is being used to define a single extension.    

For translating this single extension for use in the T.30 SUB, there is no
need to use the optional # in the subaddress and if you  read T.33, you will
see that
the # WOULD NOT be placed in the T.30 SUB field for this case.    

There is absolutely no reason that I can see to re-open the discussion
and change the name of the fields, since this matter was discussed and 
decided a long time ago.     

Some additional clarification in response to Toyoda-san's questions follow:

> -----Original Message-----
> From: MAEDA toru [mailto:[email-masked]]
> Sent: Friday, May 19, 2000 5:59 AM
> To: Toyoda, Kiyoshi; Claudio Allocchio
> Cc: [email-masked]
> Subject: Re: Is the name of option "T33S" correct?
> 
> 
> Toyoda-san, Allocchio-san
> 
>  From the beginning of discussion, T33S means T.33, not SUB in T30.
> Also SUB in T.30 consists of  "*" , "#" , space and numeric digits as 
> defined in Table 3/T.30.
> 
> Regards,
> 
> Toru MAEDA
> 
> 
> At 17:39 00/05/19 +0900, Toyoda, Kiyoshi wrote:
> >Allocchio-san,
> >
> >I want to test the interworking of addressing RFC2304
> >for promoting it to Draft Standard.
> >But, the minutes of Adelade meeting below said that it is
> >difficult to test for many implemetors because the machine
> >must support T33. I think it is misunderstanding that the
> >machine must support T33 to test the interworking.
> >
Actually, if a machine supports either T.30 or T.33, the
interworking should be fine, for the reasons noted below (i.e.
the rules are really the same in T.30 and T.33 for the single extension case
supported in the RFC 2303/4).    

> >
> >At 08.40 +0900 00-04-27, Hiroshi Tamura wrote:
> > >- draft-ietf-fax-faxaddr-v2-00.txt, 
> draft-ietf-fax-minaddr-v2-00.txt
> > >
> > >Interworking is not enough, especially for /T33S issue.
> > >T33S conforms to ITU-T T.33(Facsimile routing utilizing 
> the subaddress).
> > >It is kind of an application profile. There are fax machines
> > >that support T.30 SUB signal. But there are very few 
> implementations
> > >about T.33. A question was raised about how to validate
> > >if two independent implementations interwork for addressing.
> > >About this question, there was an opinion it is that gateways can
> > >handle the specified address correctly.
> >
As noted, for this case, either T.30 or T.33 support should be OK 
to test interworking.   

The exact handling of the translation from a sub-addr element to 
a T.30 device with SUB support would seem to be a gateway matter, although
the rules for placement of the numeric characters are defined in T.30 
and more precisely described (regarding bit orders, etc.)  in T.33.   

> >
> >The option "/T33S=" does not support T33 because "#" character
> >does not be allowed in the sub-addr field as below nevertheless
> >T33 must support "#" character. And we can not write multiple
> >subaddresses in the sub-addr field nevertheless T33 must support
> >it with "#" character.  So, I think that "/T33S=" means sub-address
> >of T30.
> >
As I noted above, this is an incorrect interpretation of T.33.   For the
case of
a single extension (which is the only case supported in "sub-addr", if you
then
put this into a SUB field per the T.33 rules, you would simply place the 
numeric characters in the right-most octets of the T.30 sub field, with 
the remaining 20 characters being padded by spaces.  This is intentionally
consistent with the 
same set of rules that are defined in T.30 (that is, the SUB characters are
placed
in the right most octets, with padding on the left with Spaces.)  There is
no use of
the # character in this case.      

So, NO, T.33 does not require use of the # for this case.  Therefore, there
seems to be total consistency between T.33 and T.30 rules for the
translation of the single extension which is permitted in the "sub-addr"
element.   

> >I would like to propose to change the name of t33-sep and T33S
> >to t30-sep and T30S.
> >
> >
> > >      qualif-type1 = "/" t33-sep "=" sub-addr
> > >
> > >   where
> > >
> > >      t33-sep = "T33S"
> > >
> > >      sub-addr = 1*( DIGIT )
> >
Since the rules for T.30 and T.33 are exactly the same for this case, 
there is no value in making the change.   By the way, T.30 is a 
normative reference within T.33, so T.33 incorporates support
for the T.30 SUB by reference.    

> >
> > >4.1 Multiple subaddresses
> > >
> > >   In case a particular service requires multiple T.33 
> subaddresses, and
> > >   these subaddresses need to be given on the same 
> "fax-mbox", multiple
> > >   "fax-email" elements will be used.
> >
Yes, so as a result, there is only use of a single subaddress extension per
mail address in RFC 2303/4.   Therefore, the # character of T.33, which may
be used to separate multiple subaddresses in a T.30 subaddress (per T.33),
is never used for "sub-addr".   

Hopefully this explanation is helpful.   So, if there is an attempt to do
interworking
between RFC 2305 devices and T.30 devices which support SUB for sending and
receiving cases, this should meet the interworking requirements.    

> >Best regards,
> >
> >
> >
> >Kiyoshi Toyoda
> 
> *****************************
> Toru MAEDA
> CANON Inc. OIP Technology Adv. 3
> *****************************
> 
Best Regards,  

James

* -----------------------------------
James Rafferty
Senior Product Manager, IP Telephony
Brooktrout Technology
410 First Avenue
Needham, MA 02494 USA

Phone:  +1-781-433-9462
Fax: 781-433-9268
Email/Internet Fax:  [email-masked]
www.brooktrout.com
Your Hook into the New Network(SM)

---

From: Hiroshi Tamura <[email-masked]>
Date: Mon, 22 May 2000 10:42:54 +0900 (JST)

Rafferty-san,

Thank you for your explnation.

I understand what you are saying.

But, for implementers who read RFC2303/2304 and T.33(not T.30),
I think some clarifications may be necessary for RFC2303/2304.

According to /T33S in RFC2303/2304, we cannot use "#".
In T.33, "#" is an important element.
I think this causes misunderstandings.

Someone may think, "If we support /T33S, all features in T.33
must be supported."

I fould this is wrong from your explanation.
They will find it if they CAREFULLY read RFC2303/2304 and T.33.

On the conditions that /T33S remains as it is,
can we add some additional descriptions in these RFCs ?

For example,
"In this case, /T33S means T.30 SUB frame, although
digits are only used."

(I think Better sentences are necessary. This example
is very POOR.)

For being Draft Standard, we need interworking.
For interworking test, I think it is better to have clarifications
about it. T.30 SUB can be implemented more easily than
"T.33 Full implementation"

<snip>

> the # WOULD NOT be placed in the T.30 SUB field for this case.    

OK.

<snip>

> supported in the RFC 2303/4).    

So, considering this, I think we can add something.

<snip>

> translation of the single extension which is permitted in the "sub-addr"

This is very important information for interworking.

Any suggestions or comments are welcome.

Regards,
--
Hiroshi Tamura, Ricoh Company, LTD.
E-mail: [email-masked]

---

From: Dan Wing <[email-masked]>
Date: Sun, 21 May 2000 19:34:02 -0700 (PDT)

I agree the text in RFC2304 could be clearer regarding "#".

"#" appears to only be useful for multiple subaddresses (reference T.33,
7/96 edition, section 4.2).  Section 4.1 of RFC2304 describes how multiple
subaddresses should be handled.

I recommend the "Note" in section 2 of RFC2304, which currently reads:

   Note:
     See section 4.1 in case multiple sub-addr per fax-mbox need to be
     specified.

be changed to read:

   Note:
     In T.33, the "#" character is used to specify multiple subaddresses.
     However, only digits are permitted in the <sub-addr> field defined
     by this document.  Refer to section 4.1 in case multiple <sub-addr>
     per <fax-mbox> need to be specified.

-Dan Wing

---

From: "Toyoda, Kiyoshi" <[email-masked]>
Date: Mon, 22 May 2000 15:41:02 +0900

Rafferty-san,

Thank you for your explanation. Your explantion will be
helpful for implementors. I won't say about changing the name 
of /T33S anymore. 

But, I agree the recommendation which Wing-san said below.
It will clarify the meaning of /T33S. 
 
Best Regards,

Kiyoshi Toyoda