Subject: Re: [ietf-types] Review requested for draft-ietf-sidr-rescerts-provisioning
From: Bjoern Hoehrmann <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Tue, 19 Jul 2011 18:16:52 +0200
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>

* Stewart Bryant wrote:
>Please can I request a review of application/rpki-updown
>as specified in draft-ietf-sidr-rescerts-provisioning

You've previously asked for a review of application/rpki-manifest and
application/rpki-roa. application/rpki-updown has the same problems I
already pointed out for the other types. Archives of comments are at:
http://www.ietf.org/mail-archive/web/ietf-types/current/maillist.html
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Date: Tue, 19 Jul 2011 15:54:37 +0100
From: Stewart Bryant <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [ietf-types] Review requested for draft-ietf-sidr-rescerts-provisioning
Reply-To: [email-masked]

Please can I request a review of application/rpki-updown
as specified in draft-ietf-sidr-rescerts-provisioning

======

5.1.  application/rpki-updown

    MIME media type name:  application
    MIME subtype name:  rpki-updown
    Required parameters:  None
    Optional parameters:  None
    Encoding considerations:  binary
    Security considerations:  Carries an RPKI Provisioning Protocol
       Message, as defined in this document.
    Interoperability considerations:  None
    Published specification:  This document
    Applications which use this media type:  HTTP [RFC5652]
    Additional information:
       Magic number(s):  None
       File extension(s):
       Macintosh File Type Code(s):
    Person & email address to contact for further information:  Geoff
       Huston <[email-masked]>
    Intended usage:  COMMON
    Author/Change controller:  Geoff Huston <[email-masked]>

=======

The document is currently on the IESG agenda for 25th August.

Thanks

Stewart

Date: Mon, 18 Jul 2011 15:41:13 -0400 (EDT)
From: Yves Lafon <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-types] Request for review: application/evd+xml media type

On Thu, 7 Jul 2011, Bjoern Hoehrmann wrote:

Thanks Bj=F6rn, here is the revised version of the media type definition:

Type name:

     application
Subtype name:

     evd+xml
Required parameters:

     none
Optional parameters:

     charset
     This parameter has identical semantics to the charset parameter of the=
=20
'application/xml' media type as specified in [RFC 3023].
Encoding considerations:

     Identical to those of 'application/xml' as described in [RFC 3023],=20
section 3.2, as applied to the EventDescriptions document.
Security considerations:

     Same as that of Section 10 in [RFC 3023].
Interoperability considerations:

     There are no known interoperability issues.
Published specification:

     Web Services Event Descriptions (this specification).
Applications which use this media type:

     No known applications currently use this media type.
Additional Information:

     Magic number(s):
     None.

     File extension(s):
     evd

     Fragment identifiers:
     An EventDescriptions fragment identifier references a particular Event=
=20
Type within an EventDescriptions document. The Event Type referenced is=20
the Event Type with the @id attribute whose normalized value (per=20
[xml:id]) equals that of the fragment identifier component.

     For example, if the EventDescriptions document from Example 4-1 were=
=20
located at "http://www.example.com/eventtypes/oceanwatch", the following=20
URI references the Event Type defined in lines 12-14:=20
http://www.example.com/eventtypes/oceanwatch#WindReportEvent.

     Macintosh file type code(s):
     No Macintosh file type code defined.
Person and email address to contact for further information:

     World Wide Wed Consortium <[email-masked]>
Intended usage:

     COMMON
Restrictions on usage:

     none.
Author/Change controller:

     The WS-EventDescriptions specification is a work product of the World=
=20
Wide Web Consortium's Web Service Resource Access Working Group. The W3C=20
has change control over these specifications.

> * Yves Lafon wrote:
>> Here is the registration document for the application/evd+xml media
>> type [1] by the W3C Web Services Resource Access Working Group [2].
>
> Has this been submitted before? It seems to me that the document has had
> Candidate Recommendation status for a couple of months, and W3C policy
> is to submit on entering Last Call, but there is nothing in my archives.
>
>> <<<
>> This appendix defines the 'application/evd+xml' media type which can be
>> used to describe EventDescription documents serialized as XML.
>>
>> MIME media type name:
>
> You are using an outdated template, the current template is in RFC 4288.
> The current templates structures and names some fields differently.
>
>> Security considerations:
>>
>>     none
>
> Well, at the very least you should point out that the ones in RFC 3023
> are likely to apply to implementations of the specific type here aswell.
>
>> Interoperability considerations:
>>
>>     There are non known interoperability issues.
>
> This looks like a typo.
>
>>     Fragment identifiers:
>>     An EventDescriptions fragment identifier references a particular Eve=
nt
>> Type within an EventDescriptions document. The Event Type referenced is
>> the Event Type with the @id attribute whos value equals that of the
>> fragment identifier component.
>
> In addition to the typo, this seems insufficient and I am not sure how
> compatible this is other types and what some people would like to change
> the existing specifications to. I note in particular that you don't say
> whether for instance "#x" would match id=3D' x ' (note the spaces); I als=
o
> note that you don't define the `id` attribute as ID attribute and don't
> say how this works for actual ID attributes or magic ones like xml:id.

This has been clarified, both in the media type definition and in the=20
schema associated.

>>     Base URI:
>>     As specified in [RFC 3023] section 6.
>
> The only reason to include this that I can think of is to mislead people
> into thinking RFC 3023 has anything to say on that even though it does
> not. If you don't want to say anything about Base URIs, then don't.

--=20
Baroula que barouleras, au ti=E9u toujou t'entourneras.

         ~~Yves

From: George Michaelson <[email-masked]>
Date: Fri, 15 Jul 2011 10:34:16 +1000
To: [email-masked]
Cc: [email-masked], "[email-masked]" <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Review requested for draft-ietf-sidr-repos-struct

As a co-author of the draft, can I get some quality time with people to =
work out the following

1) what is the minimum cost text change to the draft(s) which will =
satisfy the types registry people about language about the types issue

2) can we confirm a process that I, as a complete NEOPHYTE can use to =
request/registr the appropriate types and associated (meta) data about =
them

3) Can we please PLEASE avoid descent into some god-awful ontological =
discussion about the language being used herre, because this is a very =
late stage change in a process which we've tried very hard not to get =
side-tracked on.

In that context, I think its understood that we have 4 basic file =
objects being represented and shared in the repository system

	a) certificates, expressed as ASN.1 encoded binary data in files =
