[media-types] Re: [IANA #1445348] application/vnd.3g pp.mcs-location-user-config+xml registration request

Approved.

-MSK

On Wed, Mar 18, 2026 at 6:06 PM Amanda Baber via RT <
[email protected]> wrote:

> Hi Murray,
>
> Can you confirm that this final template is correct, and that it's OK to
> register now? The requester says "The changes will be reflected in the next
> update cycle, where the new version will be published mid~late June 2026. I
> confirmed that there won't be any 'newer things' for Release 19 and that
> the published specification will only make changes on the sentence in
> security consideration that reviewer has requested 3GPP to do so. Would
> this be enough to proceed forward?"
>
> Does this work, or does it need to wait for the June version of the spec
> (and/or need other changes)? Your email requesting the change to the
> "Mechanisms for privacy and integrity protection ..." sentence is included
> below.
>
> thanks,
> Amanda
>
> =====
>
> Name: Dongwook Kim
>
> Email: [email protected]
>
> Media type name: application
>
> Media subtype name: vnd.3gpp.mcs-location-user-config+xml
>
> Required parameters: N/A
>
> Optional parameters: "charset" the parameter has identical semantics to
> the charset parameter of the "application/xml" media type as specified in
> section 9.1 of IETF RFC 7303.
>
> Encoding considerations: binary
>
> Security considerations: Same as general security considerations for
> application/xml media type as specified in section 9.1 of IETF RFC 7303.
>
> The information transported in this media type does not include active or
> executable content.
>
> Mechanisms for privacy and integrity protection of these payloads can be
> provided by HTTPS (TLS) and/or typical protections available to XML
> payloads.
>
> This media type does not include provisions for directives that institute
> actions on a recipient's files or other resources.
>
> This media type does not include provisions for directives that institute
> actions that, while not directly harmful to the recipient, may result in
> disclosure of information that either facilitates a subsequent attack or
> else violates a recipient's privacy in any way.
>
> This media type does not employ compression.
>
> Interoperability considerations: Same as general interoperability
> considerations for application/xml media type as specified in section 9.1
> of IETF RFC 7303. Any unknown XML elements and any unknown XML attributes
> are to be ignored by recipient of the MIME body
>
> Published specification: 3GPP TS 24.484 "Mission Critical Services (MCS)
> configuration management; Protocol specification" version 19.4.0, available
> via
> https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3138
>
> Applications which use this media: Applications supporting the location
> user configuration data document as described in the published
> specification.
>
> Fragment identifier considerations: The handling in section 5 of IETF RFC
> 7303 applies.
>
> Restrictions on usage: None
>
> Additional information:
>
> 1. Deprecated alias names for this type: None
> 2. Magic number(s): None
> 3. File extension(s): None
> 4. Macintosh file type code: None
> 5. Object Identifiers: None
>
> Person to contact for further information:
>
> 1. Name: 3GPP Specifications Manager, Dongwook Kim
> 2. Email: [email protected]
>
> Intended usage: COMMON
>
> Author: 3GPP CT1 Working Group/[email protected]
>
> Change controller: Dongwook Kim / [email protected]
>
> On Mon Mar 16 17:44:10 2026, [email protected] wrote:
> > On Mon, Mar 9, 2026 at 4:25 PM Amanda Baber via RT <
> > [email protected]> wrote:
> >
> > > On Thu Mar 05 14:59:38 2026, [email protected] wrote:
> > > > On Mon, Mar 2, 2026 at 12:28 PM Amanda Baber via RT <
> > > > [email protected]> wrote:
> > > >
> > > > > Name: Dongwook Kim
> > > > >
> > > > > Email: [email protected]
> > > > >
> > > > > Media type name: application
> > > > >
> > > > > Media subtype name: vnd.3gpp.mcs-location-user-config+xml
> > > > >
> > > > > Required parameters: N/A
> > > > >
> > > > > Optional parameters: "charset" the parameter has identical
> semantics
> > > > > to
> > > > > the charset parameter of the "application/xml" media type as
> > > > > specified in
> > > > > section 9.1 of IETF RFC 7303.
> > > > >
> > > > > Encoding considerations: binary
> > > > >
> > > > > Security considerations: Same as general security considerations
> for
> > > > > application/xml media type as specified in section 9.1 of IETF RFC
> > > > > 7303.
> > > > >
> > > > > The information transported in this media type does not include
> > > > > active or
> > > > > executable content.
> > > > >
> > > > > Mechanisms for privacy and integrity protection of protocol
> > > > > parameters
> > > > > exist.
> > > > >
> > > >
> > > > Can we include a link to those?
> > >
> > > Privacy and integrity protection is solved by the transport layer by
> using
> > > HTTPS (TLS). The xml documents defined in TS 24.484 do all refer to OMA
> > > OMA-TS-XDM_Core-V2_1-20120403-A. In that document in clause 5.1.4 it is
> > > stated that TLS shall be supported according to RFC 2246.
> > >
> >
> > Then I would change that last sentence to:
> >
> > Mechanisms for privacy and integrity protection of these payloads can be
> > provided by HTTPS (TLS) and/or typical protections available to XML
> > payloads.
> >
> > > > Interoperability considerations: Same as general interoperability
> > > > > considerations for application/xml media type as specified in
> section
> > > > > 9.1
> > > > > of IETF RFC 7303. Any unknown XML elements and any unknown XML
> > > > > attributes
> > > > > are to be ignored by recipient of the MIME body
> > > >
> > > > Are there any prior implementations of this, or versions of its
> > > > specification, that might result in interoperability problems with
> > > > this one?
> > >
> > > There has not been any prior implementation of this.
> > >
> >
> > Thanks then, no additional changes needed.
> >
> > Approved if the above change is accepted.
> >
> > -MSK
>
>

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