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

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]