Subject: Re: [ietf-types] outdated template (was: Re: Review requested for draft-ietf-sidr-repos-struct)

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 04 Jul 2011 01:24:41 +0200

* 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/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 07 Jul 2011 11:28:57 -0600

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/

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 08 Jul 2011 10:17:20 +0100

> 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

-- 
For corporate legal information go to:

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

---

From: Paul Libbrecht <[email-masked]>
Date: Fri, 8 Jul 2011 13:37:37 +0200

Hello Peter,

> 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.

>      "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.

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

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 

hope it helps.

paul

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 14 Jul 2011 11:18:42 -0600

On 7/8/11 5:37 AM, 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)... 
>> 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?

> 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.
> 
>> 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:
>> 
>> 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/

---

From: George Michaelson <[email-masked]>
Date: Fri, 15 Jul 2011 10:34:16 +1000

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. 

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:

> 
> Hi Paul
> 
> Thank you for the suggestion.
> 
> 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.
> 
> - Stewart
> 
> 
> On 18/06/2011 21:37, 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.
>> 
>> If you agree, I would suggest a Windows Flavor Name (e.g. "RPKI Manifest") and Macintosh Uniform Type Identifier (e.g. "public.rpki.manifest").
>> 
>> paul
>> 
>> 
>> Le 17 juin 2011 à 15:14, Stewart Bryant a écrit :
>> 
>>> draft-ietf-sidr-repos-struct
>>> 
>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-repos-struct/
>>> 
>>> Makes the following types request.
>>> 
>>> Review comments by 1 July would be appreciated.
>>> 
>>> Many thanks
>>> 
>>> - Stewart
>>> 
>>> 
>>> 
>>> 7.1.1.  application/rpki-manifest
>>> 
>>>   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]>
>>> 
>>> 7.1.2.  application/rpki-roa
>>> 
>>>   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
>>> 
>>> Huston, et al.          Expires December 10, 2011              [Page 12]
>>> Internet-Draft        ResCert Repository Structure             June 2011
>>> 
>>>   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]>
>>> 
>>> _______________________________________________
>>> ietf-types mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ietf-types
>> 
> 
> 
> --

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 19 Jul 2011 15:54:37 +0100

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

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 19 Jul 2011 18:16:52 +0200

>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/