[media-types] Re: [IANA #1448465] application/syslog r egistration request

Approved as "application/syslog-msg".

-MSK

On Thu, Apr 9, 2026 at 4:36 PM Sabrina Tanamal via RT <
[email protected]> wrote:

> Hi Murray,
>
> Following up on this request from March 26th.
>
> Thanks,
> Sabrina
>
> On Thu Apr 02 23:27:46 2026, amanda.baber wrote:
> > Hi Murray,
> >
> > Sending a reminder for this request from March 26th.
> >
> > thanks,
> > Amanda
> >
> > On Thu Mar 26 20:27:40 2026, amanda.baber wrote:
> > > Hi Murray,
> > >
> > > This is a request to recommend to the IESG that they approve this
> > > media type as a grandfathered type. Please see the requester's note
> > > and template below.
> > >
> > > IANA questions:
> > >
> > > 1) If this is OK to grandfather:
> > >
> > > a) Should the subtype name be changed from "syslog" to "syslog-msg",
> > > as he suggests below?
> > >
> > > b) Is the change controller field OK?
> > >
> > > 2) If grandfathering isn't appropriate, should this be registered now
> > > as "application/vnd.syslog"?
> > >
> > > thanks,
> > > Amanda
> > >
> > > ======
> > >
> > > Note from applicant:
> > >
> > > I could argue that this should be a candidate for grandfathering.  The
> > > syslog protocol is defined by an official RFC that dates back to March
> > > 2009.  The two subsequent RFCs, also from March 2009, document this
> > > for transport over TCP and UDP respectively.  These received port
> > > assignments but no media types.  I can't speak for the RFC authors,
> > > but I imagine that they did not consider submitting a media type in
> > > their RFC as they were building on the design of the existing
> > > traditional syslog implementations and assumed it would be used only
> > > in that context.
> > >
> > > I believe it would make sense to see if we could have this
> > > grandfathered in with one change:  Change the media type on my
> > > application to `application/syslog-msg` to match RFC5424.  This RFC
> > > defines the protocol and message format whereas the others map to a
> > > specific transport.  The message format is defined in Section 6
> > > (https://www.rfc-editor.org/rfc/rfc5424#section-6).  This keeps the
> > > media type confined to a single RFC without any changes to the format.
> > > It also keeps the media type "application/syslog" available should
> > > anyone wish to pursue a more general-purpose syslog usage.  Would that
> > > be reasonable?  If so, what would be the next steps?
> > >
> > > As for a using the vendor tree, that is certainly a possible
> > > alternative.  I avoided that route because I wished to have this media
> > > type (and corresponding CoAP content-format) useable more broadly.
> > > Since we are not making any changes to the protocol, I did not feel it
> > > appropriate to put this as a vendor specific media type.  We had no
> > > part in the syslog work, we're just simple using it in our work.
> > >
> > > Hopefully that makes sense.  Happy to provide any more details or
> > > information to support this application.
> > >
> > > Template:
> > >
> > > Name: Stephen Berard
> > >
> > > Email: [email protected]
> > >
> > > Media type name: application
> > >
> > > Media subtype name: syslog
> > >
> > > Required parameters: N/A. The MSG field encoding variant (MSG-ANY or
> > > MSG-UTF8) is signaled within the payload itself via the presence or
> > > absence of a UTF-8 BOM (0xEF 0xBB 0xBF) at the start of the MSG field,
> > > per RFC 5424 Section 6.4. No external parameters are needed to parse
> > > or interpret the message.
> > >
> > > Optional parameters: N/A
> > >
> > > Encoding considerations: binary
> > >
> > > Per RFC 5424 Section 6.4, the MSG field is defined as *OCTET in both
> > > its MSG-ANY and MSG-UTF8 variants, permitting NUL octets, bare CR and
> > > LF octets, and content exceeding 998 octets in length. Binary encoding
> > > is therefore required.
> > >
> > > Security considerations: (1) No executable content — syslog is
> > > observational log data with no execution model
> > > (2) Syslog messages routinely contain hostnames, process identifiers,
> > > usernames, IP addresses, and application-level detail that may include
> > > credentials or session tokens if an application logs carelessly.
> > > (3) The format does not provide any mechanism. Mechanisms such as TLS
> > > and/or DTLS should be used.
> > > (4) This format is defined in RFC5424 which has defined security
> > > considerations [RFC5424 Section 8](RFC 5424 has its own Security
> > > Considerations section (Section 8) which must be referenced.)
> > > (5) The format does not incorporate links that need to be interpreted.
> > >
> > > Interoperability considerations: The format is defined by
> > > [RFC5424](https://www.rfc-editor.org/rfc/rfc5424) and is designed for
> > > interoperability. Syslog is widely used by many UNIX/Linux/POSIX and
> > > other systems.
> > >
> > > Published specification: The syslog protocol is defined in
> > > [RFC5424](https://www.rfc-editor.org/rfc/rfc5424)
> > >
> > > Two additional RFCs define transport mappings for TCP
> > > [RFC5425](https://www.rfc-editor.org/rfc/rfc5425) and for UDP
> > > [RFC5426](https://www.rfc-editor.org/rfc/rfc5426). Though no media
> > > type has been requested as of yet.
> > >
> > > Applications which use this media: This media type identifies a
> > > payload as a single RFC 5424 syslog message. While established
> > > transport mappings exist for UDP (RFC 5426) and TCP (RFC 6587),
> > > neither defines a MIME content type. This registration is intended for
> > > use in application-layer protocols that require explicit content type
> > > identification, such as HTTP or CoAP, enabling correct payload
> > > dispatch and content negotiation without reliance on transport-layer
> > > conventions.
> > >
> > > Fragment identifier considerations: N/A
> > >
> > > Restrictions on usage: None
> > >
> > > Provisional registration? (standards tree only): No
> > >
> > > Additional information:
> > >
> > > 1. Deprecated alias names for this type: N/A
> > > 2. Magic number(s): None
> > > 3. File extension(s): None - no file storage type is defined for
> > > syslog
> > > 4. Macintosh file type code: None
> > > 5. Object Identifiers: 1.3.6.1.2.1.192 (SYSLOG-MSG_MIB) defined by
> > > [RFC5676](https://www.rfc-editor.org/rfc/rfc5676)
> > >
> > > General Comments: This registration is motivated by the need to assign
> > > a CoAP Content-Format ID (per RFC 7252 Section 12.3) for syslog
> > > payloads in constrained device environments. The CoAP Content-Formats
> > > registry requires a registered IANA media type as a prerequisite for
> > > such an assignment. A separate CoAP Content-Format registration has
> > > been filed along with this media type registration.
> > >
> > > Person to contact for further information:
> > >
> > > 1. Name: Stephen Berard
> > > 2. Email: [email protected]
> > >
> > > Intended usage: COMMON
> > >
> > > Author/Change controller: Stephen Berard
>
>

_______________________________________________
media-types mailing list -- [email protected]
To unsubscribe send an email to [email protected]