Registration of the text/red MIME Sub-Type
RFC 4102

Note: This ballot was opened for revision 05 and is now closed.

(Allison Mankin) Yes

(Brian Carpenter) (was Discuss) No Objection

Comment (2005-03-16)
No email
send info
Comments from Gen-ART review. I will clear the DISCUSS to NO-OB if the shepherd acknowledges taking these comments under consideration.

GEN-ART Review
Documents: draft-ietf-avt-text-red-05.txt

Trigger: IETF tele-chat, 17 March 2005
Reviewer: Elwyn Davies
AD: Alison Mankin
Review Date: 13 March 2005
Intended status: Proposed Standard

Summary: A trivial MIME type registration request.  I am not qualified to check
out all the parameter mappings but it seems ready to go, except for a couple of
nits (although one absolutely needs resolution) and some formatting glitches.

This should be ready to go except as follows:

Section 3:
3.   IANA Considerations

    One new MIME sub-type is to be registered, as described below:

       MIME media type name: text

       MIME subtype name: RED

-     Is the subtype name (RED) intended to be uppercase?  Every other mime
(sub)type I know uses lowercase and the document refers to text/red at
various points in the description.  I have been unable to determine whether
case is significant in subtype names from a brief reading of the MIME RFCs.

Section 4:
    -  The pt parameter is mapped to an a=3Dfmtp attribute by eliminating
       the parameter name (pt) and changing the commas to slashes.  For
       example, 'pt=3D"101,102"' maps to 'a=3Dfmtp:99 101/102', where =
'99' is
       the payload type of the redundancy frames.  Note that the single
       quote marks (') used in this example is not present in the
       actual message encoding, but is present here only for readability.
       The level of redundancy is shown by the number of elements in the
       payload type list.

-     I think this paragraph has got mangled by the text processing tools used (the
= may be spurious)... there are a couple of other places where lines have
overrun and an '=' appears at the end of the previous line.  Run idnits on
the text to be sure!  Maybe using 99 next to 101/102 doesn't make it terribly
clear that 99 is a placeholder.

Maybe this document should reference RFC2048 (MIME registrations) as well as

(Margaret Cullen) (was Discuss) No Objection

(Scott Hollenbeck) (was Discuss) No Objection

Comment (2005-03-17)
No email
send info
I know the text/red situation was discussed *somewhere* in the context of our MIME-type registration procedures, but I can't find any reference to a review request sent to the ietf-types list.  That really needs to happen before we can approve this document.

Allison and I talked about this by phone.  I'm OK with putting the document in the "Approved: Write-up Needed" state as long as a review request is sent and we have the opportunity to address whatever might come up.

I'm also confused by something I read in the introduction:

"RFC 2793 [7] specifies one usage of RFC 2198 and the text/red MIME
type for the transport of redundant text data."

Looking at RFC 2793 I see no mention of text/red.  It talks about text/t140.  Are they supposed to be the same thing?

Finally, in section 3 the change controller is identified as "IETF avt WG".  I thought we agreed that a working group name would be used only it were accompanied by words like "as designated by the IESG".

Please add appropriate RFC Editor notes to address these last two points.

(Russ Housley) No Objection

Comment (2005-03-14)
No email
send info
  Equal signs apper as '=3D', which makes examples a bit hard to read.

(David Kessens) No Objection

(Jon Peterson) No Objection

(Mark Townsley) No Objection

(Bert Wijnen) No Objection

(Alex Zinin) No Objection