- sg16-avd - lists.packetizer.com

RE: Update r1; Re: H.248.1 V3 Editorial Comments: Week 5
by Kevin Boyle 15 Jun '05

15 Jun '05

This is week 4. Let's not get ahead of ourselves, especially since I am still catching up from the Great Capitalization Change that took me literally days of effort to work through. All should note: my email address changed some time ago to kboyle(a)nortel.com. Use of the nortelnetworks.com address will start being rejected in the next day or so. Kevin -----Original Message----- From: Christian Groves [mailto:christian.groves@ERICSSON.COM] Sent: Wednesday, June 15, 2005 2:55 AM To: Albrecht.Schwarz(a)alcatel.de Cc: itu-sg16(a)external.cisco.com; kboyle(a)nortelnetworks.com Subject: Re: Update r1; Re: H.248.1 V3 Editorial Comments: Week 5 Hello Albrecht, all, I agree with Albrechts suggestions. With regards to the Generic Package I think its is a typo that change be changed as extension rules say this must be a versioning of the package. With regards to your comments ABS7 "Wording of sentence? Makes this sense?" I think the sentence should read "Allowed terminations type combinations in a context". With regards to your comments ABS8 " Note: an ALCATEL contribution to next SG16 is planned proposing "§ 5.8.7 Notify" inclusion". I'm happy to accept this as Notify is a command and should be listed. Regards, Christian PS: Kevin: Did I miss week 4 ABNF sections? I'll send some comments on week 4 in the next couple of days. Albrecht.Schwarz(a)alcatel.de wrote: > I found two further typos in Appendix II. > -> Revision "...r1" file in Incoming directory again. > > Regards > Albrecht > > > > > > Albrecht > > SCHWARZ/DE/ALCAT To: SG16 > <itu-sg16(a)external.cisco.com> > EL@ALCATEL cc: > jan.lindquist(a)ERICSSON.COM > Subject: H.248.1 V3 > Editorial Comments: Week 5 > 13.06.2005 18:25 > > > > > > > > > FYI, > > I've uploaded comments from ALCATEL side to "Week 5" in the "Incoming" > directory: > > http://ftp3.itu.int/av-arch/avc-site/Incoming/TD7%20Week%205%20Comment > s% > 20ASchwarz.doc > > > Major (technical) update is Generic Package Version 2 (instead V1) due > to inclusion of "onIteration" capability in my opinion. > > Also just the note that Alcatel contributions for next SG16 are in > planning with regard to: > 1) § E.11.5 "recommendations on statistics usage), and > 2) App. II (new § 5.8.6 Notify) > > Regards > Albrecht > > > > >

1 0

Re: Update r1; Re: H.248.1 V3 Editorial Comments: Week 5
by Christian Groves 15 Jun '05

15 Jun '05

Hello Albrecht, all, I agree with Albrechts suggestions. With regards to the Generic Package I think its is a typo that change be changed as extension rules say this must be a versioning of the package. With regards to your comments ABS7 "Wording of sentence? Makes this sense?" I think the sentence should read "Allowed terminations type combinations in a context". With regards to your comments ABS8 " Note: an ALCATEL contribution to next SG16 is planned proposing “§ 5.8.7 Notify” inclusion". I'm happy to accept this as Notify is a command and should be listed. Regards, Christian PS: Kevin: Did I miss week 4 ABNF sections? I'll send some comments on week 4 in the next couple of days. Albrecht.Schwarz(a)alcatel.de wrote: > I found two further typos in Appendix II. > -> Revision "...r1" file in Incoming directory again. > > Regards > Albrecht > > > > > > Albrecht > > SCHWARZ/DE/ALCAT To: SG16 > <itu-sg16(a)external.cisco.com> > EL@ALCATEL cc: > jan.lindquist(a)ERICSSON.COM > Subject: H.248.1 V3 > Editorial Comments: Week 5 > 13.06.2005 18:25 > > > > > > > > > FYI, > > I've uploaded comments from ALCATEL side to "Week 5" in the "Incoming" > directory: > > http://ftp3.itu.int/av-arch/avc-site/Incoming/TD7%20Week%205%20Comments% > 20ASchwarz.doc > > > Major (technical) update is Generic Package Version 2 (instead V1) due > to > inclusion of "onIteration" capability in my opinion. > > Also just the note that Alcatel contributions for next SG16 are in > planning > with regard to: > 1) § E.11.5 "recommendations on statistics usage), and > 2) App. II (new § 5.8.6 Notify) > > Regards > Albrecht > > > > >

