From: kyle at drummondgroup.com (Kyle Meadors) Date: Mon Nov 17 09:37:47 2003 Subject: Registration of MIME media type Application/EDI-Tradacoms Message-ID: <001101c3ace6$12870540$60eb3444@nash01.tn.comcast.net> MIME media type name: Application MIME subtype name: IETF Tree - EDI-Tradacoms Required parameters: None Optional parameters: CHARSET, as defined for MIME Encoding considerations: May need BASE64 or QUOTED-PRINTABLE transfer encoding on transports not capable of handling 8 BIT text Security considerations: Refer to RFC 1767 Section 7 Interoperability considerations: None Published specification: Refer to RFC 1767 Applications which use this media type: EDI, EDIINT Additional information: Magic number(s): none File extension(s): none Macintosh File Type Code(s): none Person & email address to contact for further information: Name: Kyle Meadors Email: kyle@drummondgroup.com Intended usage: COMMON. UK EDI standard to support EDIINT AS2 in UK Author/Change controller: Drummond Group Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20031117/9bb37843/attachment.htm >From LMM@acm.org Wed Nov 19 03:29:09 2003 From: LMM at acm.org (Larry Masinter) Date: Wed Nov 19 03:30:00 2003 Subject: Registration of MIME media type Application/EDI-Tradacoms In-Reply-To: <001101c3ace6$12870540$60eb3444@nash01.tn.comcast.net> Message-ID: <007001c3ae44$e938aa80$c3432099@MasinterT40> This registration refers to RFC 1767. Now, RFC 1767 already contains 3 media type registrations, but does not mention "tradacoms". So it is difficult to tell what is actually meant by the registration as it is currently written. Also, since RFC 1767 is a standards track document, normally the "change controller" would be the IETF rather than a private individual/company. MIME media type name: Application MIME subtype name: IETF Tree - EDI-Tradacoms Required parameters: None Optional parameters: CHARSET, as defined for MIME Encoding considerations: May need BASE64 or QUOTED-PRINTABLE transfer encoding on transports not capable of handling 8 BIT text Security considerations: Refer to RFC 1767 Section 7 Interoperability considerations: None Published specification: Refer to RFC 1767 Applications which use this media type: EDI, EDIINT Additional information: Magic number(s): none File extension(s): none Macintosh File Type Code(s): none Person & email address to contact for further information: Name: Kyle Meadors Email: kyle@drummondgroup.com Intended usage: COMMON. UK EDI standard to support EDIINT AS2 in UK Author/Change controller: Drummond Group Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20031118/bfb34a25/attachment.htm >From gk@ninebynine.org Thu Nov 20 18:30:46 2003 From: gk at ninebynine.org (Graham Klyne) Date: Thu Nov 20 19:58:05 2003 Subject: application/rdf+xml Message-ID: <5.1.0.14.2.20031120171306.02597e58@127.0.0.1> Following review comments, the W3C RDFcore working group's draft for registering application/RDF+XML was updated some time ago, per [1]: [1] http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml-mediatype-03.txt (after a brief absence, this is draft is now back online) No further comments have been noted, either on , or on . The RDF specification has just completed its second W3C last-call, and is requested [3] for consideration for advancement to a Proposed Recommendation (W3C-speak for approximately draft standard). The specification documents are linked from [2]. [2] http://www.w3.org/2001/sw/RDFCore/#documents [3] http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Nov/0146.html Accordingly, I think it is appropriate that in the near future we request IESG consideration of this draft for RFC publication and registration of the Content Type. If there are any remaining issues, please let us know on . Thanks. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact From: kyle at drummondgroup.com (Kyle Meadors) Date: Tue Jan 3 16:22:37 2006 Subject: Registration of MIME media type Application/EDI-Tradacoms Message-ID: <001101c3ace6$12870540$60eb3444@nash01.tn.comcast.net> MIME media type name: Application MIME subtype name: IETF Tree - EDI-Tradacoms Required parameters: None Optional parameters: CHARSET, as defined for MIME Encoding considerations: May need BASE64 or QUOTED-PRINTABLE transfer encoding on transports not capable of handling 8 BIT text Security considerations: Refer to RFC 1767 Section 7 Interoperability considerations: None Published specification: Refer to RFC 1767 Applications which use this media type: EDI, EDIINT Additional information: Magic number(s): none File extension(s): none Macintosh File Type Code(s): none Person & email address to contact for further information: Name: Kyle Meadors Email: kyle@drummondgroup.com Intended usage: COMMON. UK EDI standard to support EDIINT AS2 in UK Author/Change controller: Drummond Group Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20031117/9bb37843/attachment.html >From LMM@acm.org Wed Nov 19 03:29:09 2003 From: LMM at acm.org (Larry Masinter) Date: Tue Jan 3 16:22:37 2006 Subject: Registration of MIME media type Application/EDI-Tradacoms In-Reply-To: <001101c3ace6$12870540$60eb3444@nash01.tn.comcast.net> Message-ID: <007001c3ae44$e938aa80$c3432099@MasinterT40> This registration refers to RFC 1767. Now, RFC 1767 already contains 3 media type registrations, but does not mention "tradacoms". So it is difficult to tell what is actually meant by the registration as it is currently written. Also, since RFC 1767 is a standards track document, normally the "change controller" would be the IETF rather than a private individual/company. MIME media type name: Application MIME subtype name: IETF Tree - EDI-Tradacoms Required parameters: None Optional parameters: CHARSET, as defined for MIME Encoding considerations: May need BASE64 or QUOTED-PRINTABLE transfer encoding on transports not capable of handling 8 BIT text Security considerations: Refer to RFC 1767 Section 7 Interoperability considerations: None Published specification: Refer to RFC 1767 Applications which use this media type: EDI, EDIINT Additional information: Magic number(s): none File extension(s): none Macintosh File Type Code(s): none Person & email address to contact for further information: Name: Kyle Meadors Email: kyle@drummondgroup.com Intended usage: COMMON. UK EDI standard to support EDIINT AS2 in UK Author/Change controller: Drummond Group Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20031118/bfb34a25/attachment.html >From gk@ninebynine.org Thu Nov 20 18:30:46 2003 From: gk at ninebynine.org (Graham Klyne) Date: Tue Jan 3 16:22:37 2006 Subject: application/rdf+xml Message-ID: <5.1.0.14.2.20031120171306.02597e58@127.0.0.1> Following review comments, the W3C RDFcore working group's draft for registering application/RDF+XML was updated some time ago, per [1]: [1] http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml-mediatype-03.txt (after a brief absence, this is draft is now back online) No further comments have been noted, either on , or on . The RDF specification has just completed its second W3C last-call, and is requested [3] for consideration for advancement to a Proposed Recommendation (W3C-speak for approximately draft standard). The specification documents are linked from [2]. [2] http://www.w3.org/2001/sw/RDFCore/#documents [3] http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Nov/0146.html Accordingly, I think it is appropriate that in the near future we request IESG consideration of this draft for RFC publication and registration of the Content Type. If there are any remaining issues, please let us know on . Thanks. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact