TG Download Services - Relax content-type requirement for ATOM feed resources

[arbakker]

Change proposal description

I propose to relax the mime-type requirement TG Requirement 2 - TG for Download Services for ATOM feed resources to allow application/xml as well as application/atom+xml (currently the only allowed mime-type).

I previously opened an issue at the helpdesk-validator, but it was suggested to open an issue here.

Addressed TG

Technical Guidance for the implementation of INSPIRE Download Services

Location

TG Requirement 2 - Technical Guidance for the implementation of INSPIRE Download Services :

The relevant part of the ATOM RFC 4287:

There are no other parts in the ATOM RFC 4287 about the mime-type for feed resources.

The ATOM RFC 4287 is interpreted by the ETF validator as a requirement for using only application/atom+xml as mime-type for ATOM feed resources. However I would argue that the ATOM RFC 4287 does not set an explicit requirement for the used mime-type and would allow for using application/xml as mime-type for ATOM feed resources.

Issue faced

Mostly copy-paste from INSPIRE-MIF/helpdesk-validator#661 with some edits:

---

The problem I am facing with this requirement is that the mime-type application/atom+xml is not recognized as an XML format by most browsers. This is the case for at least Chromium based browsers (Google Chrome, MS Edge and more) and Firefox, which represents a significant usage share of web browsers in use currently. Bug reports on this issue have been open for years, so probably will not be fixed any time soon:

• Firefox - Opened 20 years ago
• Chromium - Opened 10 years ago

A consequence of browsers failing to recognize the mime-type application/atom+xml as an XML based format is that browsers do not render the ATOM feed with XML syntax highlighting. Which reduces the user experience of consuming the ATOM feeds directly in a web browser:

An additional consequence is that the browser XSLTProcessor API does not work as well. We use this feature to let the browser render the ATOM XML feeds into a user-friendly HTML output, see for instance Download Service van BRO Wandonderzoek. This works through including an XSL stylesheet in the ATOM feed:

<?xml-stylesheet href="https://service.pdok.nl/atom/style/style.xsl" type="text/xsl" media="screen"?>

This way we can direct users directly to our ATOM services, but this only works if the browser thinks it is dealing with a XML based resource. I am aware the ATOM protocol is mostly intended for machine-to-machine consumption, however I want to argue that facilitating human-to-machine consumption for ATOM services will lower the barrier to entry to these services. Therefore I am proposing to allow usage of application/xml mime-type for ATOM feed resources.

Also I wonder whether the ATOM RFC 4287 is normative on the usage of the application/atom+xml mime-type since it states:

An Atom Document, when serialized as XML 1.0, can be identified with
the following media type:

MIME media type name: application
MIME subtype name: atom+xml

If this is the case , namely application/atom+xml is not required per RFC, then the TG for Download Services does not need a change, then the issue lies with the helpdesk-validator team.

If this is not the case, namely application/atom+xml is required per RFC, then the TG for Download Services would need to explicitly allow for the usage of application/xml, considering it reflects current practices in publishing ATOM feeds and stimulates the usage of ATOM services.

Proposed solution

Explicitly allow for the usage of the following mime-types for ATOM feed resources:

• application/xml
• application/atom+xml

Provided the ATOM RFC does not already allow for this.

Pull request

None, awaiting feedback proposal.

Additional information

None.

Relevant legislation

None.

Impact on IR

No impact, considering it proposes a relaxation of a requirement.

Impact on INSPIRE validator

INSPIRE validator would need to be changed to also allow the mime-type application/xml for ATOM feed resources (besides the already allowed mime-type application/atom+xml.

Linked issue

INSPIRE-MIF/helpdesk-validator#661

Impact on INSPIRE XML schemas

None.

Impact on INSPIRE code lists

None.

Change proposer

anton.bakker[at]kadaster.nl

References

• Bug report Firefox - Opened 20 years ago
• Bug report Chromium - Opened 10 years ago
• ATOM RFC 4287
• Technical Guidance for the implementation of INSPIRE Download Services

[heidivanparys]

Also I wonder whether the ATOM RFC 4287 is normative on the usage of the application/atom+xml mime-type since it states:

An Atom Document, when serialized as XML 1.0, can be identified with
the following media type:
MIME media type name: application
MIME subtype name: atom+xml

If this is the case , namely application/atom+xml is not required per RFC, then the TG for Download Services does not need a change, then the issue lies with the helpdesk-validator team.

If this is not the case, namely application/atom+xml is required per RFC, then the TG for Download Services would need to explicitly allow for the usage of application/xml, considering it reflects current practices in publishing ATOM feeds and stimulates the usage of ATOM services.

application/atom+xml is not required per RFC:

[arbakker]

Yes, that was also my impression, good to have established that. I just double-checked my proposal and found that I missed the following relevant parts to the TG for Download Services and the ATOM RFC:

Wording in the ATOM RFC indicates that the link type attribute can differ from the actual media type returned for that resource.

Note that the type attribute does not override the actual media type returned with the representation.

If that is the case Requirement 7 can remain unchanged, with the provision that actual media type returned for ATOM Feed resources can also be application/atom+xml .

Or is not necessary for the TG for Download service to explicitly allow for this, because the TG in combination with RFC already implicitly allows this?

[fabiovinci]

What about requirements 15 and 42?
Do they need to be changed?

[heidivanparys]

A few more comments from my side:

Wording in the ATOM RFC indicates that the link type attribute can differ from the actual media type returned for that resource.

That indication can also been in the following text from RFC 4287:

 # Whatever a media type is, it contains at least one slash
atomMediaType = xsd:string { pattern = ".+/.+" }

Explicitly allow for the usage of the following mime-types for ATOM feed resources:

* `application/xml`

* `application/atom+xml`

Provided the ATOM RFC does not already allow for this.

Note that text/xml also is a valid media type for XML documents, see also RFC 7303 (highlighting is mine):

This specification standardizes three media types -- application/xml,
application/xml-external-parsed-entity, and application/xml-dtd --
for use in exchanging network entities that are related to the
Extensible Markup Language (XML) while defining text/xml and text/
xml-external-parsed-entity as aliases for the respective application/
types. This specification also standardizes the '+xml' suffix for
naming media types outside of these five types when those media types
represent XML MIME entities.

Regarding other impacted requirements:

What about requirements 15 and 42? Do they need to be changed?

There are more requirements related to 'type' attributes for links to XML-based documents that may be affected by the comments above.

Note that application/opensearchdescription+xml is not present in IANAs media type register. As far as I can see, it was originally defined in a document that is now expired, see also https://datatracker.ietf.org/doc/draft-ellermann-opensearch/.

Given the fact that this is not a media type present in the IANA register, and that

Link elements MAY have a type attribute, whose value MUST conform to the syntax of a MIME media type

perhaps those requirements should be updated as well (possibly in a new issue).

[sMorrone]

Subgroup meeting on 24.03.2022:
the Subgroup approved the proposal to allow for the usage of the following mime-types for ATOM feed resources:

• application/xml
• application/atom+xml
• text/xml
  modifying accordingly the TG Requirements 7, 15 and 42.
  A new issue will be opened to deal with modification of TG Requirements 6, 8, 40

[sMorrone]

During the joint MIG/MIG-T meeting held on 31/03-01/04/2022, the proposal was endorsed.
More details in the meeting minutes on the 69th MIG-T meeting page