Proposal: Standardized storage location field in aux region

[hyiger]

Motivation

Physical inventory management is a natural use case for a writable smart-spool tag. For anyone running more than a handful of spools — multiple shelves, drybox units, material classes segregated across a workspace — knowing where a spool physically lives is as useful as knowing what's on it. Today that information lives in external spreadsheets, Notion pages, or app databases, which defeats the "data lives on the tag" principle the spec is built on. It also means peel-and-stick tag reuse loses location context the moment a spool moves.

Current workaround and why it falls short

Section 6.2.1 (general-purpose key range 65400–65534) lets users stash arbitrary fields under a general_purpose_range_user identifier. It works, but:

• Data is opaque to any reader that doesn't know the user's private schema, so a spool tagged by one tool surfaces no location info in another — exactly the fragmentation the spec is trying to avoid.
• The cooperative "delete-on-change" rule means any cross-tool write to the GP range wipes the data.
• Every inventory app, slicer, or printer that wants to support location has to agree on an unofficial convention, which is functionally a proprietary extension dressed up as an open one.
• The 8-character cap on general_purpose_range_user effectively limits who can claim the range to short handles/brand names.

Proposal

Add an optional storage-location field to the aux region. Aux is the right home because:

• It's user-writable, updated independently of manufacturer data.
• It legitimately changes over the spool's lifetime (shelf-to-shelf moves, reassignment after tag reuse).
• It's semantically similar to workgroup — user/org-scoped metadata rather than material fact.

Suggested shape:

- key: <next available>
  name: storage_location
  type: string
  max_length: 32   # open to discussion
  description:
    - Free-form identifier for the physical storage location of the container.
    - Examples: "Shelf B3", "Drybox 2 / Slot 4", "Garage-rack-left"
    - Semantics are user-defined; no hierarchy is enforced by the spec.

Alternative shape: two fields — storage_location_primary and storage_location_detail — to allow loose hierarchy (building/room vs. shelf/bin) without mandating structure. I'd lean toward a single free-form string and let applications layer structure on top, but open to either.

Open questions

1. Length budget. 32 chars covers typical shelf/bin labels but is tight for something like "Building A / Room 203 / Rack 4 / Bin 12". 64 may be safer at the cost of aux-region real estate.
2. Privacy. Storage labels can leak organizational info (rack IDs in a commercial facility, etc.). Probably not the spec's job to address, but worth flagging that write_protection semantics should clearly apply to this field.
3. Scope. Should this be material-class-agnostic (same field works for resin bottles in a cabinet, filament spools on a rack, etc.), or SLA-only/filament-only like last_stir_time? Seems general enough to leave uncategorized.
4. Relationship to workgroup. Worth clarifying that workgroup is about tag provenance/write-protection and storage_location is about physical placement — they're orthogonal.

Happy to submit a PR against data/aux_fields.yaml once there's consensus on naming and length.

[CZDanol]

Hello,
thank you for your good idea.

I have no objections to adding a field like this to the spec.

A few notes:

• You're very generous on the length budget. Typical whole tag size is 320 B. By the spec, the aux section is recommended to have at least 32 B - and that's what we currently allocate on the Prusament spools. To be honest, we weren't (wrongfully) expecting this much use of the aux region, so we were a bit conservative there. We should aim for addressing this better, but that is the current situation.
  • Down the line, not only because of the aux region restrictions, but also because of the whole tag size limitations, I'd suggest the field to have at most 8 characters.
• write_protection applies to the main region, so I don't think it fits here
• Definitely a material class agnostic field

Feel free to submit a PR :)