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

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]