[media-types] [IANA #1423130] text/vnd.wmap registrati on request

Hi Alexey,

They're OK with the change to application/vnd.wmap, but would prefer not to change the file extension. Because you described that issue as non-blocking, we'll go ahead with the registration.

thanks,
Amanda

On Thu Aug 21 11:23:38 2025, [email protected] wrote:
> 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]