of nameform .cer
	b) CRLs in classic RFC5280 form in files of nameform .crl
	c) Manifests, ASN1 structures which complement CRLs, in files of =
nameform .mnf
	d) the first of an expected growing family of binary signed =
objects (CMS) specific in context to the needs of RPKI as a space of =
signed data. This object is the ROA, the Route Origin Attestation, in a =
file of nameform .roa

so we have .cer, .crl, .mnf, and .roa.=20

It is understood that drafts either in progress, or forseeable will be =
defining new types of signed objects reflecting extra data involved in =
s-BGP, or other activities. I have no role to play in that document =
process so I am not trying to pre-empt what they need, but arguably it =
will be additional file types, and therefore registered type-names.

Guys, can you just help me 'get over the hump' on this?

-George

On 20/06/2011, at 8:48 PM, Stewart Bryant wrote:

>=20
> Hi Paul
>=20
> Thank you for the suggestion.
>=20
> RTG will follow IETF best practice on this and to that end
> I will take the advice of my IESG colleges who are have
> more experience with ietf-types.
>=20
> - Stewart
>=20
>=20
> On 18/06/2011 21:37, Paul Libbrecht wrote:
>> Stewart,
>>=20
>> would you consider adding information in this registration request =
about names of the clipboard flavors?
>> My modest experience has shown me that importing files with =
certificates is rather a painful approach but drag-and-dropping or =
copy-and-pasting them worked much better.
>>=20
>> If you agree, I would suggest a Windows Flavor Name (e.g. "RPKI =
Manifest") and Macintosh Uniform Type Identifier (e.g. =
"public.rpki.manifest").
>>=20
>> paul
>>=20
>>=20
>> Le 17 juin 2011 =E0 15:14, Stewart Bryant a =E9crit :
>>=20
>>> draft-ietf-sidr-repos-struct
>>>=20
>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-repos-struct/
>>>=20
>>> Makes the following types request.
>>>=20
>>> Review comments by 1 July would be appreciated.
>>>=20
>>> Many thanks
>>>=20
>>> - Stewart
>>>=20
>>>=20
>>>=20
>>> 7.1.1.  application/rpki-manifest
>>>=20
>>>   MIME media type name:  application
>>>   MIME subtype name:  rpki-manifest
>>>   Required parameters:  None
>>>   Optional parameters:  None
>>>   Encoding considerations:  binary
>>>   Security considerations:  Carries a RPKI Manifest
>>>      [I-D.ietf-sidr-rpki-manifests].
>>>   Interoperability considerations:  None
>>>   Published specification:  This document
>>>   Applications which use this media type:  Any MIME-complaint =
transport
>>>   Additional information:
>>>      Magic number(s):  None
>>>      File extension(s):  .mft
>>>      Macintosh File Type Code(s):
>>>   Person&   email address to contact for further information:  Geoff
>>>      Huston<[email-masked]>
>>>   Intended usage:  COMMON
>>>   Author/Change controller:  Geoff Huston<[email-masked]>
>>>=20
>>> 7.1.2.  application/rpki-roa
>>>=20
>>>   MIME media type name:  application>
>>>   MIME subtype name:  rpki-roa
>>>   Required parameters:  None
>>>   Optional parameters:  None
>>>   Encoding considerations:  binary
>>>   Security considerations:  Carries a RPKI ROA
>>>      [I-D.ietf-sidr-roa-format]
>>>   Interoperability considerations:  None
>>>=20
>>> Huston, et al.          Expires December 10, 2011              [Page =
12]
>>> Internet-Draft        ResCert Repository Structure             June =
2011
>>>=20
>>>   Published specification:  This document
>>>   Applications which use this media type:  Any MIME-complaint =
transport
>>>   Additional information:
>>>      Magic number(s):  None
>>>      File extension(s):  .roa
>>>      Macintosh File Type Code(s):
>>>   Person&   email address to contact for further information:  Geoff
>>>      Huston<[email-masked]>
>>>   Intended usage:  COMMON
>>>   Author/Change controller:  Geoff Huston<[email-masked]>
>>>=20
>>> _______________________________________________
>>> ietf-types mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ietf-types
>>=20
>=20
>=20
> --=20
> For corporate legal information go to:
>=20
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>=20
>=20

Date: Thu, 14 Jul 2011 11:18:42 -0600
From: Peter Saint-Andre <[email-masked]>
To: Paul Libbrecht <[email-masked]>
OpenPGP: url=https://stpeter.im/stpeter.asc
Cc: [email-masked], [email-masked]
Subject: Re: [ietf-types] Review requested for draft-ietf-sidr-repos-struct

On 7/8/11 5:37 AM, Paul Libbrecht wrote:
> Hello Peter,
> 
> 
> Le 7 juil. 2011 Ã  19:28, Peter Saint-Andre a Ã©crit :
> 
>> On 6/18/11 2:37 PM, Paul Libbrecht wrote:
>>> would you consider adding information in this registration
>>> request about names of the clipboard flavors? My modest
>>> experience has shown me that importing files with certificates is
>>> rather a painful approach but drag-and-dropping or
>>> copy-and-pasting them worked much better.
>> 
>> Stewart can clarify the matter for us, but as far as I can see
>> RPKI certificates, manifest files, and route origin authorizations
>> aren't exactly the kind of things that would be imported and
>> exported by end users, since they are used for improved security of
>> BGP routing (not web sites, email messages, and the like)... 
>> http://tools.ietf.org/html/draft-ietf-sidr-arch-13 
>> http://tools.ietf.org/html/draft-ietf-sidr-rpki-manifests-13 
>> http://tools.ietf.org/html/draft-ietf-sidr-roa-format-12
>> 
>> Is there really a use case for copying such entities to the
>> clipboard of an end-user-oriented operating system such as Windows
>> of Macintosh?
> 
> I leave to you the probability, I still feel it's better to have a
> name agreed-upon even if not used of use now. Administrating such a
> router is a matter of "editing a config". My experience was with
> certificates for end user to go in and out of the certificate store
> on Mac.

Right, but these are not certificates for end users, they're RPKI (not
normal PKI) certificates for routers, plus associated manifest files and
route origin authorizations. I don't see the potential for much if any
user interaction with these beasts.

Authors?

