[media-types] [IANA #1445348] application/vnd.3gpp.m cs-location-user-config+xml registration request

Hi Murray,

See inline for additional text suggested by the requester. Does this work? Should the line about prior implementations be included in the published registration template?

thanks,
Amanda

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.

> > 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
> >
> 
> 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.

> > 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
> >
> > Provisional registration? (standards tree only): No
> >
> > 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]
> >
> 
> -MSK

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