> Francois,
>
> The UUIE _is_ a Q.931 IE, 5.8.6.2/Q.931 does not exclude this IE, and
> neither H.225.0 or H.323 address the issue of how to handle a
> UUIE--or any
> other IE, for that matter--with invalid content, therefore
> the behavior
> defined in Q.931 is normative for H.323.
An "invalid coding" for an information element does NOT include the content
of a User-User information element. By definition, a Q.931 User-user IE can
include whatever you feel like. A …
[View More]proper implementation will not reject a
call because of the content of the User-user IE.
> _All_ of Q.931 is an "ISDN thing," so what's your point?
>
> Finally, there is much in Q.931 that H.323 does not
> reference, but that does
> not invalidate the parts of Q.931 that H.323 references.
H.323 does not use Q.931. H.225.0 recycled some of the messages (but not
all of them). More importantly, it doesn't explicitly use the
PROCEDURES of Q.931. There are some stringent timer requirements for
example in Q.931 that not used use by H.323. The DISCONNECT and
RELEASE messages are not even used. We are not even setting up
a bearer channel in H.323 when doing a call setup.
In summary, H.225.0 is NOT Q.931.
[View Less]
Hi, Christian:
I am glad that you have described what exactly I wanted to say. I completely
agree with you.
All emails were sent to get the point across that you have just described.
Hope that every member will also agree with your clarification.
Best regards,
Radhika R. Roy
> -----Original Message-----
> From: Christian Groves [SMTP:Christian.Groves@ERICSSON.COM]
> Sent: Wednesday, May 31, 2000 8:21 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: H.323 Annex O
&…
[View More]gt;
> Hello Roy,
>
> I abit confused at all these emails flying around about the H.246
> SIP-H.323 Appendix. There are alot of could's and would's in the Sg16
> meeting report and I believe the underlying sentiment was that we would
> let the IETF continue with their work and monitor it. At a later stage
> we could reference this work in an informational Appendix.
>
> I agree on your desire to have one document describing the Interworking.
> I hope that interested parties contribute to the work done in the IETF
> rather than starting competing work in SG16 at this stage.
>
> Regards, Christian
>
> "Roy, Radhika R, ALARC" wrote:
> >
> > Hi, Glen:
> >
> > It is nice to know that an H.246 SIP-H.323 Interworking APPENDIX will be
> > created.
> >
> > Per earlier emails, it appears that this APPENDIX will be informational
> one.
> >
> > With respect to presenting the contributions, I tried to bring
> contributions
> > including authors of the Internet Drafts for the SIP-H.323 Interworking
> in
> > the last SG16 meeting held in Geneva on February 2000. However, the US
> Dept
> > of State did not accept the contributions of the organizations (e.g.,
> > Universities) and companies who were not the members of the ITU-T SG16
> > (either independently or jointly with other companies who are the
> members of
> > the ITU-T).
> >
> > However, in IETF, it has not been the case. That is why, the authors of
> > those internet drafts are working to create an Informational RFC.
> >
> > Now it appears that the SG16 will also be creating an informational
> > APPENDIX.
> >
> > It appears that the IETF's Informational RFC will be produced first.
> >
> > Let us keep our eyes open how we can create a unified informational
> standard
> > cooperating in both standard organizations. Some suggestions have been
> made
> > in the earlier emails.
> >
> > Our objectives should be to create one single standard for the same
> thing.
> >
> > Best regards,
> > Radhika R. Roy
> >
> > > -----Original Message-----
> > > From: Glen Freundlich [SMTP:ggf@LUCENT.COM]
> > > Sent: Wednesday, May 31, 2000 12:34 PM
> > > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > > Subject: Re: H.323 Annex O
> > >
> > > While it is true that work is progressed through written contributions
> to
> > > study
> > > group and rapporteurs' meetings, those written contributions can be
> > > created
> > > jointly via email, conference calls, over a plate of bull fries at
> Bruce's
> > > Bar,
> > > etc. Note that joint creation of a contribution does not guarantee its
> > > approval
> > > (although probability of approval certainly increases when a larger
> group
> > > of
> > > people are involved in the creation of a proposal).
> > >
> > > In the case of a jointly created contribution, it seems reasonable
> that
> > > someone
> > > from that group would be able to present the contribution at a
> meeting. If
> > > someone has a contribution they would like to present at a meeting,
> but is
> > > unable
> > > to attend, it's certainly possible to ask someone who plans to attend
> the
> > > meeting
> > > to present the material.
> > >
> > > As for the SIP-H.323 interworking annex, check the meeting report:
> > >
> > > "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."
> > >
> > > SIP-H.323 interworking would be described in an appendix to H.246 (not
> > > H.323
> > > Annex O). This would describe the "preferred interworking mode", which
> > > would
> > > specify, for example, the use of H.323 fast start. It might describe
> the
> > > relationship between the functional entities (e.g., is the SIP-H.323
> > > interworking
> > > function in a gateway or gatekeeper for the H.323 side, and in a SIP
> proxy
> > > for
> > > the SIP side?). It would describe message mapping (e.g., the H.323
> Setup
> > > message
> > > maps to a SIP Invite message, and the called party number IE is mapped
> to
> > > the To
> > > header).
> > >
> > > Glen
> > >
> > >
> > > Chip Sharp wrote:
> > >
> > > > At 09:59 AM 5/30/00 -0400, Roy, Radhika R, ALARC wrote:
> > > > ...snip...
> > > > >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 true that SG16 still operates mainly on the basis of written
> > > > contributions to meetings and not on mail lists like IETF WG. It is
> > > also
> > > > true that non-ITU members have a hard time participating in ITU SG
> > > > work. Even if a company is an ITU member, attending all the
> meetings
> > > > around the world is a travel burden on small companies (even big
> > > > companies). However, an IETF WG can submit a written contribution to
> > > SG16
> > > > via existing mechanisms. Usually, this is initiated via consensus of
> the
> > > WG
> > > > and/or by WG chair via the ISOC VP - Standards. Of course, it
> requires
> > > > someone to represent that contribution at the SG16 meetings. The
> SG16
> > > > Rapporteurs have been very open in the past to inviting non-ITU
> member
> > > > experts to Rapporteur Meetings to further the work. The SG16 mail
> list
> > > has
> > > > been one of the more active SG mail lists in actually discussing
> > > technical
> > > > issues. And SG16's working documents are available for review as
> well
> > > (at
> > > > least from Rapporteur's Meetings). It will be nice if ITU could
> codify
> > > > some of these examples at WTSA.
> > > >
> > > > I understand the desire to do the work in one place. It is also
> true
> > > that
> > > > SG16 can reference an IETF RFC in its recommendations. However, if
> it
> > > is
> > > > an informational RFC, it can't be a normative reference in ITU.
> > > > ...snip...
> > > > >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".
> > > >
> > > > Remember an ITU Recommendation cannot make a normative reference to
> an
> > > > Informational RFC.
> > > > If there is no new protocol work being done, the H.323-SIP
> interworking
> > > > could conceivably become a BCP (Best Current Practice) some day.
> > > >
> > > > >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.
> > > >
> > > > The ITU can incorporate by (normative or non-normative) reference to
> any
> > > > RFC. The IETF has an IPR policy that isn't too different from ITU
> (I
> > > don't
> > > > think). Current A.5 procedures require that IETF provide a written
> > > > agreement to allow normative references to an RFC (I don't remember
> ever
> > > > seeing one of these, but there may be a blanket agreement). There
> are
> > > > proposals to drop this requirement in the next version of A.5.
> > > >
> > > > Any IPR contained in IETF RFCs are covered by IETF IPR policy. It
> is
> > > true
> > > > that a company that has declared IPR in an IETF RFC may not know it
> is
> > > > being referenced in ITU and therefore may not submit an IPR
> statement to
> > > > ITU. Therefore the IPR would only be covered by the IETF IPR
> statement
> > > > (this brings up interesting legal questions, but I'll leave that up
> to
> > > the
> > > > lawyers.). This should only be a real problem if the invention were
> > > > included in the ITU Recommendation by some means other than
> reference.
> > > >
> > > > So the bottom line is that there are mechanisms to share work in ITU
> and
> > > > IETF even without all the formal mechanisms worked out between
> Megaco
> > > and
> > > > Q.14. However, if the work is going to be cooperative, such an
> > > agreement
> > > > is probably desirable.
> > > >
> > > > Good Luck!
> > > > Chip
> > > >
> > > > -------------------------------------------------------------------
> > > > Chip Sharp CTO Consulting Engineering
> > > > Cisco Systems
> > > > Reality - Love it or Leave it.
> > > > http://www.netaid.org
> > > > -------------------------------------------------------------------
> > > >
> > > >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > > listserv(a)mailbag.intel.com
> > >
> > > --
> > > Glen Freundlich ggf(a)lucent.com
> > > Lucent Technologies office: +1 303 538 2899
> > > 11900 N. Pecos fax: +1 303 538 3907
> > > Westminster, Colorado 80234 USA
> > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > 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
[View Less]
> 5.8.6.2/Q.931: When a SETUP or RELEASE message is received
> which has one or
> more mandatory information elements with invalid content, a
> RELEASE COMPLETE
> message with cause No. 100, “invalid information element
> contents” shall be
> returned."
My understanding of this statement is that it is meant to cover
Q.931 elemements themselves, NOT UUIE content. As far as Q.931 is
concerned, the User-user information element can be coded in
whatever way we want. It is …
[View More]an ISDN thing that was carried over
in H.225.0.
So, my take is that this section is completely irrelevant to the
H.245 tunnelling (or in fact H.245 in general). Also, it talks about
a message (RELEASE) that is not even supported in H.225.0.
[View Less]
Yep. You are correct.
> -----Original Message-----
> From: Paul Long [mailto:Plong@SMITHMICRO.COM]
> Sent: Tuesday, May 30, 2000 8:01 AM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
>
>
> (Whoops, I misunderstood. You were talking about actually
> tunneling an H.245
> message in Setup. I was thinking you were just indicating
> tunneling, which
> is of course okay.)
>
> -----Original Message-----
&…
[View More]gt; From: Paul Long [mailto:plong@smithmicro.com]
> Sent: Tuesday, May 30, 2000 9:56 AM
> To: 'Mailing list for parties associated with ITU-T Study Group 16'
> Subject: RE: On TD26 - Fast TCS and M/S negotiation in H.323v4
>
>
> Francois,
>
> Tunneling and Fast Connect are orthogonal to each other. I
> can't find where
> v2 or v3 says that they cannot be done in parallel. As a
> matter of fact,
> this is how we implemented it. We are now very aggressive
> with call setup.
> What specific problems are there with doing them at the same time? We
> haven't found any.
>
> Paul
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
[View Less]
Hi, Glen:
It is nice to know that an H.246 SIP-H.323 Interworking APPENDIX will be
created.
Per earlier emails, it appears that this APPENDIX will be informational one.
With respect to presenting the contributions, I tried to bring contributions
including authors of the Internet Drafts for the SIP-H.323 Interworking in
the last SG16 meeting held in Geneva on February 2000. However, the US Dept
of State did not accept the contributions of the organizations (e.g.,
Universities) and companies …
[View More]who were not the members of the ITU-T SG16
(either independently or jointly with other companies who are the members of
the ITU-T).
However, in IETF, it has not been the case. That is why, the authors of
those internet drafts are working to create an Informational RFC.
Now it appears that the SG16 will also be creating an informational
APPENDIX.
It appears that the IETF's Informational RFC will be produced first.
Let us keep our eyes open how we can create a unified informational standard
cooperating in both standard organizations. Some suggestions have been made
in the earlier emails.
Our objectives should be to create one single standard for the same thing.
Best regards,
Radhika R. Roy
> -----Original Message-----
> From: Glen Freundlich [SMTP:ggf@LUCENT.COM]
> Sent: Wednesday, May 31, 2000 12:34 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: H.323 Annex O
>
> While it is true that work is progressed through written contributions to
> study
> group and rapporteurs' meetings, those written contributions can be
> created
> jointly via email, conference calls, over a plate of bull fries at Bruce's
> Bar,
> etc. Note that joint creation of a contribution does not guarantee its
> approval
> (although probability of approval certainly increases when a larger group
> of
> people are involved in the creation of a proposal).
>
> In the case of a jointly created contribution, it seems reasonable that
> someone
> from that group would be able to present the contribution at a meeting. If
> someone has a contribution they would like to present at a meeting, but is
> unable
> to attend, it's certainly possible to ask someone who plans to attend the
> meeting
> to present the material.
>
> As for the SIP-H.323 interworking annex, check the meeting report:
>
> "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."
>
> SIP-H.323 interworking would be described in an appendix to H.246 (not
> H.323
> Annex O). This would describe the "preferred interworking mode", which
> would
> specify, for example, the use of H.323 fast start. It might describe the
> relationship between the functional entities (e.g., is the SIP-H.323
> interworking
> function in a gateway or gatekeeper for the H.323 side, and in a SIP proxy
> for
> the SIP side?). It would describe message mapping (e.g., the H.323 Setup
> message
> maps to a SIP Invite message, and the called party number IE is mapped to
> the To
> header).
>
> Glen
>
>
> Chip Sharp wrote:
>
> > At 09:59 AM 5/30/00 -0400, Roy, Radhika R, ALARC wrote:
> > ...snip...
> > >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 true that SG16 still operates mainly on the basis of written
> > contributions to meetings and not on mail lists like IETF WG. It is
> also
> > true that non-ITU members have a hard time participating in ITU SG
> > work. Even if a company is an ITU member, attending all the meetings
> > around the world is a travel burden on small companies (even big
> > companies). However, an IETF WG can submit a written contribution to
> SG16
> > via existing mechanisms. Usually, this is initiated via consensus of the
> WG
> > and/or by WG chair via the ISOC VP - Standards. Of course, it requires
> > someone to represent that contribution at the SG16 meetings. The SG16
> > Rapporteurs have been very open in the past to inviting non-ITU member
> > experts to Rapporteur Meetings to further the work. The SG16 mail list
> has
> > been one of the more active SG mail lists in actually discussing
> technical
> > issues. And SG16's working documents are available for review as well
> (at
> > least from Rapporteur's Meetings). It will be nice if ITU could codify
> > some of these examples at WTSA.
> >
> > I understand the desire to do the work in one place. It is also true
> that
> > SG16 can reference an IETF RFC in its recommendations. However, if it
> is
> > an informational RFC, it can't be a normative reference in ITU.
> > ...snip...
> > >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".
> >
> > Remember an ITU Recommendation cannot make a normative reference to an
> > Informational RFC.
> > If there is no new protocol work being done, the H.323-SIP interworking
> > could conceivably become a BCP (Best Current Practice) some day.
> >
> > >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.
> >
> > The ITU can incorporate by (normative or non-normative) reference to any
> > RFC. The IETF has an IPR policy that isn't too different from ITU (I
> don't
> > think). Current A.5 procedures require that IETF provide a written
> > agreement to allow normative references to an RFC (I don't remember ever
> > seeing one of these, but there may be a blanket agreement). There are
> > proposals to drop this requirement in the next version of A.5.
> >
> > Any IPR contained in IETF RFCs are covered by IETF IPR policy. It is
> true
> > that a company that has declared IPR in an IETF RFC may not know it is
> > being referenced in ITU and therefore may not submit an IPR statement to
> > ITU. Therefore the IPR would only be covered by the IETF IPR statement
> > (this brings up interesting legal questions, but I'll leave that up to
> the
> > lawyers.). This should only be a real problem if the invention were
> > included in the ITU Recommendation by some means other than reference.
> >
> > So the bottom line is that there are mechanisms to share work in ITU and
> > IETF even without all the formal mechanisms worked out between Megaco
> and
> > Q.14. However, if the work is going to be cooperative, such an
> agreement
> > is probably desirable.
> >
> > Good Luck!
> > Chip
> >
> > -------------------------------------------------------------------
> > Chip Sharp CTO Consulting Engineering
> > Cisco Systems
> > Reality - Love it or Leave it.
> > http://www.netaid.org
> > -------------------------------------------------------------------
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv(a)mailbag.intel.com
>
> --
> Glen Freundlich ggf(a)lucent.com
> Lucent Technologies office: +1 303 538 2899
> 11900 N. Pecos fax: +1 303 538 3907
> Westminster, Colorado 80234 USA
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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
[View Less]
Good!
Federico
> ----------
> Da: Glen Freundlich[SMTP:ggf@LUCENT.COM]
> Risposta a: Mailing list for parties associated with ITU-T Study Group
> 16
> Inviato: mercoledì 31 maggio 2000 19.29
> A: ITU-SG16(a)MAILBAG.INTEL.COM
> Oggetto: H.248 change document
>
> Greetings,
>
> I have placed 3 files in the Incoming directory of the pictel ftp site:
>
> H248-for-decision-changes-wsynt.zip - The change document showing the
> specific …
[View More]modifications to the determined H.248 as finalized at the Osaka
> meeting.
>
> H248-for-decision-wcm.zip - The entire H.248 document with changes to
> the determined document highlighted.
>
> H248-for-decision-wcm.zip - H.248 with all changes accepted (the clean
> document).
>
> Regards,
> Glen
>
>
> --
> Glen Freundlich ggf(a)lucent.com
> Lucent Technologies office: +1 303 538 2899
> 11900 N. Pecos fax: +1 303 538 3907
> Westminster, Colorado 80234 USA
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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
[View Less]
Gee, I'm usually the lawyer. I stand corrected on this point.
> -----Original Message-----
> From: Scott Bradner [SMTP:sob@HARVARD.EDU]
> Sent: Wednesday, May 31, 2000 10:56 AM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: H.323 Annex O
>
> > 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.
>
> lets be …
[View More]careful here -
>
> current Copyright law says there is always Copyright IPR in any document
> even
> if the document has no copyright statement on it.
>
> the IETF requires that authors of IETF documents give the IETF (actually
> ISOC
> for legal reasons) the right to publish the douments, allow others to
> publish the documents as-is, and, in most cases, the right to make
> derivative
> works within the IETF standards process - the author retains all other
> rights
>
> the IETF can not grant the right for any other organization to make
> derivative rigts because we do not get that right from the authors
>
> but the authors can give their own OK if they want
>
> that said, I do not think its a real good idea to have two
> organizations working off the same base documents to come up
> with different results - it just confuses the community - so
> I would rather that one organization take the token to lead but
> that people from both organizations work together if possible
>
> Scott
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
[View Less]
At 09:59 AM 5/30/00 -0400, Roy, Radhika R, ALARC wrote:
...snip...
>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 true that …
[View More]SG16 still operates mainly on the basis of written
contributions to meetings and not on mail lists like IETF WG. It is also
true that non-ITU members have a hard time participating in ITU SG
work. Even if a company is an ITU member, attending all the meetings
around the world is a travel burden on small companies (even big
companies). However, an IETF WG can submit a written contribution to SG16
via existing mechanisms. Usually, this is initiated via consensus of the WG
and/or by WG chair via the ISOC VP - Standards. Of course, it requires
someone to represent that contribution at the SG16 meetings. The SG16
Rapporteurs have been very open in the past to inviting non-ITU member
experts to Rapporteur Meetings to further the work. The SG16 mail list has
been one of the more active SG mail lists in actually discussing technical
issues. And SG16's working documents are available for review as well (at
least from Rapporteur's Meetings). It will be nice if ITU could codify
some of these examples at WTSA.
I understand the desire to do the work in one place. It is also true that
SG16 can reference an IETF RFC in its recommendations. However, if it is
an informational RFC, it can't be a normative reference in ITU.
...snip...
>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".
Remember an ITU Recommendation cannot make a normative reference to an
Informational RFC.
If there is no new protocol work being done, the H.323-SIP interworking
could conceivably become a BCP (Best Current Practice) some day.
>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.
The ITU can incorporate by (normative or non-normative) reference to any
RFC. The IETF has an IPR policy that isn't too different from ITU (I don't
think). Current A.5 procedures require that IETF provide a written
agreement to allow normative references to an RFC (I don't remember ever
seeing one of these, but there may be a blanket agreement). There are
proposals to drop this requirement in the next version of A.5.
Any IPR contained in IETF RFCs are covered by IETF IPR policy. It is true
that a company that has declared IPR in an IETF RFC may not know it is
being referenced in ITU and therefore may not submit an IPR statement to
ITU. Therefore the IPR would only be covered by the IETF IPR statement
(this brings up interesting legal questions, but I'll leave that up to the
lawyers.). This should only be a real problem if the invention were
included in the ITU Recommendation by some means other than reference.
So the bottom line is that there are mechanisms to share work in ITU and
IETF even without all the formal mechanisms worked out between Megaco and
Q.14. However, if the work is going to be cooperative, such an agreement
is probably desirable.
Good Luck!
Chip
-------------------------------------------------------------------
Chip Sharp CTO Consulting Engineering
Cisco Systems
Reality - Love it or Leave it.
http://www.netaid.org
-------------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
Hi, Orit and All:
It is a very good proposal that H.246 SIP-H.323 Interworking APPENDIX will
be an informational.
In this case, I guess that we can also refer any IETF's Informational RFCs
(including SIP-H.323 Interworking), if needed, in this APPENDIX because it
does not need to have the "normative" references.
Best regards,
Radhika R. Roy
> -----Original Message-----
> From: Orit Levin [SMTP:orit@radvision.com]
> Sent: Wednesday, May 31, 2000 10:29 AM
> To: ITU-SG16(a)…
[View More]MAILBAG.INTEL.COM
> Subject: H.323-SIP Appendix of H.246 (Previously Annex O)
>
> Good morning! A small clarification.
> SG16 proposed to organized H.323-SIP work as an APPENDIX (i.e.
> "informative"document) of H.246. H.246 is an umbrella for many signaling
> gateways (such as H.320, ISUP, Mobile Networks, etc.). This Appendix will
> happen only if contributions on H.323-SIP will be brought to SG16. It was
> also noticed, that it is preferable to have architectural proposals,
> defining preferred mode of operation, capabilities, versions, etc., rather
> then containing detailed messages flows. Just a reminder, in ITU
> everything is driven by contributions only.
>
> Best Regards,
> Orit Levin
> RADVision Inc.
> 575 Corporate Drive Suite 420
> Mahwah, NJ 07430
> Tel: 1 201 529 4300 (230)
> Fax: 1 201 529 3516
> www.radvision.com <http://www.radvision.com>
> orit(a)radvision.com <mailto:orit@radvision.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
> 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.
lets be careful here -
current Copyright law says there is always Copyright IPR in any document even
if the document has no copyright statement on it.
the IETF requires that authors of IETF documents give the IETF (actually ISOC
for legal reasons) the right to publish the douments, allow others to
…
[View More]publish the documents as-is, and, in most cases, the right to make derivative
works within the IETF standards process - the author retains all other
rights
the IETF can not grant the right for any other organization to make
derivative rigts because we do not get that right from the authors
but the authors can give their own OK if they want
that said, I do not think its a real good idea to have two
organizations working off the same base documents to come up
with different results - it just confuses the community - so
I would rather that one organization take the token to lead but
that people from both organizations work together if possible
Scott
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
