Please see my response sent to Paul.
No one has ruled out that there cannot be another BOF where the consensus
for the standardtrack RFC can be sought once the Informational RFC for the
SIP-H.323 Interworking is finalized (Please see SIP WG Co-Chair's and my
email sent after the SIP-H.323 Interworking BOF in the SIP mailing list. Why
did you not contradict those emails then?).
Chip Sharp further made it clear in his email the problems of using the IETF
drafts if the authors cannot participate in the ITU meetings no matter
whether there is IPR or not.
> -----Original Message-----
> From: Tom-PT Taylor [SMTP:taylor@NORTELNETWORKS.COM]
> Sent: Tuesday, May 30, 2000 9:29 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: H.323 Annex O
>
> Radhika, you make some dubious comments here. As you know, I laid out a
> management procedure for coordination between the two groups in the
> February meeting. SG 16 has not chosen to adopt it yet, but may do so in
> the future. In the meantime, I must remark that there was a really strong
> consensus in the IETF that they would not do standards-track work on
> interworking. You are being overly optimistic when you suggest otherwise.
>
> The other thing is that you should read the boilerplate on Internet
> Drafts. With rare exception, they are made freely available, in
> contradiction to what you suggest in the final paragraph of this note. If
> AT&T or another company proves to have IPR in a solution standardized by
> the ITU-T, they are free to enforce their patent on their chosen terms if
> another company chooses to practice it, but that has nothing to do with
> the standardization process.
>
> -----Original Message-----
> From: Roy, Radhika R, ALARC [SMTP:rrroy@ATT.COM]
> Sent: Tuesday, May 30, 2000 9:59 AM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: H.323 Annex O
>
> Hi, Roni:
>
> The important thing is that an Informational RFC for the SIP-H.323
> Interworking is under way (with a possibility to standard RFC) in the IETF
>
> and the contributions that invented the interworking solution are also
> there
> (in the IETF).
>
> So, I am afraid that two non-compatible standards will emerge. We
> should NOT
> encourage non-compatible standards for the same thing.
>
> There are also no mechanisms in the ITU-T SG16 to accept the
> contributions
> for the companies that can afford to communicate via emails only. I guess
> that the best way is to have the RFC from the IETF that will have all
> inputs
> from all companies that invented the interworking solution. The SG16 can
> then have the RFC for their use to make a formal standard (with more
> additions if needed).
>
> It is well understood that the mapping between SDP and H.245 can not
> be done
> so easily and that is why an interworking standard is so urgent. If the
> informational RFC of the IETF does not cover the H.263+ parameters, the
> SG16
> can then add those things. Or, any companies that like to address these
> parameters can also submit contributions as the IETF drafts (or send an
> email to the eGroup) proposing a solution.
>
> The SIP-H.323 interworking work is well under way in the IETF based
> on well
> written contributions as I described in my email.
>
> Why does the SG16 like to re-invent the wheel since this work is
> already
> progressing based on invented solutions submitted by the companies in the
> IETF?
>
> If you think that any improvements need to be done in the solutions
> proposed
> in the contributions of the IETF (please see the references provided in my
>
> email), please submit the proposal in the IETF. We can then use the
> Informational RFC as an input for a formal standard in the SG16. In this
> way, we can get the best the both worlds having a "single common standard
> for SIP-H.323 Interworking".
>
> The key is that the SG16 cannot use the interworking solution that
> has been
> "invented" by the other companies or institutions without their consent
> and
> participation. I personally feel very strongly that the SG16 cannot not
> "invent" a NEW interworking solution of its own that will NOT include the
> solutions proposed by others in the IETF.
>
> I hope that this will clarify the situation.
>
> Best regards,
>
> Radhika R. Roy
>
> > -----Original Message-----
> > From: Roni Even [SMTP:Roni_e@ACCORD.CO.IL]
> > Sent: Sunday, May 28, 2000 6:44 AM
> > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > Subject: Re: H.323 Annex O
> >
> > Roy,
> > The summary from Q14 states that SIP-H.323 interworking will be an
> > appendix
> > that will map messages for simple audio calls. and would defines
> preferred
> > interworking mode. See the text bellow from TD-21b
> > Roni Even
> >
> > 6.1.1 APC-1776 - Terms of Reference for H.323 - Internet Interworking
> > [H.323-Internet Interworking Group] [joint with Q.12, Q.13]
> > Q.15 discussed some SIP matters - SDP does not currently provide enough
> > detail to describe H.263+ parameters.
> >
> > Call signaling could be captured in an appendix to H.246. This appendix
> > would first address simple audio interworking, covering topics such as
> > mapping messages between H.323 and SIP. This is work that is currently
> in
> > progress in the IETF (not an official work item at this time, but an
> > unofficial task in the SIP working group). This appendix would define
> the
> > "preferred interworking mode" of H.323; we'd expect the SIP experts to
> > define the preferred interworking mode of SIP. We need to capture the
> > essence of each of the functional entities. Contributions are requested.
>
> >
> > There was agreement that a new annex to H.323 to address how H.323 could
>
> > utilize a variety of internet services. Section 3 of APC-1776 is a good
> > basis for this work.
> >
> >
> > > -----Original Message-----
> > > From: Roy, Radhika R, ALARC [SMTP:rrroy@ATT.COM]
> > > Sent: Fri, May 26, 2000 9:30 PM
> > > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > > Subject: H.323 Annex O
> > >
> > > Mr. M. F. TOSCO
> > > Chairman
> > > ITU-T SG16 WP2
> > >
> > > Dear Mr. TOSCO:
> > >
> > > We are very much pleased to see that an H.323 Annex O (Internet
> > Protocols
> > > and Technologies Complementary to H.323) has been opened in the joint
> > > meeting of Q.13/16 and Q.13/16 held in Osaka, Japan on May 15-19,
> 2000.
> > It
> > > is expected that this annex will cover the following topics:
> > >
> > > 1. H.323-SIP Interworking
> > > 2. Inteworking between H.323 and other IETF Protocols (e.g.,
> TRIP,
> > > etc.)
> > >
> > > With respect to item 1 (H.323-SIP Interworking), it has been noted in
> > the
> > > meeting report that the IETF is also working to develop an
> Informational
> > > RFC
> > > (a standard track RFC is also a possibility) for the SIP-H.323
> > > interworking.
> > > The way this work in the IETF is progressing is as follows (I believe
> > that
> > > the editor of H.323 Annex O is also fully aware of this work of the
> > IETF):
> > >
> > > 1. SIP-H.323 Interworking Requirements RFC (Informational): by
> > > July-December, 2000 (tentative)
> > > 2. SIP-H.323 Interworking RFC (Informational): December 2000 -
> > March
> > > 2001 (tentative)
> > >
> > > The Internet-Drafts and documents that are being provided to develop
> the
> > > RFC
> > > are as follows:
> > >
> > > 1. Agrawal, Roy, and Palawat, "SIP-H.323 Interworking
> > Requirements,"
> > > draft-agrawal-roy-palawat-sip-h323-interworking-00.txt, IETF, June
> 2000.
> > > 2. Singh and Schulzrinne, "Interworking Between SIP/SDP and
> H.323",
> > > draft- singh-sip-h323-00.txt, IETF, January 2000.
> > > 3. C. Agbah, "SIP and H.323 Signaling Gateway."
> > >
> > > It is expected that the SIP-H.323 Interworking RFC will be based
> > primarily
> > > on the above documents along with suggestions made via emails and
> > > conference
> > > calls.
> > >
> > > People could take many those contributions to the ITU-T SG16 for the
> > > SIP-H.323 Interworking in the last SG16 February'00 meeting. However,
> it
> > > was
> > > found that many companies and institutions that invented the
> > interworking
> > > solution could not afford to provide the membership fees of the ITU-T,
>
> > and
> > > some of them even could not afford to make a foreign trip for the
> > standard
> > > meeting. But this has not been the case for the IETF where the email
> has
> > > been good enough to work for developing the standard.
> > >
> > > Therefore, I am proposing the following to harmonize the work of these
>
> > two
> > > organizations so that the complementary standards are created in the
> > ITU-T
> > > SG16 and IETF:
> > >
> > > 1. Let the IETF produce the SIP-H.323 interworking RFC, while we,
>
> > the
> > > ITU-T SG16, will develop the H.323-TRIP and/or other IETF protocols
> > > Interworking standard.
> > > 2. Should the IETF do not develop the standard track SIP-H.323
> RFC,
> > > we,
> > > the ITU-T SG16, might consider how IETF's SIP-H.323 Interworking
> > > (Informational) RFC can be made a formal standard.
> > >
> > > I hope this suggestion will be acceptable to all of us.
> > >
> > > Best regards,
> > >
> > > Radhika R. Roy
> > > AT&T Delegation Manager in the ITU-T SG16 (WP1, WP2, & WP3)
> > > 200 Laurel Avenue, Middletown, NJ 07748, USA
> > > +1 732 420 1580 Tel
> > > +1 732 368 1195 Fax
> > > rrroy(a)att.com
> > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > listserv(a)mailbag.intel.com
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv(a)mailbag.intel.com
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
