[media-types] Re: [IANA #1423130] text/vnd.wmap regi stration request

Hi Amanda,

My apologies for the delay on this one.

This is mostly fine, but I have one significant comment below (and a few 
other non blocking comments):

On 22/07/2025 16:02, Amanda Baber via RT wrote:
> Hi Alexey,
>
> Sending a reminder for this request from July 11th.
>
> thanks,
> Amanda
>
> On Fri Jul 11 17:35:25 2025, amanda.baber wrote:
>> Hi Alexey,
>>
>> Would you be able to review this new one by July 25th?
>>
>> thanks,
>> Amanda
>>
>> =====
>>
>> Name: Rubén Fabián Beltrán del Río Vara
>>
>> Email: [email protected]
>>
>> Media type name: text
>>
>> Media subtype name: vnd.wmap
>>
>> Required parameters: N/A
>>
>> Optional parameters: Parameter name: charset
>> Parameter value syntax: As defined in RFC 2045, Section 5.1 and RFC
>> 2046,
>> Section 4.1.2. The value must be a registered charset name from the
>> IANA
>> Character Sets registry.
>> Parameter semantics: Specifies the character encoding used to
>> represent the
>> textual content of the wmap file. The charset parameter follows the
>> same
>> syntax and semantics as defined for other text media types.
>> Default value: UTF-8 (when charset parameter is not specified)
>>
>> Encoding considerations: binary
>>
>> The wmap format is a text-based format that uses UTF-8 encoding by
>> default.
>> Content consists of human-readable text using standard Unicode
>> characters.
>>
>> The format is designated as "binary" encoding because:
>> - Line endings may be Unix (LF), Windows (CRLF), or classic Mac (CR)
>> format, meaning CR and LF octets can appear outside of CRLF sequences

There is a slight problem here, because text/* don't allow for line 
ending other than CRLF.

If allowing for bare CRs and bare LFs as line ending is important, maybe 
this can be changed to "application/vnd.wmap", which doesn't have such 
restriction on line ending?

>> - No enforcement is made for line lengths, so in theory, component
>> labels and note text content may potentially exceed 998 octets per
>> line.
Irrespective of my comment above, I agree that "binary" is correct for 
this media type.
>> Security considerations: The wmap format is a declarative text format
>> for describing Wardley Maps and poses minimal security risks. The
>> format contains only textual data that describes components,
>> relationships, and metadata.
>>
>> As with any text format, implementations should validate input and
>> handle malformed content gracefully. The format does not support
>> executable code, external references, or embedded binary data.
>>
>> Applications processing wmap files should implement appropriate input
>> validation to prevent buffer overflows or denial of service attacks
>> from malformed input.
>>
>> Interoperability considerations: The wmap format is designed for
>> interoperability between Wardley mapping tools and applications. The
>> format uses a simple, line-oriented syntax that can be parsed by
>> standard text processing tools.
>>
>> Different line ending conventions (LF, CRLF, CR) are supported to
>> ensure cross-platform compatibility. The grammar is case-insensitive
>> for keywords while preserving original case for display purposes.
>>
>> Published specification: The wmap format specification is defined
>> using Extended Backus-Naur Form (EBNF) and is available at:
>> https://map.tranquil.systems/wmap-spec.ebnf.txt
>>
>> Applications which use this media: - Map (macOS application for
>> creating Wardley Maps) (https://map.tranquil.systems)
>> - Map for Linux (A linux port of Map currently in development)
>> - Map for Classic Mac (A classic mac app targetting system 6 - macOS
>> 9, currently in development)
>>
>> Fragment identifier considerations: No fragment identifier syntax is
>> defined for the wmap format. Fragment identifiers are not applicable
>> to this media type.
>>
>> 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): N/A
>> 3. File extension(s): wmap
It looks like this file extension is already used for another 
application. If you can change this, that would be great. If not, not a 
big deal.
>> 4. Macintosh file type code: N/A
>> 5. Object Identifiers: N/A
>>
>> General Comments: The wmap format supports the following entities:
>>
>> - Components with positions and optional shapes
>> - Dependencies between components (lines and arrows)
>> - Textual notes at specific positions
>> - Stage boundaries for evolution axes
>> - Component groupings
>> - Inertia markers for components
>> - Evolution indicators showing component movement
>>
>> The format is designed to be both human-readable and machine-
>> parseable, enabling version control, diff tools, and other tooling.
>>
>> Person to contact for further information:
>>
>> 1. Name: Rubén Fabián Beltrán del Río Vara
>> 2. Email: [email protected]
>>
>> Intended usage: COMMON
>>
>> Author/Change controller: Rubén Fabián Beltrán del Río Vara <[email protected]>

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