Re: [rtcweb] No Plan

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 03 June 2013 21:43 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBEB11E8109 for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 14:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.152
X-Spam-Level:
X-Spam-Status: No, score=-0.152 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC7k8kQHprjQ for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 14:43:16 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id E102A11E810A for <rtcweb@ietf.org>; Mon, 3 Jun 2013 14:40:31 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta02.westchester.pa.mail.comcast.net with comcast id joYh1l0050QuhwU51xgX04; Mon, 03 Jun 2013 21:40:31 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id jxgX1l00X3ZTu2S3NxgX07; Mon, 03 Jun 2013 21:40:31 +0000
Message-ID: <51AD0D4E.5000207@alum.mit.edu>
Date: Mon, 03 Jun 2013 17:40:30 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= <ibc@aliax.net>
References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <CALiegfk6XchF4U1Orpd6oJsydz-VGtBQ=CwaWrPa_KjsaQynYQ@mail.gmail.com> <51A7CD81.2060805@gmail.com> <51A835D7.9060603@omnitor.se> <CALiegfm4R=3mGqTOxBfvCfnsRg=fe=XapA6s-QQNjrsAkg5HEA@mail.gmail.com> <51A8F3EF.9080702@alum.mit.edu> <CALiegfkfz=qVM_wB21BBOypMTwTjkyG97zAmzHVpA6WHK2DA6w@mail.gmail.com> <51AD0472.9020506@alum.mit.edu> <CALiegfn099xpZ4Gj950PtGWU0CPx0HZOs7aF--nMj8L6mza0Gg@mail.gmail.com>
In-Reply-To: <CALiegfn099xpZ4Gj950PtGWU0CPx0HZOs7aF--nMj8L6mza0Gg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370295631; bh=+M+LcvloESxZPidxvFO1DoHuay2qiAtoof4H4Gk8eeM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=keLXbJnfFzEYWq/crE5Yp6KxZCr4v2FVtgYfCzqUEJFdH34A814YaoO2Zkf/Qa9w+ T9Nhk7bnVL799cLTuYfdMytLh8luPakk+tPg8rd0UeFQmxyaUK6GNFaNdZmk84SDsD zAlO6XmPoCq6vaZemDNvb6iV2G6+GqYE9j5W4X99V+k7jFxPcbf1ajxGoFvEFS42Xs V2iwIzUN9AEINhR87TE/ZMyecqr2DWI9F7Wk4wWq3BWKBWCc35wJWp3HYwnOhID8/x ksY0+odcTJlvQoNx3cGZUA0uSOtKN+Blly00mBm7rtzKWTIWNaj2ObfqF53ZmV5stQ qkQqKAZOfkNvA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] No Plan
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jun 2013 21:43:32 -0000

RFC4103

On 6/3/13 5:20 PM, Iñaki Baz Castillo wrote:
> 2013/6/3 Paul Kyzivat <pkyzivat@alum.mit.edu>du>:
>
>> One answer may be that the difference is that the real-time requirements for
>> text aren't as demanding as they are for voice or video. But there are other
>> good reasons for identifying interactive text as media. One reason is what
>> we are arguing right how: the desire to negotiate properties of the
>> transmission. (Should it be byte-by-byte or line-by-line.) Another is that,
>> like voice and video there is likely to be a demand to record it for later
>> analysis and playback, or to broadcast it to a collection of people.
>>
>> When text is treated as media, then treating it in parallel with other media
>> makes more sense. (For instance ensuring the that the text is synchronized
>> with the other media, both initially and when recorded and played back
>> later.)
>
> Well, I must recognize that now I see a real usecase: realtime
> subtitles synchronized with audio/video streams. That would be much
> better than the typicall subtitles embed in the video stream (because
> it could be rendered as real text, so the user could choose the text
> size, and so on).
>
> Problems of standarizing text over RTP:
>
> - Encoding
>
> - ¿just plain text? ¿could it be HTML code instead? ¿how to send
> hyperlinks? ¿how to use custom markup?
>
> - Integrity: RTP can loose packets, do we accept that a chat can loose
> "chars" or "lines"?
>
>
>
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
>