[media-types] [IANA #1272257] application/vnd.ipfs.ipns-record registration request

[Amanda Baber via RT <[e-mail]>]

Hi Alexey,

Sending a reminder for this revision from May 11th.

thanks,
Amanda

On Thu May 11 18:36:37 2023, amanda.baber wrote:
> Hi Alexey,
> 
> Does this revision work?
> 
> ===
> 
> Security considerations:
> 
> The media type inherits the security considerations from
> application/octet-stream,
> contains no executable code, offers no data confidentiality,
> but provides integrity protection through a signature digest:
> <https://specs.ipfs.tech/ipns/ipns-record/#record-verification>
> In the IPFS/IPNS contexts, it is mandatory to verify the integrity
> based on the expected signature digest before acting
> on any content-addressed data linked from the record.
> 
> ===
> 
> thanks,
> Amanda
> 
> On Thu May 11 12:57:32 2023, [e-mail] wrote:
> > Hi Amanda,
> >
> > On 09/05/2023 20:31, Amanda Baber via RT wrote:
> > > Hi Alexey,
> > >
> > > Can you review this request by May 23rd?
> > >
> > > I'm passing this one to you because you reviewed this applicant's
> > > four application/vnd.ipld.* requests last year.
> > This is fine to register. One small question/suggestion below:
> > >
> > > thanks,
> > > Amanda
> > >
> > > =====
> > >
> > > Name: Marcin Rataj
> > >
> > > Email: [e-mail]
> > >
> > > Media type name: application
> > >
> > > Media subtype name: vnd.ipfs.ipns-record
> > >
> > > Required parameters: N/A
> > >
> > > Optional parameters: N/A
> > >
> > > Encoding considerations: binary
> > >
> > > Security considerations: The media type inherits the security
> > > considerations for application/octet-stream,
> > > contains no executable code.
> > I think this registration can be improved by stating whether the
> > format
> > provides any means for integrity protection and/or data
> > confidentiality.
> > > When used in IPFS/IPNS context, it is strongly recommended
> > > verifying
> > > record integrity based on expected signature digest
> > > <https://specs.ipfs.tech/ipns/ipns-record/#record-verification>.
> > >
> > > Interoperability considerations: N/A
> > >
> > > Published specification: <https://specs.ipfs.tech/ipns/ipns-
> > > record/#record-serialization-format>
> > >
> > > Applications which use this media: IPFS <https://ipfs.tech> uses
> > > signed IPNS records as means of introducing cryptographically-
> > > verifiable mutable pointers to immutable data
> > > <https://specs.ipfs.tech/ipns/ipns-record/>.
> > >
> > > IPNS allows addressing dynamic content in a decentralized network
> > > with changing location and version. Signed IPNS records in IPFS
> > > enable secure, tamper-proof content-addressable applications and
> > > services with high resilience against censorship and data loss.
> > >
> > > Fragment identifier considerations: N/A
> > >
> > > Restrictions on usage: N/A
> > >
> > > Provisional registration? (standards tree only): No
> > >
> > > Additional information:
> > >
> > > 1. Deprecated alias names for this type: N/A
> > > 2. Magic number(s): N/A
> > > 3. File extension(s): ipns-record
> > > 4. Macintosh file type code: N/A
> > > 5. Object Identifiers: N/A
> > >
> > > General Comments:
> > >
> > > Person to contact for further information:
> > >
> > > 1. Name: Marcin Rataj
> > > 2. Email: [e-mail]
> > >
> > > Intended usage: COMMON
> > >
> > > IPNS records can be exchanged using a variety of transport
> > > mechanisms, including P2P, HTTP, or even sneakernet.
> > >
> > > Author/Change controller: Protocol Labs
> > > <https://protocol.ai>
> > > <[e-mail]>