>> If there is such a use case, then I have one further question...
>> 
>>> If you agree, I would suggest a Windows Flavor Name (e.g. "RPKI 
>>> Manifest") and Macintosh Uniform Type Identifier (e.g. 
>>> "public.rpki.manifest").
>> 
>> The following UTIs make sense to me (if we decide that we need
>> them).
>> 
>> For the application/rpki-manifest media type...
>> 
>> Macintosh file type code(s):  A uniform type identifier (UTI) of 
>> "public.rpki.manifest" is suggested.
> 
> You are mistaking Macintosh file type code(s) which is the pre-MacOSX
> Apple-owned registry of four-letter codes for file-types and
> clipboard types. This is all dead now as far as I know.

You're right, the Macintosh file type codes are old-style things:

http://support.apple.com/kb/TA25699?viewlocale=en_US

> What is not dead is that clipboard flavours are named using a simple
> string in Windows and uniform type identifier for MacOSX. I believe
> adding the two lines (per declaration) avoids attempts of naming
> things that are put in clipboard.
> 
>> For the application/rpki-roa media type...
>> 
>> Macintosh file type code(s):  A uniform type identifier (UTI) of 
>> "public.rpki.roa" is suggested.
>> 
>> However, it's not clear to me what you mean by a Windows Flavor
>> Name, and I don't see examples of that in any existing media type 
>> registrations at iana.org or in RFCs. There is one example in the
>> MathML spec:
>> 
>> http://www.w3.org/TR/2009/WD-MathML3-20090604/chapter6.html
>> 
>> Could you clarify where you think such a definition would go in an
>> IANA registration?
> 
> Correct, MathML is such an example. SVG as well: 
> http://www.w3.org/TR/SVG/mimereg.html and a few others (not many yet
> indeed).
> 
> I have unfortunately not been able to find a specification for the
> Windows flavor names. The closest URL at MSDN, as of today, is
> http://msdn.microsoft.com/en-us/library/ms649049.aspx

I'd prefer not to add things to IANA registrations for which there is no
precedent in the IETF, and no real documentation. Other folks on the
ietf-types list might have different opinions, but I've not seen any
discussion about Windows flavor names or Macintosh uniform type
identifier on this list over the last few years. Furthermore, I'm not
even sure where such information would go in the registration template
per RFC 4288. Perhaps in the interoperability considerations, although
my understanding has always been that those are supposed to cover known
problems with interop. As far as I know, there are no such issues with
the media types being registered.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Date: Mon, 11 Jul 2011 21:53:58 +0300
From: Roni Even <[email-masked]>
To: [email-masked]
Cc: [email-masked], "'Ali C. Begen \(abegen\)'" <[email-masked]>, [email-masked]
Subject: [ietf-types] Updating the registration of audio and video DV media subtype

This is a multi-part message in MIME format.