1 0

Update r1; Re: H.248.1 V3 Editorial Comments: Week 5
by Albrecht.Schwarz＠alcatel.de 14 Jun '05

14 Jun '05

I found two further typos in Appendix II. -> Revision "...r1" file in Incoming directory again. Regards Albrecht Albrecht SCHWARZ/DE/ALCAT To: SG16 <itu-sg16(a)external.cisco.com> EL@ALCATEL cc: jan.lindquist(a)ERICSSON.COM Subject: H.248.1 V3 Editorial Comments: Week 5 13.06.2005 18:25 FYI, I've uploaded comments from ALCATEL side to "Week 5" in the "Incoming" directory: http://ftp3.itu.int/av-arch/avc-site/Incoming/TD7%20Week%205%20Comments%20 ASchwarz.doc Major (technical) update is Generic Package Version 2 (instead V1) due to inclusion of "onIteration" capability in my opinion. Also just the note that Alcatel contributions for next SG16 are in planning with regard to: 1) § E.11.5 "recommendations on statistics usage), and 2) App. II (new § 5.8.6 Notify) Regards Albrecht

1 0

H.248.1 V3 Editorial Comments: Week 5
by Albrecht.Schwarz＠alcatel.de 13 Jun '05

13 Jun '05

FYI, I've uploaded comments from ALCATEL side to "Week 5" in the "Incoming" directory: http://ftp3.itu.int/av-arch/avc-site/Incoming/TD7%20Week%205%20Comments%20 ASchwarz.doc Major (technical) update is Generic Package Version 2 (instead V1) due to inclusion of "onIteration" capability in my opinion. Also just the note that Alcatel contributions for next SG16 are in planning with regard to: 1) § E.11.5 "recommendations on statistics usage), and 2) App. II (new § 5.8.6 Notify) Regards Albrecht

1 0

Draft H.460.fantas
by Giles Chamberlin 13 Jun '05

13 Jun '05

Attached document is based on AVD-2718 from the Biel meeting. Modifications are to take into account the comments from the meeting and to improve clarity. In particular I hope I've succeeded in not breaking fast connect. As you'll see form the markup, there's more to do, but hopefully that's mostly editorial. Giles Chamberlin

1 0

Re: (????-??????????)Comments on Draft F-series documents
by Niexiuying 13 Jun '05

13 Jun '05

