Re: [MMUSIC] [AVTCORE] New Possible Errata in RFC2326 (And Draft) regarding Blocksize

worley@ariadne.com (Dale R. Worley) Sat, 10 January 2015 02:28 UTC

Return-Path: <worley@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B1B1A6FEB for <mmusic@ietfa.amsl.com>; Fri, 9 Jan 2015 18:28:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjhhaDp_hqiK for <mmusic@ietfa.amsl.com>; Fri, 9 Jan 2015 18:28:26 -0800 (PST)
Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FBF01A6EEC for <mmusic@ietf.org>; Fri, 9 Jan 2015 18:28:25 -0800 (PST)
Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-07v.sys.comcast.net with comcast id e2UP1p0072VvR6D012UPhr; Sat, 10 Jan 2015 02:28:23 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-19v.sys.comcast.net with comcast id e2UP1p0051KKtkw012UPQd; Sat, 10 Jan 2015 02:28:23 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id t0A2SMF2026545; Fri, 9 Jan 2015 21:28:22 -0500
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id t0A2SMYw026542; Fri, 9 Jan 2015 21:28:22 -0500
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Julius Friedman <juliusfriedman@gmail.com>
In-Reply-To: <CACFvNHXwTm5k7Wiw65A=eSBEF9RqP4FJnNysziFik7vpnqrR4A@mail.gmail.com> (juliusfriedman@gmail.com)
Sender: worley@ariadne.com
Date: Fri, 09 Jan 2015 21:28:22 -0500
Message-ID: <87r3v38j3t.fsf@hobgoblin.ariadne.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1420856903; bh=Q7Pfz1LSM914iCDd9q9DGw1vE/nWobp/18VqpaxnKhI=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=psm781T9wSlIiNQVf6bmMDUkOWXR7wC+7gosBdnsnZtCsrD2vqNw12PIJ3RDWKdiE TLHu0xqPuwQQC4ok6kN+2hLZSRCiPajWIenQcGyBWwbMmyO2GSi5PHIqYUM38+Rx3A 3ZRGONSKAK7ZtPzIYz9sueHWpVKiCkXd6HkKt7LNphXdHNOXFuQau7sajUizJom1/h +AiAwYtJCpiUYRyr4aP6IJuJUHIes595c2r311MYywI/E87yWSzjw33F1XHQmGpMVj JMx8RkEPpAmdBdd/qEiP845YcT+mxjKjunzDpUlsPgh2KRBHLVOgZk/5TCpQaH6Lh4 r0iCN8Ocr/u4w==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/OTXDuhuQvzKULHVn1se395W-FKQ>
Cc: mmusic@ietf.org, avt@ietf.org
Subject: Re: [MMUSIC] [AVTCORE] New Possible Errata in RFC2326 (And Draft) regarding Blocksize
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Jan 2015 02:28:28 -0000

Julius Friedman <juliusfriedman@gmail.com> writes:
> 18.10 <http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40#section-18.10>.
> Blocksize
>
>    The Blocksize request-header field is sent from the client to the
>    media server asking the server for a particular media packet size.
>    This packet size does not include lower-layer headers such as IP,
>    UDP, or RTP.  The server is free to use a blocksize which is lower
>    than the one requested.  The server MAY truncate this packet size to
>    the closest multiple of the minimum, media-specific block size, or
>    override it with the media-specific size if necessary.  The block
>    size MUST be a positive decimal number, measured in octets.  The
>    server only returns an error (4xx) if the value is syntactically
>    invalid.
>
> Both paragraphs go to specify that the number MUST be positive but
> specify no LOWER bound.
>
> A Blocksize of 12 or less will cause data loss under UDP and cause
> invalid framing under TCP.

Could you explain this in more detail?  Since the "Blocksize" number
"does not include lower-layer headers such as IP, UDP, or RTP", it seems
to me that it counts only the bytes after the "RTP Fixed Header Fields"
and any RTP header extensions, and that number legitimately could be
small (depending on the media encoding in the RTP).

> It should be noted that the Blocksize MUST be a positive decimal
> number greater than or equal to that supported by the underlying
> transport.

In any case, *this* RFC does not *have* to state that, as that is a
requirement imposed by other RFCs. 

> I would like to file this errata as soon as possible if everyone agrees;
>
> If it's not erratum can we please also address this misnomer I seem to have.

As far as I can tell, it's not an erratum, because there is no "error"
in the RFC.  What you're suggesting is that there is useful information
that the RFC does not include, but that information is not an error in
this RFC's text.

Dale