--Boundary_(ID_kUZGE9fzU915ZZLtux4GQQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi,

draft-ietf-payload-rfc3189bis-01 has passed Working Group Last Call in the
Payload Working Group.

Note that it an update to existing RFC3189 registrations
http://www.iana.org/assignments/rtp-parameters for DV media subtype.

The new registrations are in Section 3.1 of the document.
http://tools.ietf.org/html/draft-ietf-payload-rfc3189bis-01#section-3.1 

The information is also available below. 

I noticed that there is a need to change the change controller from " IETF
Audio/Video Transport working group delegated from the   IESG"  to " IETF
Payload  working group delegated from the   IESG"

 

Other comments on the registration are welcome.

Thanks

Roni Even 

Payload co-chair

 

3.1.1.  Media Type Registration for DV Video

 

Type name:  video

   Subtype name:  DV

   Required parameters:

      encode:  type of DV format.  Permissible values for encode are

         SD-VCR/525-60,

         SD-VCR/625-50,

         HD-VCR/1125-60,

         HD-VCR/1250-50,

         SDL-VCR/525-60,

         SDL-VCR/625-50,

         314M-25/525-60,

         314M-25/625-50,

         314M-50/525-60,

         314M-50/625-50,

         370M/1080-60i,

         370M/1080-50i,

         370M/720-60p,

         370M/720-50p,

         306M/525-60 (for backward compatibility),

         and 306M/625-50 (for backward compatibility).

   Optional parameters:

      audio:  whether the DV stream includes audio data or not.

         Permissible values for audio are bundled and none.  Defaults to
none.

   Encoding considerations:

         DV video can be transmitted with RTP as specified in RFCXXXX(This
document).  Other transport methods are not specified.

   Security considerations:

         See Section 4 of RFCXXXX (This document).

   Interoperability considerations:  NONE

   Public specification:

         IEC 61834 Standard

         SMPTE 314M

         SMPTE 370M

         RFCXXXX (This document)

         SMPTE 306M (for backward compatibility).

   Applications that use this media type:  Audio and video streaming and
conferencing tools.

   Additional information:  NONE

   Person & email address to contact for further information:

         Katsushi Kobayashi

         e-mail: [email-masked]

   Intended usage:  COMMON

   Restrictions on usage:  This media type depends on RTP framing, and hence
is only defined for transfer via RTP (RFC 3550).  Transfer within other
framing protocols is not defined at this time.

   Author:

         Katsushi Kobayashi

   Change controller:

         IETF Audio/Video Transport working group delegated from the

         IESG

 

3.1.2.  Media Type Registration for DV Audio

   Type name:  audio

   Subtype name:  DV

   Required parameters:

      encode:  type of DV format.  Permissible values for encode are

         SD-VCR/525-60,

         SD-VCR/625-50,

         HD-VCR/1125-60,

         HD-VCR/1250-50,

         SDL-VCR/525-60,

         SDL-VCR/625-50,

         314M-25/525-60,

         314M-25/625-50,

         314M-50/525-60,

         314M-50/625-50,

         370M/1080-60i,

         370M/1080-50i,

         370M/720-60p,

         370M/720-50p,

         306M/525-60 (for backward compatibility),

         and 306M/625-50 (for backward compatibility).

   Optional parameters:

      audio:  whether the DV stream includes audio data or not.

         Permissible values for audio are bundled and none.  Defaults to
none.

   Encoding considerations:

         DV audio can be transmitted with RTP as specified in RFCXXXX(This
document).  Other transport methods are not specified.

   Security considerations:

         See Section 4 of RFCXXXX (This document).

   Interoperability considerations:  NONE

   Published specification:

         IEC 61834 Standard

         SMPTE 314M

         SMPTE 370M

         RFCXXXX (This document)

         SMPTE 306M (for backward compatibility).

   Applications that use this media type:  Audio and video streaming and
conferencing tools.

   Additional information:  NONE

   Person & email address to contact for further information:

         Katsushi Kobayashi

         e-mail: [email-masked]

   Intended usage:  COMMON

   Restrictions on usage:  This media type depends on RTP framing, and hence
is only defined for transfer via RTP (RFC 3550).  Transfer      within other
framing protocols is not defined at this time.

 

   Author:

         Katsushi Kobayashi

   Change controller:

         IETF Audio/Video Transport working group delegated from the

         IESG

 

--Boundary_(ID_kUZGE9fzU915ZZLtux4GQQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>Hi,<o:p></o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoPlainText><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>draft-ietf-payload-rfc3189bis-01</span><span style='font-family:"Courier New"'> </span>has passed Working Group Last Call in the Payload Working Group.<o:p></o:p></p><p class=MsoPlainText><o:p>&nbsp;</o:p></p><p class=MsoPlainText>Note that it an update to existing RFC3189 registrations <a href="http://www.iana.org/assignments/rtp-parameters">http://www.iana.org/assignments/rtp-parameters</a> for DV media subtype.<o:p></o:p></p><p class=MsoPlainText><o:p>&nbsp;</o:p></p><p class=MsoPlainText>The new registrations are in Section 3.1 of the document. <a href="http://tools.ietf.org/html/draft-ietf-payload-rfc3189bis-01#section-3.1">http://tools.ietf.org/html/draft-ietf-payload-rfc3189bis-01#section-3.1</a> <o:p><!
 /o:p></p>
nbsp;</o:p></p><p class=MsoNormal>The information is also available below. <o:p></o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoPlainText><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>I noticed that there is a need to change the change controller from &quot;</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> IETF Audio/Video Transport working group delegated from the&nbsp;&nbsp; IESG&quot; </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>&nbsp;to &quot;</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> IETF Payload &nbsp;working group delegated from the&nbsp;&nbsp; IESG&quot;<o:p></o:p></span></p><p class=MsoPlainText><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>Other comments on the registration are welcome.<o:p></o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p cl!
 ass=MsoNo
><p class=MsoNormal>Roni Even <o:p></o:p></p><p class=MsoNormal>Payload co-chair<o:p></o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>3.1.1.&nbsp; Media Type Registration for DV Video<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; <o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>Type name:&nbsp; video<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Subtype name:&nbsp; DV<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font!
 -family:"
; Required parameters:<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; encode:&nbsp; type of DV format.&nbsp; Permissible values for encode are<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SD-VCR/525-60,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SD-VCR/625-50,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HD-VCR/1125-60,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HD-VCR/1250-50,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbs!
 p;&nbsp;&
DL-VCR/525-60,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SDL-VCR/625-50,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 314M-25/525-60,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 314M-25/625-50,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 314M-50/525-60,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 314M-50/625-50,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 370M/1080-60i,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbs!
 p;&nbsp;&
bsp;&nbsp; 370M/1080-50i,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 370M/720-60p,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 370M/720-50p,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 306M/525-60 (for backward compatibility),<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and 306M/625-50 (for backward compatibility).<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Optional parameters:<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><!
 p class=M
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; audio:&nbsp; whether the DV stream includes audio data or not.<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Permissible values for audio are bundled and none.&nbsp; Defaults to&nbsp; none.<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Encoding considerations:<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DV video can be transmitted with RTP as specified in RFCXXXX(This document).&nbsp; Other transport methods are not specified.<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</!
 o:p></spa
xt><span style='font-family:"Courier New"'>&nbsp;&nbsp; Security considerations:<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; See Section 4 of RFCXXXX (This document).<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Interoperability considerations:&nbsp; NONE<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Public specification:<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb!
 sp;&nbsp;
FR style='font-family:"Courier New"'>IEC 61834 Standard<o:p></o:p></span></p><p class=MsoPlainText><span lang=FR style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SMPTE 314M<o:p></o:p></span></p><p class=MsoPlainText><span lang=FR style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SMPTE 370M<o:p></o:p></span></p><p class=MsoPlainText><span lang=FR style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style='font-family:"Courier New"'>RFCXXXX (This document)<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SMPTE 306M (for backward compatibility).<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Applications that use this media type:&nbsp; Audio and video !
 streaming
o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Additional information:&nbsp; NONE<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Person &amp; email address to contact for further information:<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Katsushi Kobayashi<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; e-mail: [email-masked]<o:p></o:p></span></p><p class!
 =MsoPlain
mily:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Intended usage:&nbsp; COMMON<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Restrictions on usage:&nbsp; This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550).&nbsp; Transfer within other framing protocols is not defined at this time.<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Author:<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Katsushi Kobayashi<o:p></o:p></s!
 pan></p><
n style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Change controller:<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IETF Audio/Video Transport working group delegated from the<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IESG<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>3.1.2.&nbsp; Media Type Registration for DV Audio<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p!
 ></span><
<span style='font-family:"Courier New"'>&nbsp;&nbsp; Type name:&nbsp; audio<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Subtype name:&nbsp; DV<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Required parameters:<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; encode:&nbsp; type of DV format.&nbsp; Permissible values for encode are<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SD-VCR/525-60,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Cour!
 ier New"'
&nbsp;&nbsp;&nbsp;&nbsp; SD-VCR/625-50,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HD-VCR/1125-60,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HD-VCR/1250-50,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SDL-VCR/525-60,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SDL-VCR/625-50,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 314M-25/525-60,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 314M-25/625-50,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-!
 family:"C
&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;314M-50/525-60,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 314M-50/625-50,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 370M/1080-60i,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 370M/1080-50i,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 370M/720-60p,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 370M/720-50p,<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 306M/525-60 (for backward compatibility),<o:p></o:p></span></p><p clas!
 s=MsoPlai
amily:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and 306M/625-50 (for backward compatibility).<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Optional parameters:<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; audio:&nbsp; whether the DV stream includes audio data or not.<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Permissible values for audio are bundled and none.&nbsp; Defaults to none.<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Encodi!
 ng consid
n></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DV audio can be transmitted with RTP as specified in RFCXXXX(This document).&nbsp; Other transport methods are not specified.<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Security considerations:<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; See Section 4 of RFCXXXX (This document).<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&n!
 bsp; Inte
ns:&nbsp; NONE<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Published specification:<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IEC 61834 Standard<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;SMPTE 314M<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span lang=FR style='font-family:"Courier New"'>SMPTE 370M<o:p></o:p></span></p><p class=MsoPlainText><span lang=FR style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RFCXXXX (This document)<o:p></o:p></span>!
 </p><p cl
ng=FR style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style='font-family:"Courier New"'>SMPTE 306M (for backward compatibility).<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Applications that use this media type:&nbsp; Audio and video streaming and conferencing tools.<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Additional information:&nbsp; NONE<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Person &amp; email address to contact for further information:<o:p></o:p></span></p><p class=MsoPlainText><span style='font-!
 family:"C
/o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Katsushi Kobayashi<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; e-mail: [email-masked]<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Intended usage:&nbsp; COMMON<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Restrictions on usage:&nbsp; This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550).&nbsp; Transfer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; within other framing!
  protocol