Dear Mr. OKUBO Sakae and all: I appreciate that Mr. OKUBO Sakae have given us the comments to draft F.dl and F.avod. I modified the draft F.dl and F.avod based on his comments. Attached is the new version of draft F.dl. The reply to Mr. OKUBO Sakaea's comments is as follows: You comments to the reversion of F.dl and comments to the reply are solicited. I will send the new version of Draft F.avod soon. Thank all of you for your comments in advance. Best Regard. Nie xiuying F.DL ^^^^ 1/ Table of Contents Why ex Section 8 Requirements has been dropped in this draft? It should be an essential part as shown in the title and scope. Add Ex Section 8 requirments to new document, delete 8.2 and 8.3 of last version. In my opinion, 8.2 and 8.3 have similar means to ex section 8. 2/ Section 1 I cannot understand the meaning of "responsive application solution" and the intention of including the "when applicable ITU-T Recommendations are not yet available" part. The latter looks contradictory if this documents is intended as an ITU-T Recommendation. I derived this setence from ITU- T REc. F.701. I think it refers to special application requirments and technical architecture and framwork. I delete the sentence from the new version document if it does not define anything. 3/ Section 2 We need to check if we can include IEEE standards as part of the normative references. I have checkITU-T releted document about it. the answer to it is "yes". 4/ Section 3, Distance Learning I do not understand what "sometimes connectedness" means. It means "through telecommunication networks"., because using post ( or mail) to send learning material is also a kind of "distance learning". 5/ Section 6, last paragraph The same comment as 1/. 6/ Section 7.1.1, Case 2, Stage 1 It is implied that DLSP provides instant messaging. Videophone and telephone look separate from DLSP. Is that the intention? It only refers to that individual instruct can also be achieved using videophone or telephone. It may or may not within DLSP. For this draft scope, I delete them from this document to limite distance learning to multimedia services. 7/ Section 7.3, 1st paragraph I would suggest to itemize listed applications as bullets. I modify the document based on this suggestion. 8/ Section 7.3, 2nd paragraph "conferences" and "files distribution applications" look too generic for this document addressing distance learning service. I delete them. 9/ Section 8.2 I would suggest to itemize listed applications under the sentence: The following are desirable adjuncts to the distance learning application: I delte this section, because I add ex section 8 requirments to this document. F.avod ^^^^^^ 1/ Section 5, 2nd paragraph I wonder if the scope of this document is limited to the use of "current carriers networks." I believe it should also take into account other type of networks like corporate, private ones. Chang it to telecommunications networks to include other networks. 2/ Section 6.1, 2nd paragraph This description doe not match Figure 1. "Control and management system" is a part of the "service provider" there. Change the description to " .. is made of content providers, service providers and end users " 3/ Section 6.1, after Figure 1, 2nd bullet, 2nd sentence It is hard to capture the structure of this sentence. Please rephrase it. 4/ Section 6.1 "value-added services" is too generic. We need some examples in the context of avod. Give some examples . such as audivisual on demand service prsented, gaming, per-order audiovisual on demand services. 5/ Section 7.1, 1st paragraph, 3rd sentence I cannot understand what "integrating centralized or distributed methods" means. Delete them form document. It refers to CDN based method and peer to peer delivery method. 6/ Section 7.2, 1st paragraph, 4th sentence starting with "Some current affairs, ..." This sentence is incomplete. delete this sentence. 7/ Section 7.3, Stage 5, 2nd last sentence It is not clear to me how "due to he has passed the authentication before" related to other part of the sentence. delete " after he passes authentication". 8/ Section 8.3, 3rd sentence This sentence is incomplete. change "." to ","to make two sentences into one sentence. 9/ Section 8.6, after the three bullets What is "start time"? Response time to the request of an audiovisual content? yes, it is. 10/ Section 9, 2) Add some more descriptions, "control" is necessary in any type of avod applications as far as "on demand" is involved. Change " control" to " monitoring". 11/ Section 11.2, 1st sentence It looks we are comparing the two different categories; provider (SP stands for Service Provider) and system (videoconference system). It is not a surprise if they are quite different in functions.　 Delete the first paragraph.　 _____ ========= _____

1 0

Re: Comments on Draft F-series documents
by sunmingjun 13 Jun '05

13 Jun '05

Dear Mr. Okubo and all, I have no problem to the editioral of F.MMCIP, following orange texts are the reply to the questions. Comments from Mr.Okubo are appreciated, and other comments and suggestions are solicited. Best£¬ Mingjun Sun sunmingjun(a)catr.com.cn China Academy of Telecommunication Technology +86-10-62302430-2413 2005-06-13 ----- Original Message ----- From: "OKUBO Sakae" <okubo(a)MXZ.MESH.NE.JP> To: <itu-sg16(a)external.cisco.com> Sent: Thursday, June 09, 2005 4:21 PM Subject: Comments on Draft F-series documents > > F.MMCIP > ^^^^^^^ > > 1/ Section 2.6 > > As we have "multimedia conference service" in Section 2.9, I would > suggest the following: > > A type of multimedia conference service that utilizes networks for > control and media transfer. > > 2/ Section 2.7, last sentence > > As we may also use ALM (Application Layer Multicast) in the future, > use of network transport multicast may not be an only solution. "may" > instead of "should" would be more appropriate. > > 3/ Section 5, 2nd paragraph > > "If there are two or more terminals, ..." I wonder if the number be > "three or more" instead of "two ore more". The multimedia information > control and exchange is needed also for the case where only two > terminals are involved? > The multimedia information control and exchange isn¡¯t needed in fact, but in some cases, the multimedia information control and exchange still works. For example, three terminals in a five-endpoints conference leaves, but the conference still continues, the multimedia information control and exchange still is needed though only the two terminals in this conference. > 4/ Section 5, 3 bullets > > It looks multiple viewpoints are involved to get these three types of > terminal: hardware/software, full/part time use, movable/fixed. > Please sort them out. > following is the propositional modification text : There are two types of terminal: ¨C Hard terminal, which includes two sub-type of terminals: dedicated studios equipped for multimedia conferences, named special conference terminal; equipment only part-time used for teleconferencing, can be moved from here to there, named Portable Terminal ¨C Soft terminal, running on Computer > 5/ Section 6.1, 2nd sentence > > We need clarification here. > > Since the "Voice/Video/Data Switch & Process function" is in the > IP-based Network area, the multimedia path between the switch&process > function and the right most User is understood to be IP. Does this > mean that PSTN Access terminal is using IP over PSTN? It looks more > realistic to me that the switch&process function has PSTN interface > and the voice is ordinary analog one. > since the function of "Voice/Video/Data Switch & Process function" is mainly about media processing, so my suggestion to this problem is another ¡°gateway function¡± is added for the PSTN and IP transition, also for the mobile. > 6/ Section 6.3 > > I would suggest to unify the function listing style as verb first. >

