Opened 15 years ago

Closed 14 years ago

Last modified 14 years ago

#55 closed editorial (fixed)

Updating to RFC4288

Reported by: mnot@… Owned by: fielding@…
Priority: Milestone: 02
Component: non-specific Severity:
Keywords: Cc:

Description

The update from RFC2048 to RFC4288 requires minor modifications for the media type registrations for "message/http", "application/http" and "multipart/byteranges".

Change History (6)

comment:1 Changed 14 years ago by mnot@…

  • Component set to non-specific
  • Milestone set to unassigned

comment:2 Changed 14 years ago by fielding@…

  • Milestone changed from unassigned to 02
  • Owner set to fielding@…
  • Status changed from new to assigned

comment:3 Changed 14 years ago by julian.reschke@…

The modifications were done in [152], but it wouldn't hurt to review them (and maybe fill out the "Applications that use this media type:" field (see <​http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-01#appendix-A>).

comment:4 Changed 14 years ago by fielding@…

From [197]:

RFC4288 is not a normative ref; related to #55

comment:5 Changed 14 years ago by fielding@…

  • Resolution set to fixed
  • Status changed from assigned to closed

The templates look fine. I don't have a list of applications. The types are primarily used for archives of message traffic and some forms of protocol encapsulation.

I made the same changes to p5 for multipart/byteranges in [196]. Note that 4288 is not a normative dependency [197].

I don't think that there is anything more we need to do here, so i am closing the issue.

comment:6 Changed 14 years ago by julian.reschke@…

From [200]:

Note changes wrt to RFC4288, make reference to RFC4288 informative in Part 3, too; related to #55.

Note: See TracTickets for help on using tickets.