time.<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Author:<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Katsushi Kobayashi<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp; Change controller:<o:p></o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IETF Audio/Video Transport work!
 ing group
/o:p></span></p><p class=MsoPlainText><span style='font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IESG<o:p></o:p></span></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p></div></body></html>

--Boundary_(ID_kUZGE9fzU915ZZLtux4GQQ)--

From: Frank Ellermann <[email-masked]>
Date: Fri, 8 Jul 2011 22:23:34 +0200
To: Yves Lafon <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-types] Request for review: application/evd+xml media type

On 7 July 2011 15:47, Yves Lafon <[email-masked]> wrote:

> Published specification:
> =A0 =A0Web Services Event Descriptions (this specification).

Just in case an obvious point, this would appear "as is"
(out of a "this" context) in the registry, better use an
URI when you fix Bj=F6rn's nits.

-Frank

From: Paul Libbrecht <[email-masked]>
Date: Fri, 8 Jul 2011 13:37:37 +0200
To: Peter Saint-Andre <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [ietf-types] Review requested for draft-ietf-sidr-repos-struct

Hello Peter,

Le 7 juil. 2011 =E0 19:28, Peter Saint-Andre a =E9crit :

> On 6/18/11 2:37 PM, Paul Libbrecht wrote:
>> would you consider adding information in this registration request
>> about names of the clipboard flavors? My modest experience has shown
>> me that importing files with certificates is rather a painful
>> approach but drag-and-dropping or copy-and-pasting them worked much
>> better.
>=20
> Stewart can clarify the matter for us, but as far as I can see RPKI
> certificates, manifest files, and route origin authorizations aren't
> exactly the kind of things that would be imported and exported by end
> users, since they are used for improved security of BGP routing (not =
web
> sites, email messages, and the like)...
> http://tools.ietf.org/html/draft-ietf-sidr-arch-13
> http://tools.ietf.org/html/draft-ietf-sidr-rpki-manifests-13
> http://tools.ietf.org/html/draft-ietf-sidr-roa-format-12
>=20
> Is there really a use case for copying such entities to the clipboard =
of
> an end-user-oriented operating system such as Windows of Macintosh?

I leave to you the probability, I still feel it's better to have a name =
agreed-upon even if not used of use now.
Administrating such a router is a matter of "editing a config".
My experience was with certificates for end user to go in and out of the =
certificate store on Mac.

> If there is such a use case, then I have one further question...
>=20
>> If you agree, I would suggest a Windows Flavor Name (e.g. "RPKI
>> Manifest") and Macintosh Uniform Type Identifier (e.g.
>> "public.rpki.manifest").
>=20
> The following UTIs make sense to me (if we decide that we need them).
>=20
> For the application/rpki-manifest media type...
>=20
>   Macintosh file type code(s):  A uniform type identifier (UTI) of
>      "public.rpki.manifest" is suggested.

You are mistaking Macintosh file type code(s) which is the pre-MacOSX =
Apple-owned registry of four-letter codes for file-types and clipboard =
types. This is all dead now as far as I know.

What is not dead is that clipboard flavours are named using a simple =
string in Windows and uniform type identifier for MacOSX.
I believe adding the two lines (per declaration) avoids attempts of =
naming things that are put in clipboard.

> For the application/rpki-roa media type...
>=20
>   Macintosh file type code(s):  A uniform type identifier (UTI) of
>      "public.rpki.roa" is suggested.
>=20
> However, it's not clear to me what you mean by a Windows Flavor Name,
> and I don't see examples of that in any existing media type
> registrations at iana.org or in RFCs. There is one example in the =
MathML
> spec:
>=20
> http://www.w3.org/TR/2009/WD-MathML3-20090604/chapter6.html
>=20
> Could you clarify where you think such a definition would go in an =
IANA
> registration?

Correct, MathML is such an example.
SVG as well:
	http://www.w3.org/TR/SVG/mimereg.html
and a few others (not many yet indeed).

I have unfortunately not been able to find a specification for the =
Windows flavor names.=20
The closest URL at MSDN, as of today, is =
http://msdn.microsoft.com/en-us/library/ms649049.aspx=20

hope it helps.

paul=

Date: Fri, 08 Jul 2011 10:17:20 +0100
From: Stewart Bryant <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [ietf-types] Review requested for draft-ietf-sidr-repos-struct
Reply-To: [email-masked]

On 07/07/2011 18:28, Peter Saint-Andre wrote:
> Hi Paul, Stewart asked me to take a look at this issue...
>
> On 6/18/11 2:37 PM, Paul Libbrecht wrote:
>> Stewart,
>>
>> would you consider adding information in this registration request
>> about names of the clipboard flavors? My modest experience has shown
>> me that importing files with certificates is rather a painful
>> approach but drag-and-dropping or copy-and-pasting them worked much
>> better.
> Stewart can clarify the matter for us, but as far as I can see RPKI
> certificates, manifest files, and route origin authorizations aren't
> exactly the kind of things that would be imported and exported by end
> users, since they are used for improved security of BGP routing (not web
> sites, email messages, and the like)...
>
> http://tools.ietf.org/html/draft-ietf-sidr-arch-13
> http://tools.ietf.org/html/draft-ietf-sidr-rpki-manifests-13
> http://tools.ietf.org/html/draft-ietf-sidr-roa-format-12
>
> Is there really a use case for copying such entities to the clipboard of
> an end-user-oriented operating system such as Windows of Macintosh?

