Subject: Registration of MIME media type Application/EDI-Tradacoms
From: kyle at drummondgroup.com (Kyle Meadors)
Date: Mon Nov 17 09:37:47 2003

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: [email-masked]

     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 [email-masked]  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: <[email-masked]>
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: [email-masked]
 
     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 [email-masked]  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: <[email-masked]>

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 <[email-masked]>, or on
<[email-masked]>.

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 
<mailto:[email-masked]>.

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: <[email-masked]>

     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: [email-masked]

     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 [email-masked]  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: <[email-masked]>
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: [email-masked]
 
     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 [email-masked]  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: <[email-masked]>

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 <[email-masked]>, or on
<[email-masked]>.

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 
<mailto:[email-masked]>.

Thanks.

#g

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact