On 15. May 2025, at 06:28, Martin Thomson wrote:
>
> That resource is not present.
$ curl -I https://www.rfc-editor.org/rfc/rfc-local.css
HTTP/2 404
date: Thu, 15 May 2025 04:50:41 GMT
content-type: text/html; charset=utf-8
Maybe reacting to the (incorrect for a CSS) media type of the 404 respo
Hi Alexis,
(Resending to the list, too :-)
On Wed, May 14, 2025 at 1:27 PM Alexis Rossi wrote:
>>
>>
>> On Wed, May 14, 2025 at 3:59 AM Carsten Bormann wrote:
>> On 14. May 2025, at 11:09, Michael Richardson wrote:
>>>
>>> We needed an abstract that was higher level than the markdown tables
> And I’m myopic.
That always helps with immersing in dense diagrams :-)
Should I be seeing these errors:
Refused to apply style from 'https://www.rfc-editor.org/rfc/rfc-local.css'
because its MIME type ('text/html') is not a supported stylesheet MIME type,
and strict MIME checking is enabl
On Thu, May 15, 2025, at 14:21, Carsten Bormann wrote:
> Refused to apply style from
> 'https://www.rfc-editor.org/rfc/rfc-local.css' because its MIME type
> ('text/html') is not a supported stylesheet MIME type, and strict MIME
> checking is enabled.
That resource is not present. However, the
On 15-May-25 13:50, Martin Thomson wrote:
On Thu, May 15, 2025, at 11:44, StJohns, Michael wrote:
Just took a look from an iPadMiniusing Safari. Perfectly readable.
And I’m myopic. But they are a bit dense.
All screens are different. I have a very large screen and I'm unable to read
the te
On Thu, May 15, 2025, at 11:44, StJohns, Michael wrote:
> Just took a look from an iPadMiniusing Safari. Perfectly readable.
> And I’m myopic. But they are a bit dense.
All screens are different. I have a very large screen and I'm unable to read
the text. If you want a format that is not
Just took a look from an iPadMiniusing Safari. Perfectly readable. And
I’m myopic. But they are a bit dense.
Mike
On Wed, May 14, 2025 at 20:01 Martin Thomson wrote:
> On Thu, May 15, 2025, at 00:16, Jean Mahoney wrote:
> > (Artwork only available as SVG: see
> > https://www.rfc-edi
On Thu, May 15, 2025, at 00:16, Jean Mahoney wrote:
> (Artwork only available as SVG: see
> https://www.rfc-editor.org/rfc/rfc9633.html)
>
>Figure 1: Case A-1: Application Flow Aggregation
Wow, I hadn't seen these diagrams before. They are completely unreadable. The
text
On Wed, May 14, 2025 at 01:48:45PM -0700, Alexis Rossi wrote:
> While doing a little exploring about UML and PlantUML yesterday, I noticed
> that draw.io is phasing out PlantUML support at the end of the year in
> favor of mermaid.js. I don't know what that means about its longevity, but
> thought
On Wed, May 14, 2025 at 2:06 AM Michael Richardson
wrote:
>
> Nico Williams wrote:
>
>
> Even plantuml sources will be more accessible than imagery. We should
> > try to be more formal and precise in prose.
>
> I haven't used this one, but it seems similiar to other things.
>
>
While d
On Wed, May 14, 2025 at 3:59 AM Carsten Bormann wrote:
> On 14. May 2025, at 11:09, Michael Richardson
> wrote:
> >
> > We needed an abstract that was higher level than the markdown tables.
>
> I often generate tables from CSV files.
> E.g.,
>
> https://github.com/cbor-wg/draft-ietf-cbor-cde
>
>
>
>
>
>
> > Not sure how the current generation of braille readers are impacted by
> > SVG
>
> [JM] SVG is accessible to screen reader apps. The SVG desc element [4]
> allows authors to provide a description of the diagram that is then read
> to screen reader users.
>
> There is an open issue [5] o
Hi Marc,
semi-facetious...
> I spent the last 10 years trying to convince people at the IETF to use formal
> methods to reduce errata and updates (with little success).
10 years is not enough.
(ABNF was invented 1977 and became STD in 2008.)
> I also recently proposed a modification to RFCXM
On 5/13/25 4:57 PM, Martin Thomson wrote:
> On Wed, May 14, 2025, at 09:43, Marc Petit-Huguenin wrote:
>> No to making anything but English sentences normative. People can add
>> all the examples, diagram, images, and alt tags they want in an RFC, I
>> am going to ignore all of them and complain
On 14. May 2025, at 16:23, Paul Duffy (paduffy)
wrote:
>
> It was required that both the OpenAPI and Protobuf definitions be inlined
> within the draft. It's a mess (not directly usable by developer tools …
That is indeed a problem.
I made a quick prototype a while ago how the RPC might want
Dear Colleagues,
Do you know, having to deal with legal matters affecting Children&families, and
it's the same shit different day - informative v normative alias legislative v
executive alias saxon v norman.
I digress. What about borrowing an idea from Microsoft branded visual basic?
Graphica
Hi Michael,
On 5/14/25 7:31 AM, Michael Richardson wrote:
Are there some examples in the RFC series of WG publishing (HTTP)APIs based
upon the Swagger definitions.
[JM] RFC 8743 has an example implementation of an API documented with
OpenAPI using Swagger 2.0 [1]
1. How do we present the
Hi all,
Some general info on how ASCII art and SVG are currently handled by
tools below --
On 5/13/25 5:39 PM, Agent wrote:
I'm thinking about this one. My initial thoughts are that we should use
an alternatives mechanism so that ASCII art is always there but SVG
overlay exists - or maybe w
https://datatracker.ietf.org/doc/draft-duffy-csmp/08/
It was required that both the OpenAPI and Protobuf definitions be inlined
within the draft. It's a mess (not directly usable by developer tools ... but
links for direct import are included later in the draft).
This is also a draft strugglin
On 5/13/25 5:11 PM, Carsten Bormann wrote:
> On 14. May 2025, at 01:24, Brian E Carpenter
> wrote:
>>
>> Just to take a recent example, anyone consulting RFC 9686 using a screen
>> reader will not obtain an overview of the address registration mechanism
>> (only described by Fig. 1) and will have
I suggested to Michael directly, but will repost it here: ask on the HTTPAPI
working group.
___
rfc-interest mailing list -- rfc-interest@rfc-editor.org
To unsubscribe send an email to rfc-interest-le...@rfc-editor.org
I'm thinking about this one. My initial thoughts are that we should use an alternatives mechanism so that ASCII art is always there but SVG overlay exists - or maybe work on an ASCII/SVG gateway is called for. Not sure how the current generation of braille readers are impacted by SVG and it is impo
Not an RFC yet, but see draft-ietf-scim-device-model. While it's not
super obvious, the reference should probably be
https://spec.openapis.org/oas/v3.1.1.html.
Eliot
On 14.05.2025 14:31, Michael Richardson wrote:
Are there some examples in the RFC series of WG publishing (HTTP)APIs based
up
Are there some examples in the RFC series of WG publishing (HTTP)APIs based
upon the Swagger definitions.
1. How do we present the YAML?
2. What we do reference as the description of this schema (the schema for the
API schema)
3. Any RPC experiences we should be aware of?
This is for the ASDF WG'
I have no issues with requiring images be fully described in accompanying text.
The lack of IETF’s ability to accommodate SVG generated from (name your common
tooling) is an ongoing source of great frustration.
From: Eliot Lear
Sent: Wednesday, May 14, 2025 6:10 AM
To: Paul Hoffman ; rfc-intere
On 14. May 2025, at 11:09, Michael Richardson wrote:
>
> We needed an abstract that was higher level than the markdown tables.
I often generate tables from CSV files.
E.g.,
https://github.com/cbor-wg/draft-ietf-cbor-cde
(Files with “table” in the name.)
In this case, this is a CSV, which coul
Paul, others,
I'm entirely in favor of an approach to image use that appropriately
addresses accessibility requirements. As I wrote elsewhere, images and
text should match. If they don't it's an erratum. After all, nobody
creates a picture (SVG or ASCII) that is intentionally inconsistent w
Alexis Rossi wrote:
> This is a long one, so let me state my goal up front. I am trying to
> ascertain whether there is community interest in trying to make sure
future
> RFCs can be fully read and understood without relying on information in
> imagery (SVG or ASCII). This is an
Carsten Bormann wrote:
> It is hard enough to get an RFC published at this point.
> We should be working on removing obstacles, not adding them.
RFC9008 took ages to do.
A major PITA was getting all the tables well formatted and reviewing the
changes to make sure they were all accurate.
Nico Williams wrote:
> On Tue, May 13, 2025 at 03:00:45PM -0700, Alexis Rossi wrote:
>> So I think this leads me back to my goal for posting here. Is the
community
>> interested in supporting accessibility by trying to make sure future RFCs
>> can be fully read and understood wit
30 matches
Mail list logo