Well, I can imagine that in configuring a router in an ops center
cut/paste might be the method used.

I will leave the next to the authors.

Stewart
>
> If there is such a use case, then I have one further question...
>
>> If you agree, I would suggest a Windows Flavor Name (e.g. "RPKI
>> Manifest") and Macintosh Uniform Type Identifier (e.g.
>> "public.rpki.manifest").
> The following UTIs make sense to me (if we decide that we need them).
>
> For the application/rpki-manifest media type...
>
>     Macintosh file type code(s):  A uniform type identifier (UTI) of
>        "public.rpki.manifest" is suggested.
>
> For the application/rpki-roa media type...
>
>     Macintosh file type code(s):  A uniform type identifier (UTI) of
>        "public.rpki.roa" is suggested.
>
> However, it's not clear to me what you mean by a Windows Flavor Name,
> and I don't see examples of that in any existing media type
> registrations at iana.org or in RFCs. There is one example in the MathML
> spec:
>
> http://www.w3.org/TR/2009/WD-MathML3-20090604/chapter6.html
>
> Could you clarify where you think such a definition would go in an IANA
> registration?
>
> Thanks!
>
> Peter
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

From: Cullen Jennings <[email-masked]>
Date: Thu, 7 Jul 2011 20:04:48 -0600
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked], P2PSIP Mailing List <[email-masked]>
Subject: Re: [ietf-types] Registration of media type application/p2p-overlay+xml

On Jul 7, 2011, at 6:56 PM, Bjoern Hoehrmann wrote:

> * Cullen Jennings wrote:
> >We are mandating UTF-8 as the charset which gives us the benefits =
would
> >hope. We don't want to have multiple charsets supported as we have =
noted
> >this reduces interoperability when some implementations don't bother =
to
> >implement charsets other than UTF-8. It's arbitrary choice that
> >increases what you need to implement and test, reduces =
interoperability,
> >and provides not benefits to the end user beyond what they get with
> >UTF-8.
>=20
> I am thinking about this situation:
>=20
>   Content-Type: application/p2p-overlay+xml;charset=3Diso-8859-2
>=20
>   <?xml version=3D'1.0' encoding=3D'iso-8859-15'?>
>   ...
>=20
> and I am comparing it to this situation:
>=20
>   Content-Type: application/xml;charset=3Diso-8859-2
>=20
>   <?xml version=3D'1.0' encoding=3D'iso-8859-15'?>
>   ...
>=20
> The question is how implementations determine the encoding. I am =
saying
> there should be no difference between the two cases, so long as you =
use
> the `+xml` convention and an `application` type. That would require to
> either define a charset parameter, or remove the `+xml`. I do not care
> whether some `application/p2p-overlay+xml` implementations only =
support
> UTF-8, I just do not want this to be the same as:
>=20
>   Content-Type: application/p2p-overlay+xml;dkjfashdkf=3Dsdjhfaskdjfhas
>=20
>   <?xml version=3D'1.0' encoding=3D'iso-8859-15'?>
>   ...
>=20
> namely, an unrecognized parameter with an unrecognized value.

We do use this in protocols that don't have a Content-Type header or =
place to cary the chartset but I see your point with not wanting to =
treat charset as an unknown parameter. Do you see any problem with =
saying, if there is a chartset parameter, it MUST be UTF-8?

From: Bjoern Hoehrmann <[email-masked]>
To: Cullen Jennings <[email-masked]>
Date: Fri, 08 Jul 2011 02:56:09 +0200
Cc: [email-masked], P2PSIP Mailing List <[email-masked]>
Subject: Re: [ietf-types] Registration of media type application/p2p-overlay+xml

* Cullen Jennings wrote:
>We are mandating UTF-8 as the charset which gives us the benefits would
>hope. We don't want to have multiple charsets supported as we have noted
>this reduces interoperability when some implementations don't bother to
>implement charsets other than UTF-8. It's arbitrary choice that
>increases what you need to implement and test, reduces interoperability,
>and provides not benefits to the end user beyond what they get with
>UTF-8. 

I am thinking about this situation:

  Content-Type: application/p2p-overlay+xml;charset=iso-8859-2

  <?xml version='1.0' encoding='iso-8859-15'?>
  ...

and I am comparing it to this situation:

  Content-Type: application/xml;charset=iso-8859-2

  <?xml version='1.0' encoding='iso-8859-15'?>
  ...

The question is how implementations determine the encoding. I am saying
there should be no difference between the two cases, so long as you use
the `+xml` convention and an `application` type. That would require to
either define a charset parameter, or remove the `+xml`. I do not care
whether some `application/p2p-overlay+xml` implementations only support
UTF-8, I just do not want this to be the same as:

  Content-Type: application/p2p-overlay+xml;dkjfashdkf=sdjhfaskdjfhas

  <?xml version='1.0' encoding='iso-8859-15'?>
  ...

namely, an unrecognized parameter with an unrecognized value.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From: Cullen Jennings <[email-masked]>
Date: Thu, 7 Jul 2011 18:22:47 -0600
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked], P2PSIP Mailing List <[email-masked]>
Subject: Re: [ietf-types] Registration of media type application/p2p-overlay+xml

On May 28, 2011, at 3:16 AM, Bjoern Hoehrmann wrote:

> * Cullen Jennings wrote:
> >   To:  [email-masked]
> >
> >   Subject:  Registration of media type application/p2p-overlay+xml
>=20
> There is no reason to include this part in the specification.

fixed - thanks
=20
>=20
> >   Type name:  application
> >
> >   Subtype name:  p2p-overlay+xml
> >
> >   Required parameters:  none
> >
> >   Optional parameters:  none
>=20
> Why are you using the +xml convention but do not specify the type in a
> manner consistent with application/xml?

I may have missed what part of 3023 part we violate but I read it and =
could not see anything. Clearly the desire was to support UTF-8 which we =
do.=20

> Without a very good reason I'd
> think you should either add the "charset" parameter

We are mandating UTF-8 as the charset which gives us the benefits would =
hope. We don't want to have multiple charsets supported as we have noted =
this reduces interoperability when some implementations don't bother to =
implement charsets other than UTF-8. It's arbitrary choice that =
increases what you need to implement and test, reduces interoperability, =
and provides not benefits to the end user beyond what they get with =
UTF-8.=20

