[media-types] [IANA #1448465] application/syslog registr ation request

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]