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@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@mailbag.intel.com-- Glen Freundlich ggf@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@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
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@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@mailbag.intel.com-- Glen Freundlich ggf@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@mailbag.intel.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (2)
-
Christian Groves -
Roy, Radhika R, ALARC