> or drop the "+xml".

It is xml so it seems like it is useful to use the +xml convention so =
that systems that process that can use it.=20

>=20
> >   Encoding considerations:  Must be binary encoded.  The contents =
MUST
> >   be valid XML compliant with the relax NG grammar specified in RFC-
> >   AAAA and use the UTF-8[RFC3629] character encoding.
>=20
> This should either just say "binary" or just reference RFC 3023 as RFC
> 3023 suggests.

Ok - removed this and moved it to additional info as it seems like =
useful information.=20

>=20
> >   Interoperability considerations:  Same as application/xml as =
defined
> >   in [RFC3023].
>=20
> If there are no known interoperability issues beyond those of the type
> application/xml, that is what you should say; the considerations here
> are certainly not the same.
> --
> Bj=F6rn H=F6hrmann =B7 mailto:[email-masked] =B7 =
http://bjoern.hoehrmann.de
> Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 =
http://www.bjoernsworld.de
> 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 =
http://www.websitedev.de/
>=20

Date: Thu, 07 Jul 2011 11:28:57 -0600
From: Peter Saint-Andre <[email-masked]>
To: Paul Libbrecht <[email-masked]>
OpenPGP: url=https://stpeter.im/stpeter.asc
Cc: [email-masked], [email-masked]
Subject: Re: [ietf-types] Review requested for draft-ietf-sidr-repos-struct

Hi Paul, Stewart asked me to take a look at this issue...

On 6/18/11 2:37 PM, Paul Libbrecht wrote:
> Stewart,
> 
> would you consider adding information in this registration request
> about names of the clipboard flavors? My modest experience has shown
> me that importing files with certificates is rather a painful
> approach but drag-and-dropping or copy-and-pasting them worked much
> better.

Stewart can clarify the matter for us, but as far as I can see RPKI
certificates, manifest files, and route origin authorizations aren't
exactly the kind of things that would be imported and exported by end
users, since they are used for improved security of BGP routing (not web
sites, email messages, and the like)...

http://tools.ietf.org/html/draft-ietf-sidr-arch-13
http://tools.ietf.org/html/draft-ietf-sidr-rpki-manifests-13
http://tools.ietf.org/html/draft-ietf-sidr-roa-format-12

Is there really a use case for copying such entities to the clipboard of
an end-user-oriented operating system such as Windows of Macintosh?

If there is such a use case, then I have one further question...

> If you agree, I would suggest a Windows Flavor Name (e.g. "RPKI
> Manifest") and Macintosh Uniform Type Identifier (e.g.
> "public.rpki.manifest").

The following UTIs make sense to me (if we decide that we need them).

For the application/rpki-manifest media type...

   Macintosh file type code(s):  A uniform type identifier (UTI) of
      "public.rpki.manifest" is suggested.

For the application/rpki-roa media type...

   Macintosh file type code(s):  A uniform type identifier (UTI) of
      "public.rpki.roa" is suggested.

However, it's not clear to me what you mean by a Windows Flavor Name,
and I don't see examples of that in any existing media type
registrations at iana.org or in RFCs. There is one example in the MathML
spec:

http://www.w3.org/TR/2009/WD-MathML3-20090604/chapter6.html

Could you clarify where you think such a definition would go in an IANA
registration?

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Date: Thu, 7 Jul 2011 11:22:06 -0400 (EDT)
From: Yves Lafon <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked], Bob Freund <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-types] Request for review: application/evd+xml media type

On Thu, 7 Jul 2011, Bjoern Hoehrmann wrote:

> * Yves Lafon wrote:
>> Here is the registration document for the application/evd+xml media
>> type [1] by the W3C Web Services Resource Access Working Group [2].
>
> Has this been submitted before? It seems to me that the document has had
> Candidate Recommendation status for a couple of months, and W3C policy
> is to submit on entering Last Call, but there is nothing in my archives.

It hasn't, unfortunately. A missed step that we are trying to recover=20
from.

>> <<<
>> This appendix defines the 'application/evd+xml' media type which can be
>> used to describe EventDescription documents serialized as XML.
>>
>> MIME media type name:
>
> You are using an outdated template, the current template is in RFC 4288.
> The current templates structures and names some fields differently.
>
>> Security considerations:
>>
>>     none
>
> Well, at the very least you should point out that the ones in RFC 3023
> are likely to apply to implementations of the specific type here aswell.
>
>> Interoperability considerations:
>>
>>     There are non known interoperability issues.
>
> This looks like a typo.
>
>>     Fragment identifiers:
>>     An EventDescriptions fragment identifier references a particular Eve=
nt
>> Type within an EventDescriptions document. The Event Type referenced is
>> the Event Type with the @id attribute whos value equals that of the
>> fragment identifier component.
>
> In addition to the typo, this seems insufficient and I am not sure how
> compatible this is other types and what some people would like to change
> the existing specifications to. I note in particular that you don't say
> whether for instance "#x" would match id=3D' x ' (note the spaces); I als=
o
> note that you don't define the `id` attribute as ID attribute and don't
> say how this works for actual ID attributes or magic ones like xml:id.
>
>>     Base URI:
>>     As specified in [RFC 3023] section 6.
>
> The only reason to include this that I can think of is to mislead people
> into thinking RFC 3023 has anything to say on that even though it does
> not. If you don't want to say anything about Base URIs, then don't.
>

--=20
Baroula que barouleras, au ti=E9u toujou t'entourneras.

         ~~Yves

From: Bjoern Hoehrmann <[email-masked]>
To: Yves Lafon <[email-masked]>
Date: Thu, 07 Jul 2011 17:13:32 +0200
Cc: [email-masked], Bob Freund <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-types] Request for review: application/evd+xml media type

* Yves Lafon wrote:
>Here is the registration document for the application/evd+xml media 
>type [1] by the W3C Web Services Resource Access Working Group [2].

Has this been submitted before? It seems to me that the document has had
Candidate Recommendation status for a couple of months, and W3C policy
is to submit on entering Last Call, but there is nothing in my archives.

><<<
>This appendix defines the 'application/evd+xml' media type which can be 
>used to describe EventDescription documents serialized as XML.
>
>MIME media type name:

You are using an outdated template, the current template is in RFC 4288.
The current templates structures and names some fields differently.

>Security considerations:
>
>     none