1 0

Comments on Draft F-series documents
by OKUBO Sakae 09 Jun '05

09 Jun '05

Dear editors and all, Very belatedly, please find after the signature my comments to the following four documents posted in April: F.VTIP Service description and requirements for videotelephony over IP services (Editor: Mr Zhang Qing) <http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/FVTI P_050414.zip> F.MMCIP Service description and requirements for multimedia conferencing over IP services (Editor: Ms Sun Mingjun) <http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/FMMC IPv1.1_050410.zip> F.DL Service description and requirements for distance learning services (Editor: Ms Nie Xiuying) <http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/Fdlr ev1_050410clear.zip> F.AVoD Service description and requirements for audiovisual on demand services (Editor: Ms Nie Xiuying) <http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/FAVO Drev1_050414.zip> They are mostly editorial to make the documents more understandable. Your review about the substance is requested so that we can decide in July if these documents be processed as draft Recommendations. Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ****************************************************************** Comments common to the four documents ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1/ I would suggest to include an introductory text to the service scenario section indicating its purposes, something like: This section describes typical service scenarios to illustrate the ... service and to derive its technical requirements. 2/ Please make sure that the "requirements" section reflects all of what the service scenarios indicate. 3/ "stage" vs "step" Since the terms "stage 1", "stage 2" and "stage 3" have particular meanings defined in I.130, please use "step" for our current documents. 4/ Use of capital letters It looks the use of capital letters are not consistent. The ITU guideline is in Appendix I to A.15: Unnecessary use of capitalized words should be avoided. 5/ Editorial observations I have placed marked up documents with my observations at the following place: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/FVTIP _050414_SO.zip http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/FMMCI P_050410_SO.zip http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/Fdl_0 50410_SO.zip http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/FAVOD _050414_SO.zip Please note that the text in {} is not a modification itself but shows my comment or question F.VTIP ^^^^^^ 1/ Section 4, 3rd paragraph It may hint that videotelephony service = conventional telephony service. The use of videotelephony services ... ==> The way to place a call of videotelephony services is just the same as that of conventional telephony services ... 2/ Section 4, 2nd bullet Audio and video mixing devices may be operated by the "network" or by the "user." It would be more appropriate to delete "network" from "network devices." 3/ Section 5.2 "unmanned baby-sitting for unattended kids" should be "unmanned baby-sitting for kids"? Kids with baby-sitting are attended, I think, 4/ Section 5.3 It is not clear to me how the service profiles will be utilized in this document or other places. Please add some more positive statements of the intention. Just "for references" looks weak. 5/ Section 6.1.3, 1st paragraph Can we replace "800 customer service" with a generic naming? I think "800" is the number in the US, it is called "free dial" service in Japan and the number starts with 0120. 6/ Section 7.1, Basic requirements, 3rd bullet I wonder if "when necessary" adds particular meaning compared to the sentence without those two words. 7/ Section 7.6.1, 2nd sentence "terminal-based echo-cancellation" means acoustic echo-cancellation? Its parallel term would be "network-based" echo-cancellation. Here we are addressing echo due to the feedback from the loud-speaker to the microphone, not the one due to the 4-wire to 2-wire conversion in the network. My point is that network-based echo-cancellation may in principle deal with both network echo and acoustic echo while the terminal-based echo-canllelation deals with only acoustic echo. 8/ Section 7.6.4 1st sentence I am afraid "whenever there are motions in the human facial regions, e.g., lips or eyes" is not always true. Probably you are referring to the case where frame dropping is employed when a large amount of data is generated due to large motions. I would suggest to describe the case more precisely or delete the quoted text. F.MMCIP ^^^^^^^ 1/ Section 2.6 As we have "multimedia conference service" in Section 2.9, I would suggest the following: A type of multimedia conference service that utilizes networks for control and media transfer. 2/ Section 2.7, last sentence As we may also use ALM (Application Layer Multicast) in the future, use of network transport multicast may not be an only solution. "may" instead of "should" would be more appropriate. 3/ Section 5, 2nd paragraph "If there are two or more terminals, ..." I wonder if the number be "three or more" instead of "two ore more". The multimedia information control and exchange is needed also for the case where only two terminals are involved? 4/ Section 5, 3 bullets It looks multiple viewpoints are involved to get these three types of terminal: hardware/software, full/part time use, movable/fixed. Please sort them out. 5/ Section 6.1, 2nd sentence We need clarification here. Since the "Voice/Video/Data Switch & Process function" is in the IP-based Network area, the multimedia path between the switch&process function and the right most User is understood to be IP. Does this mean that PSTN Access terminal is using IP over PSTN? It looks more realistic to me that the switch&process function has PSTN interface and the voice is ordinary analog one. 6/ Section 6.3 I would suggest to unify the function listing style as verb first. F.DL ^^^^ 1/ Table of Contents Why ex Section 8 Requirements has been dropped in this draft? It should be an essential part as shown in the title and scope. 2/ Section 1 I cannot understand the meaning of "responsive application solution" and the intention of including the "when applicable ITU-T Recommendations are not yet available" part. The latter looks contradictory if this documents is intended as an ITU-T Recommendation. 3/ Section 2 We need to check if we can include IEEE standards as part of the normative references. 4/ Section 3, Distance Learning I do not understand what "sometimes connectedness" means. 5/ Section 6, last paragraph The same comment as 1/. 6/ Section 7.1.1, Case 2, Stage 1 It is implied that DLSP provides instant messaging. Videophone and telephone look separate from DLSP. Is that the intention? 7/ Section 7.3, 1st paragraph I would suggest to itemize listed applications as bullets. 8/ Section 7.3, 2nd paragraph "conferences" and "files distribution applications" look too generic for this document addressing distance learning service. 9/ Section 8.2 I would suggest to itemize listed applications under the sentence: The following are desirable adjuncts to the distance learning application: F.avod ^^^^^^ 1/ Section 5, 2nd paragraph I wonder if the scope of this document is limited to the use of "current carriers networks." I believe it should also take into account other type of networks like corporate, private ones. 2/ Section 6.1, 2nd paragraph This description doe not match Figure 1. "Control and management system" is a part of the "service provider" there. 3/ Section 6.1, after Figure 1, 2nd bullet, 2nd sentence It is hard to capture the structure of this sentence. Please rephrase it. 4/ Section 6.1 "value-added services" is too generic. We need some examples in the context of avod. 5/ Section 7.1, 1st paragraph, 3rd sentence I cannot understand what "integrating centralized or distributed methods" means. 6/ Section 7.2, 1st paragraph, 4th sentence starting with "Some current affairs, ..." This sentence is incomplete. 7/ Section 7.3, Stage 5, 2nd last sentence It is not clear to me how "due to he has passed the authentication before" related to other part of the sentence. 8/ Section 8.3, 3rd sentence This sentence is incomplete. 9/ Section 8.6, after the three bullets What is "start time"? Response time to the request of an audiovisual content? 10/ Section 9, 2) Add some more descriptions, "control" is necessary in any type of avod applications as far as "on demand" is involved. 11/ Section 11.2, 1st sentence It looks we are comparing the two different categories; provider (SP stands for Service Provider) and system (videoconference system). It is not a surprise if they are quite different in functions. ==========

