RE: IETF RFC format <-> W3C pubrules

I think everyone understand the benefits of enriched presentation of documents. No one is arguing that there is NO benefit.  Every participant in the IETF discussion over RFC format wants more than what is possible now.  The only questions are over the tradeoffs of benefits and costs, and on establishing criteria that authors and editors understand, agree with, can process, do not impose too many additional burdens.

Almost all of the problems are "solvable" in some abstract sense.  The problem is that some of the potential solutions require development and deployment of new infrastructure -- email archives, for example. Every new required feature adds additional compatibility considerations.  And the issues when there are many legacy systems are not abstract. There's lots we could theoretically do but which would cause untold and unnecessary disruption because it doesn't work with what's deployed. Surely you understand that.

I agree with " RFCs in HTML". However, *which* HTML? I think the guidelines for  HTML constructs allowed, encouraged, etc. will likely be quite similar between W3C and IETF, even if the default style sheet is different.     ReSpec.js looks like it would be a good foundation for something which provided required IETF boilerplate.  If IETF is more conservative than W3C, there might be a different profile of HTML features allowed.  

For "properly linked up and anchored" -- there was a long discussion about anchors and what the requirements were of references into specifications. There wasn't a discussion of "properly linked up", and I wonder if there are some guidelines in spec-prod land as to when cross-references are appropriate or a distraction.  There was specifically a question as to whether normative requirements (MUST, MAY, ...) should have semantic markup, but that seemed to be beyond the scope of the current discussion. (Personally, I think we could go a long way by linking specs to conformance testing or use cases in interoperability testing, so that we could formalize the notion of "multiple, independent, interoperable implementations", but that's a long way off.)

 " Would it not be possible, in the RFC format, to start with a allowing a  subset (that covers more than US-ASCII ...) of UNICODE?"

Yes, of course. And no one is opposed to doing so. The trick is "which subset?".  To do that, you need some idea of what the requirements are. 

On Accessibility: Accessibility is not best measured by "average ease of use".  Making a document more accessible (in the sense of making it easier to understand) to most of the population, but also making it less accessible (in the sense of making it IMPOSSIBLE to understand) to a smaller subset may not improve accessibility, if you gate is "What percentage of people can access the information". So sure, adding linking to the beginning of a document letting them skip the introductory info or mandatory or useless boilerplate might help someone. But leaving material necessary to determine conformance _only_ within non-accessible tables or figures seems like it unnecessarily narrows the scope of users who can interpret the document.


-----Original Message-----
From: Leif Halvard Silli [mailto:xn--mlform-iua@målform.no] 
Sent: Sunday, April 29, 2012 11:00 AM
To: Larry Masinter
Cc: Tab Atkins Jr.; Marcos Caceres; Doug Schepers; spec-prod@w3.org
Subject: RE: IETF RFC format <-> W3C pubrules

Larry Masinter, Sun, 29 Apr 2012 09:44:07 -0700:
>> The fact that they still produce pure-text documents
>> formatted for printing 80-column wide is either a travesty or a really
>> awesome troll.
> 
> It's more productive to understand the requirements.

The most productive part of Tab's message was "RFCs in HTML and utf-8, 
properly linked up and anchored" ...

  ...
> Email: IETF standards are developed in email, but email archives 
> commonly used throughout IETF (and W3C) are remarkably poor at 
> dealing with HTML, or discard the HTML and present an ugly attempt to 
> translate to ASCII text. It's not clear how to do better; there is no 
> suitable and implemented HTML profile defined as suitable for email 
> archives.

I find W3's online, HTML versions of their mailing lists better than 
that of the RFC-Editor.org. It handles Unicode well too. It can even be 
improved. It is not such an unsolvable problem.

> It's possible to for anyone to type an author's name into a search 
> engine -- allowing arbitrary Unicode might open you up to having to 
> deal with people who say their name is (╯°□°)╯︵ɹſsuıʞʇ∀qɐ┴.  (If I 
> look at https://twitter.com/#!/tabatkins in my default browser, I get 
> 3 squares [] in one place, five in another, and one in another; the 
> characters are not uniformly available in the three fonts I see.)   

Would it not be possible, in the RFC format, to start with a allowing a 
subset (that covers more than than US-ASCII ...) of UNICODE?

> RFCs are generally accessible.   Producing accessible HTML requires 
> additional considerations not obvious to the typical internet-draft 
> author.  And what do screen readers do with (╯°□°)╯︵ɹſsuıʞʇ∀qɐ┴? 

One accessibility issue is being able to ignore things. An RFC contains 
lots of repetitive text - especially at the start. It makes it tedious 
to start to understand. With links and anchors and CSS, one could start 
to hide things - or at least allow users to have "landmark links" that 
allow them to jump to the relevant place. E.g. for the words SHOULD, 
MUST etc, one could have a link to their definition.
-- 
Leif H Silli

Received on Monday, 30 April 2012 04:47:53 UTC