Re: [ietf-types] Registration of application/smpte336m

[Jeff Downs <[e-mail]>]

The encoding considerations text of "binary and framed" in the proposed 
registration of application/smpte336m (as part of 
draft-ietf-payload-rtp-klv-02) comes literally out of the template in 
draft-ietf-payload-rtp-howto-01.

The format is, indeed, binary (not textual).  I reviewed RFC 3555 and 
the usage of "binary" vs. "framed" isn't very clear to me, but as I read 
it the difference is whether or not the payload data can exist 
"standalone" without the frame headers/transport data.  SMPTE 336M data 
can indeed exist outside such framing and be reasonably interpreted 
(without the notion of data timing), though this certainly does not fall 
within the scope of the I-D submitted by myself (rather it is the core 
of the SMPTE 336M specification itself).

I am more than happy to defer to the expertise of others; if dropping 
binary is the right thing to do here I am completely ok with that change.

Please include me directly on any follow-ups.

Jeff Downs
PAR Government Systems


-----Original Message-----
From: Bjoern Hoehrmann [mailto:[e-mail]]
Sent: Friday, January 13, 2012 10:46 AM
To: Ali C. Begen (abegen)
Cc: [e-mail]; [e-mail]
Subject: Re: [ietf-types] Registration of application/smpte336m

* Ali C. Begen (abegen) wrote:
>6.1.  Media Type Definition
>
>      Type name: application
>
>      Subtype name: smpte336m
>
>      Required parameters:
>
>         rate: RTP timestamp clock rate.  Typically chosen based on
>         sampling rate of metadata being transmitted, but other rates
>         can be specified.
>
>      Optional parameters: None
>
>      Encoding considerations: This media type is framed and binary; see
>      Section 4.8 of [RFC4288].

Why does this include "binary"?
-- 
Björn Höhrmann · mailto:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/