1 0

FW: An important step for interoperability and functionality of text communication: RFC 4103 replaces RFC 2793.
by simao.campos＠itu.int 07 Jun '05

07 Jun '05

FYI -----Original Message----- From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] Sent: 07 June 2005 11:13 To: Text Telephone Forum; STF267 Cc: Björn Troili; eConf Support; Frank Shearar; Andreas Piirimets(Omnitor); Andreas Richter; Kristian Kristiansson; Johan Malmgren; Bill Pechey; Judy Harkins; Paul Jones(Packetizer); Marcelo Tapia; George Skorkowski; Bo Bergner; Robert Hecht; Andrea Saks; Guido Gybels (E-mail); Arnoud van Wijk; Gregg Vanderheiden; TR-30. 1; Campos, Simao; Tom Taylor; Henry Sinnreich; Christian Groves; Pekka. V. Heikkinen; Claes Tjäder Subject: An important step for interoperability and functionality of text communication: RFC 4103 replaces RFC 2793. An IETF document describing real time text transmission in IP networks is approved and published. The work with revision of the real time text transport specification RFC 2793 in IETF is completed. During the work, we have called it rfc2793bis. The result is now published as a standards track RFC: RFC 4103 RTP Payload for Text Conversation By that, RFC 2793 is made obsolete. RFC 4103 is backwards compatible with its predecessor, so the move will be smooth. There are two new parameters to handle. All references to RFC 2793 in other standards can now be read as RFC 4103, and should eventually be replaced in the texts by RFC 4103. This is valid for example for the following documents referring to RFC 2793. ITU-T H.323 Annex G Text converation and Text SET ITU-T H.248.2 Text, Fax and call discrimination packages ITU-T Draft requirements for text over IP ITU-T Draft V.151 Procedures for the end-to-end connection of analogue PSTN text telephones over an IP network utilizing text relay. ETSI TS 126 235 IP Multimedia default codecs ETSI TS 123 226 Global Text Telephony Stage 2 ETSI Draft EG 202 320 Duplex Universal Speech and Text 3GPP TS 26.235 IP Multimedia default codecs 3GPP TS 23.226 Global Text Telephony Stage 2 draft-ietf-sipping-toip Text over IP requirements draft-sinnreich-sipdev-req SIP telephony device requirements draft-ietf-avt-rfc2833bis RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals draft-ietf-avt-rfc2833bisdata Definition of Events For Modem, FAX, and Text Telephony Signals The main improvements are: -------------------------- -SDP examples clearly showing how a real time text channel can be negotiated and opened in a SIP session. -Clear packet layout examples showing various cases with and without redundancy. -Clearer and stronger recommendations to use the default two levels of redundant transmission to keep the risk for character loss very low. -Clearer and stronger recommendations to use 300 ms buffering between transmissions in order to keep the risk for character loss very low and to keep bandwidth usage for text very low. -More explicit recommendations on how to apply security considerations. -More explicit descriptions of the procedures for recovery from packet loss. -More explicit descriptions of the procedures for protection from congestion. By these improvements, I am sure that this RFC will contribute well to good interoperability and high functionality of real time conversation applications including the imnportant text medium as a popular feature improving communications for all. I and Paul Jones stand as authors, but many more have made this improvement possible by putting efforts into the work. Thanks to all! Another related document has also been published. It is RFC 4102 Registration of the text/red MIME Sub-Type. Here is a copy of the IETF announcements: -------------------------------------------------------------------------- ---------------- - A new Request for Comments is now available in online RFC libraries. RFC 4103 Title: RTP Payload for Text Conversation Author(s): G. Hellstrom, P. Jones Status: Standards Track Date: June 2005 Mailbox: gunnar.hellstrom(a)omnitor.se, paulej(a)packetizer.com Pages: 20 Characters: 44246 Obsoletes: 2793 I-D Tag: draft-ietf-avt-rfc2793bis-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4103.txt This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140. One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text. This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. ------------------------------------------------------------------------- A new Request for Comments is now available in online RFC libraries. RFC 4102 Title: Registration of the text/red MIME Sub-Type Author(s): P. Jones Status: Standards Track Date: June 2005 Mailbox: paulej(a)packetizer.com Pages: 6 Characters: 11337 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-text-red-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4102.txt This document defines the text/red MIME sub-type. "Red" is short for redundant. The actual RTP packetization for this MIME type is specified in RFC 2198. This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. ---------------------End of copy--------------------- Regards Gunnar ------------------------------------------- Gunnar Hellström Omnitor AB Renathvägen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom(a)Omnitor.se --------------------------------------------

1 0

Editing Comment from Week 1 and Week2
by Christian Groves 07 Jun '05

07 Jun '05

Hello all, The following 2 sections talk about package extension. 6.2.3 Packages For improved interoperability and backward compatibility, an MG MAY publish all Packages supported by its Terminations, including base Packages from which extended Packages are derived. An exception to this is in cases where the base packages are expressly "Designed to be extended only". 12.1.1 Designed to be extended only (Optional): Yes This indicates that the package has been expressly designed to be extended by others, not to be directly referenced. For example, the package may not have any function on its own or be nonsensical on its own. The MG SHOULD NOT publish this PackageID when reporting packages. I think there could be a chance that some people misread section 6.2.3 in that "Designed to be extended only" packages MAY be published. I believe this is not the intention as clarified in section 12.1.1. Therefore I would propose that 6.2.3 states: 6.2.3 Packages .. For improved interoperability and backward compatibility, an MG MAY publish all Packages supported by its Terminations, including base Packages from which extended Packages are derived. An exception to this is in cases where the base packages are expressly "Designed to be extended only"<<<, these packages shall not be published.>>> Regards, Christian

1 0