Well, at the very least you should point out that the ones in RFC 3023
are likely to apply to implementations of the specific type here aswell.

>Interoperability considerations:
>
>     There are non known interoperability issues.

This looks like a typo.

>     Fragment identifiers:
>     An EventDescriptions fragment identifier references a particular Event 
>Type within an EventDescriptions document. The Event Type referenced is 
>the Event Type with the @id attribute whos value equals that of the 
>fragment identifier component.

In addition to the typo, this seems insufficient and I am not sure how
compatible this is other types and what some people would like to change
the existing specifications to. I note in particular that you don't say
whether for instance "#x" would match id=' x ' (note the spaces); I also
note that you don't define the `id` attribute as ID attribute and don't
say how this works for actual ID attributes or magic ones like xml:id.

>     Base URI:
>     As specified in [RFC 3023] section 6.

The only reason to include this that I can think of is to mislead people
into thinking RFC 3023 has anything to say on that even though it does
not. If you don't want to say anything about Base URIs, then don't.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Date: Thu, 7 Jul 2011 09:47:49 -0400 (EDT)
From: Yves Lafon <[email-masked]>
To: [email-masked]
Cc: [email-masked], Bob Freund <[email-masked]>, [email-masked]
Subject: [ietf-types] Request for review: application/evd+xml media type

All,
Here is the registration document for the application/evd+xml media=20
type [1] by the W3C Web Services Resource Access Working Group [2].
Cheers,

<<<
This appendix defines the 'application/evd+xml' media type which can be=20
used to describe EventDescription documents serialized as XML.

MIME media type name:

     application
MIME subtype name:

     evd+xml
Required parameters:

     none
Optional parameters:

     charset
     This parameter has identical semantics to the charset parameter of the=
=20
'application/xml' media type as specified in [RFC 3023].
Encoding considerations:

     Identical to those of 'application/xml' as described in [RFC 3023],=20
section 3.2, as applied to the EventDescriptions document.
Security considerations:

     none
Interoperability considerations:

     There are non known interoperability issues.
Published specification:

     Web Services Event Descriptions (this specification).
Applications which use this media type:

     No known applications currently use this media type.
Additional Information:

     File extension:
     evd

     Fragment identifiers:
     An EventDescriptions fragment identifier references a particular Event=
=20
Type within an EventDescriptions document. The Event Type referenced is=20
the Event Type with the @id attribute whos value equals that of the=20
fragment identifier component.

     For example, if the EventDescriptions document from Example 4-1 were=
=20
located at "http://www.example.com/eventtypes/oceanwatch", the following=20
URI references the Event Type defined in lines 12-14:=20
http://www.example.com/eventtypes/oceanwatch#WindReportEvent.

     Base URI:
     As specified in [RFC 3023] section 6.
Person and email address to contact for further information:

     World Wide Wed Consortium <[email-masked]>
Intended usage:

     COMMON
Author/Change controller:

     The WS-EventDescriptions specification is a work product of the World=
=20
Wide Web Consortium's Web Service Resource Access Working Group. The W3C=20
has change control over these specifications.

>>>

[1] http://www.w3.org/TR/2011/CR-ws-event-descriptions-20110428/#EVD_MIME
[2] http://www.w3.org/2002/ws/ra/

--=20
Baroula que barouleras, au ti=E9u toujou t'entourneras.

         ~~Yves

From: Bjoern Hoehrmann <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Date: Mon, 04 Jul 2011 01:24:41 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] outdated template (was: Re: Review requested for draft-ietf-sidr-repos-struct)

* Peter Saint-Andre wrote:
>Bjoern, I notice that many of your reviews start with "this uses an
>outdated template". Do we need to update pointers somewhere so that
>people know which template to use?

There are a number of things that are rather repetitive, but if we re-
moved all of them, I would not offer any feedback at all, and going by
the archives, nobody else would. Knowing that someone actually looked
at some proposal is rather important for people wishing to register a
type, and I assume that is true for the IESG aswell, so I do not mind
saying the same things again and again all that much.

I would rather look at this from the perspective of people who wish to
register a type. What one should put in the "Applications that use this
media type" field is rather unclear, I don't really know anything about
"Macintosh file type code(s)", for almost all types I might know I have
no idea what the Windows Clipboard type might be, I think all text and
+xml types should have a charset parameter... those are things I'd like
to not talk about for individual registrations, from either perspective.

More broadly I do not think the "Encoding considerations" is useful as
"7bit" is no longer meaningful to most people and the difference between
"8bit" and "binary" is lost to most people (including myself going by my
past registration efforts), I don't think anybody expects that they can
contact the "Person & email address to contact for further information"
and actually get useful information, and decent Security considerations
are hard to come by to say the least.

So in terms of what we can improve, whether you say "Type name" or "MIME
Type name" or whatever the old field was, that's almost irrelevant. I'd
think I personally, primarily, care about going from a name to something
that offers more information on the format, and that being easy for most
of the type names (possible for most types). I don't really care who
authored the template or if the intended usage is COMMON or LIMITED USE.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Date: Fri, 01 Jul 2011 17:12:48 +0200
From: Jesse Alama <[email-masked]>
To: Paul Libbrecht <[email-masked]>
Cc: Adam Naumowicz <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] request for review: text/mizar

Paul Libbrecht wrote:

> If you say ASCII then I would suggest to keep ascii.

That is, you recommend that I specify a 7-bit encoding for the proposed
media type?

> Is the CRLF requirement also a requirement?

I'm not sure I understand what you're asking.

> The reason I asked about charset is that the media-type parameter
> charset is the cause of numerous communication around here,
> especially in the xml world, i'd just like to avoid any error here if
> possible.

Ah, OK. I think this kind of encoding question doesn't apply to mizar texts.

>>> - can the specification be indicated with a publicly accessible
>>> URL?
>> One candidate might be
>>
>> http://www.mizar.org/language/ which gives some information about
>> the language. Adam, do you have a better suggestion here?
>
> Such things as ASCII is not there.... this specifies the vocabulary
> not really the file format.

True, it doesn't specify the file format. Broadly, any ASCII document
is, potentially, a mizar text. Of course, only those texts that adhere
to the rules of the mizar language are acceptable to the mizar suite of
tools. But in principle they can operate on any ASCII text. Does that 
clarify things?

Jesse

-- Jesse Alama
http://centria.di.fct.unl.pt/~alama/