headers
Larry Masinter | 29 Apr 2012 05:50
Picon
Favicon
Gravatar

IETF RFC format <-> W3C pubrules

Hey W3Cers, there's a serious discussion in IETF-land over updating the
format for RFCs. There was a meeting at the last IETF meeting
and a lengthy discussion about requirements, workflows, etc.

    http://www.rfc-editor.org/pipermail/rfc-interest/

I think it is feasible and would be a great breakthrough if IETF
and W3C specification formats could converge.

There is quite a bit of overlap in requirements, although of course
They are not exactly aligned.

It would especially be a boon for joint IETF/W3C work.
Permalink | Reply |
headers
Doug Schepers | 29 Apr 2012 06:11
Picon
Favicon

Re: IETF RFC format <-> W3C pubrules

Hi, Larry-

On 4/28/12 11:50 PM, Larry Masinter wrote:
> Hey W3Cers, there's a serious discussion in IETF-land over updating the
> format for RFCs. There was a meeting at the last IETF meeting
> and a lengthy discussion about requirements, workflows, etc.
>
>      http://www.rfc-editor.org/pipermail/rfc-interest/
>
> I think it is feasible and would be a great breakthrough if IETF
> and W3C specification formats could converge.
>
> There is quite a bit of overlap in requirements, although of course
> They are not exactly aligned.
>
> It would especially be a boon for joint IETF/W3C work.

I think this would be a great idea.  There is some movement here in W3C 
on a new design for specs (beyond Tab and Fantasai's April Fools' joke).

Would you be interested in being a point person in collecting and 
reporting IETF requirements?

I think IETF, and the Web community, would benefit from a well-style 
HTML version of IETF specs.

Regards-
-Doug Schepers
W3C Developer Relations
Project Coordinator, SVG, WebApps, Touch Events, and Audio WGs
(Continue reading)

Permalink | Reply |
headers
Marcos Caceres | 29 Apr 2012 13:36
Gravatar

Re: IETF RFC format <-> W3C pubrules


On Sunday, 29 April 2012 at 05:11, Doug Schepers wrote:

> I think IETF, and the Web community, would benefit from a well-style
> HTML version of IETF specs.

I agree. But, irrespective of how they look stylistically, I think most would just settle for normative
HTML specs from the IETF with proper marked-up/linkable definitions, algorithms, and sections (and
particularly, for the IETF deprecate the paginated text-only format so their is only one authoritative
source in HTML). 

It would be great to hear if the IETF has any requirements form the W3C side. As HTML is the normative format at
the w3c, I wonder if other communities require anything form us?   

--

-- 
Marcos Caceres
http://datadriven.com.au
Permalink | Reply |
headers
Tab Atkins Jr. | 29 Apr 2012 17:42
Picon
Gravatar

Re: IETF RFC format <-> W3C pubrules

On Sun, Apr 29, 2012 at 4:36 AM, Marcos Caceres <w3c <at> marcosc.com> wrote:
> On Sunday, 29 April 2012 at 05:11, Doug Schepers wrote:
>> I think IETF, and the Web community, would benefit from a well-style
>> HTML version of IETF specs.
>
> I agree. But, irrespective of how they look stylistically, I think most would just settle for normative
HTML specs from the IETF with proper marked-up/linkable definitions, algorithms, and sections (and
particularly, for the IETF deprecate the paginated text-only format so their is only one authoritative
source in HTML).

+1. Aligning the styles and structure would be cool, but unnecessary.
All I want for Christmas is RFCs in HTML and utf-8, properly linked up
and anchored.  The fact that they still produce pure-text documents
formatted for printing 80-column wide is either a travesty or a really
awesome troll.

~TJ
Permalink | Reply |
headers
Larry Masinter | 29 Apr 2012 18:44
Picon
Favicon
Gravatar

RE: IETF RFC format <-> W3C pubrules

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

40 year old RFCs are still pretty universally usable.  There is less document success with other formats.
Promises of future support because of widespread deployment aren't worth much more than a "gopher:"  URL.

Many in the IETF use simple text tools like grep and diff on their personal copies of all RFCs and even editor
drafts. 

RFCs are single-file. If you allow images in HTML, then do you change that or package them together?
  
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.

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

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ɐ┴? 

There are more; my point is that I think these are important considerations that W3C (and spec-prod) should
(Continue reading)

Permalink | Reply |
headers
Leif Halvard Silli | 29 Apr 2012 19:59
Picon

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
(Continue reading)

Permalink | Reply |
headers
Larry Masinter | 30 Apr 2012 06:47
Picon
Favicon
Gravatar

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
(Continue reading)

Permalink | Reply |
headers
Leif Halvard Silli | 1 May 2012 02:02
Picon

RE: IETF RFC format <-> W3C pubrules

Larry Masinter, Sun, 29 Apr 2012 21:47:18 -0700:

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

What has e-mail archives to do with RFCs? Is the intention to send RFCs 
as e-mail?

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

There are text encoding problems with the current RFC system too.

First there is the problems related to describing characters, rather 
than typing them directly, which makes the RFCs difficult to understand 
for instance if the character describes a non-ASCII letter instead of 
rendering it. Or, the problem related to descriptions such as 'below I 
type an 'a', but you should consider that it is 'exotic letter x'. 

Second, you do have encoding problems now as well. Take RFC2557, which 
contains at least one non-ASCII letter - É. 

* <http://www.rfc-editor.org/rfc/rfc2557.txt

  includes the É because the file is served as ISO-8859-1
* <http://tools.ietf.org/html/rfc2557#section-9.1> is served, via
(Continue reading)

Permalink | Reply |
headers
Julian Reschke | 1 May 2012 10:09
Picon
Picon

Re: IETF RFC format <-> W3C pubrules

On 2012-05-01 02:02, Leif Halvard Silli wrote:
> ...
> There are text encoding problems with the current RFC system too.
>
> First there is the problems related to describing characters, rather
> than typing them directly, which makes the RFCs difficult to understand
> for instance if the character describes a non-ASCII letter instead of
> rendering it. Or, the problem related to descriptions such as 'below I
> type an 'a', but you should consider that it is 'exotic letter x'.
> ...

We know. See rfc-interest mailing list.

> Second, you do have encoding problems now as well. Take RFC2557, which
> contains at least one non-ASCII letter - É.

We know. See rfc-interest mailing list.

> *<http://www.rfc-editor.org/rfc/rfc2557.txt
>    includes the É because the file is served as ISO-8859-1
> *<http://tools.ietf.org/html/rfc2557#section-9.1>  is served, via
>    HTTP, with the charset label 'latin-1', which is an invalid
>    label, which means that the page is only correct in Web browsers
>    that default to Windows-1252.

As far as I can tell, it's served as UTF-8.

> *<http://www.rfc-editor.org/rfc/pdfrfc/rfc2557.txt.pdf>
>    includes the É, for some reason.
> *<http://datatracker.ietf.org/doc/rfc2557/?include_text=1>
(Continue reading)

Permalink | Reply |
headers
Leif Halvard Silli | 1 May 2012 10:56
Picon

Re: IETF RFC format <-> W3C pubrules

Julian Reschke, Tue, 01 May 2012 10:09:25 +0200:

>> * <http://tools.ietf.org/html/rfc2557#section-9.1>  is served, via
>>    HTTP, with the charset label 'latin-1', which is an invalid
>>    label, which means that the page is only correct in Web browsers
>>    that default to Windows-1252.
> 
> As far as I can tell, it's served as UTF-8.

Response #4028
Status 200; http://tools.ietf.org/html/rfc2557#section-9.1
Vary: negotiate,Accept-Encoding
Content-Encoding: gzip
Server: Apache/2.2.21 (Debian)
Content-Type: text/html; charset=latin-1
Date: Tue, 01 May 2012 08:53:48 GMT
--

-- 
leif h silli
Permalink | Reply |
headers
Larry Masinter | 8 May 2012 03:37
Picon
Favicon
Gravatar

FW: IETF RFC format <-> W3C pubrules

FYI, there was a thread on sharing RFC and W3C formatting rules and tools on the mailing list of the group
responsible for W3C publication format, 
http://lists.w3.org/Archives/Public/spec-prod/2012AprJun/0007.html.
Permalink | Reply |
headers
Iljitsch van Beijnum | 8 May 2012 12:47
Favicon

Re: FW: IETF RFC format <-> W3C pubrules

On 8 May 2012, at 3:37 , Larry Masinter wrote:

> FYI, there was a thread on sharing RFC and W3C formatting rules and tools on the mailing list of the group
responsible for W3C publication format, 
> http://lists.w3.org/Archives/Public/spec-prod/2012AprJun/0007.html.   

That message just links to a mailinglist archive. Keeping up with this list is already a big time
investment. Can anyone summarize what's going on at W3C and/or point to relevant info about the W3C format
and tools?
Permalink | Reply |
headers
Larry Masinter | 8 May 2012 20:20
Picon
Favicon
Gravatar

Re: FW: IETF RFC format <-> W3C pubrules

>  Can anyone summarize what's going on at W3C and/or point to relevant info about the W3C format and tools?

 

Here’s a quick summary:

 

The W3C produces technical standards and drafts (http://www.w3.org/TR/ has a complete list).

The W3C has a set rules for technical publications, and a set of tools for producing them.

  "spec-prod <at> w3.org"  is a public mailing list devoted to mechanisms for producing and managing W3C specifications. 

 

The web page http://lists.w3.org/Archives/Public/spec-prod/   not only has the mailing list archives, it has a list of tools and references to publication rules and guidelines at the bottom (scroll down).

 

Tools

·         Pubrules automated check tool

·         W3C Bibliography Extractor

·         W3C Spell Checker

·         W3C Stylistic Checker

·         XML Document Production Tools

·         Document Management for Web Specs

 

For Reference

·         W3C Editors' Home Page

·         W3C Publication Rules ("pubrules")

·         W3C Manual of Style

·         W3C Process Document

 

 

The group  is looking at enhancing their tooling and also modifying the requirements for document format to fix problems as well as allowing new capabilities.

 

One of the tools is ReSpec.js  http://dev.w3.org/2009/dap/ReSpec.js/documentation.html which might be adaptable for IETF use.

 

 

 

_______________________________________________
rfc-interest mailing list
rfc-interest <at> rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest
Permalink | Reply |
headers
Iljitsch van Beijnum | 8 May 2012 20:24
Favicon

Re: FW: IETF RFC format <-> W3C pubrules

On 8 May 2012, at 20:20 , Larry Masinter wrote:

> Here’s a quick summary:

Thanks, I'll read up when I get a change. However:

> One of the tools is ReSpec.js  http://dev.w3.org/2009/dap/ReSpec.js/documentation.html which might
be adaptable for IETF use.

Although it would seem to make sense for the two to work together, wouldn't it be a huge liability for both of
them to depend on the other for something so crucial?
Permalink | Reply |
headers
Bjoern Hoehrmann | 9 May 2012 03:51
Picon

Re: FW: IETF RFC format <-> W3C pubrules

* Iljitsch van Beijnum wrote:
>On 8 May 2012, at 20:20 , Larry Masinter wrote:
>> One of the tools is ReSpec.js  http://dev.w3.org/2009/dap/ReSpec.js/documentation.html
>> which might be adaptable for IETF use.
>
>Although it would seem to make sense for the two to work together,
>wouldn't it be a huge liability for both of them to depend on the other
>for something so crucial?

RFC 2629 (the xml2rfc format) has been around for about as long as I
have been involved with the W3C and the IETF. `xml2rfc` is still alive
and kicking, with very broad adoption. In contrast, the W3C has used
any number of formats and toolchains during the period. As the people
who made or maintained the formats and toolchains lose interest, the
formats and the toolchains die "quickly". I'd suggest to keep in mind
that the IETF output is an order of magnitude greater than that of the
W3C.

The W3C is also unlikely to coordinate tool development with non-W3C
parties. For instance, HTML Tidy http://tidy.sf.net/ originated there,
but maintenance of the tool became a problem, so a couple of people,
including myself, took over maintenance and development in form of a
SourceForge project. The W3C showed no interest in that over the years
until last year, when I published a patch for rudimentary "HTML5" sup-
port. Then the W3C took the latest sources and my patch, and created a
fork, publicized it, and has since "maintained" the fork in a manner
incompatible with established practises and goals of the SourceForge
project. The W3C made no attempt whatsoever to announce, discuss, or
otherwise coordinate their fork with the HTML Tidy project, including
no attempts to express dissatisfaction prior to their hostile take-
over. And while I very explicitly asked for feedback when I published
my patch for "HTML5" support they used to create their fork -- and they
certainly seem to have found issues with it -- no feedback ever made
its way into my inbox.

So I would not see this as a "huge liability", just as, plainly, silly.
--

-- 
Björn Höhrmann · mailto:bjoern <at> hoehrmann.de · 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/
Permalink | Reply |
headers
Larry Masinter | 9 May 2012 04:45
Picon
Favicon
Gravatar

Re: FW: IETF RFC format <-> W3C pubrules

I was reluctant to do this, but I think rfc-interest and spec-prod should meet.

There is a great diversity of people involved in both IETF  and W3C, and some incredulity in both
organizations about the other's willingness, interest, or capabilities of coordination, to pick
unfairly tow examples:

 From RFC-interest  http://www.rfc-editor.org/pipermail/rfc-interest/2012-May/003486.html 
 From spec-prod http://lists.w3.org/Archives/Public/spec-prod/2012AprJun/0011.html

Let's move beyond that.

I think there are a common set of requirements for archivable, accessible, Unicode, hyperlinked,
reliably printable technical specifications suitable for standardization, as well as some unique
requirements of each organization in order to deal with differing legacy, audiences, and compatibility requirements.

I think both organizations have a combination of paid staff and substantial help from volunteers.

Talk

Larry

-----Original Message-----
From: Bjoern Hoehrmann [mailto:derhoermi <at> gmx.net] 
Sent: Tuesday, May 08, 2012 6:52 PM
To: Iljitsch van Beijnum
Cc: Larry Masinter; rfc-interest <at> rfc-editor.org
Subject: Re: [rfc-i] FW: IETF RFC format <-> W3C pubrules

* Iljitsch van Beijnum wrote:
>On 8 May 2012, at 20:20 , Larry Masinter wrote:
>> One of the tools is ReSpec.js  http://dev.w3.org/2009/dap/ReSpec.js/documentation.html
>> which might be adaptable for IETF use.
>
>Although it would seem to make sense for the two to work together,
>wouldn't it be a huge liability for both of them to depend on the other
>for something so crucial?

RFC 2629 (the xml2rfc format) has been around for about as long as I
have been involved with the W3C and the IETF. `xml2rfc` is still alive
and kicking, with very broad adoption. In contrast, the W3C has used
any number of formats and toolchains during the period. As the people
who made or maintained the formats and toolchains lose interest, the
formats and the toolchains die "quickly". I'd suggest to keep in mind
that the IETF output is an order of magnitude greater than that of the
W3C.

The W3C is also unlikely to coordinate tool development with non-W3C
parties. For instance, HTML Tidy http://tidy.sf.net/ originated there,
but maintenance of the tool became a problem, so a couple of people,
including myself, took over maintenance and development in form of a
SourceForge project. The W3C showed no interest in that over the years
until last year, when I published a patch for rudimentary "HTML5" sup-
port. Then the W3C took the latest sources and my patch, and created a
fork, publicized it, and has since "maintained" the fork in a manner
incompatible with established practises and goals of the SourceForge
project. The W3C made no attempt whatsoever to announce, discuss, or
otherwise coordinate their fork with the HTML Tidy project, including
no attempts to express dissatisfaction prior to their hostile take-
over. And while I very explicitly asked for feedback when I published
my patch for "HTML5" support they used to create their fork -- and they
certainly seem to have found issues with it -- no feedback ever made
its way into my inbox.

So I would not see this as a "huge liability", just as, plainly, silly.
--

-- 
Björn Höhrmann · mailto:bjoern <at> hoehrmann.de · 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/
Permalink | Reply |
headers
Paul Hoffman | 9 May 2012 04:55

Re: IETF RFC format <-> W3C pubrules

On May 8, 2012, at 7:45 PM, Larry Masinter wrote:

> I think there are a common set of requirements for archivable, accessible, Unicode, hyperlinked,
reliably printable technical specifications suitable for standardization, as well as some unique
requirements of each organization in order to deal with differing legacy, audiences, and compatibility requirements.

For the folks on spec-prod: note that Larry started that sentence with "I think that...". There are some
people on the rfc-interest list who agree with him about the requirements, and some who do not. I propose
that you don't assume that Larry is right, and I don't propose that you ask the IETF what your requirements
should be.

--Paul Hoffman
Permalink | Reply |
headers
Larry Masinter | 9 May 2012 05:14
Picon
Favicon
Gravatar

Re: IETF RFC format <-> W3C pubrules

What I should have said was that, while there are different requirements from each organization, the
intersection of requirements is likely to be substantial.  The requirements might be different enough
that sharing tooling is impossible. But a discussion over requirements and an evaluation of
requirements for tooling are interesting.

The particular requirements I listed ("archivable, accessible, Unicode, hyperlinked, reliably
printable, technical specifications, suitable for standardization") should not have been taken as
definitive or accepted -- I don't think either group has consensus on requirements. 

Larry

-----Original Message-----
From: rfc-interest-bounces <at> rfc-editor.org [mailto:rfc-interest-bounces <at> rfc-editor.org] On
Behalf Of Paul Hoffman
Sent: Tuesday, May 08, 2012 7:56 PM
To: rfc-interest; spec-prod <at> w3.org
Subject: Re: [rfc-i] IETF RFC format <-> W3C pubrules

On May 8, 2012, at 7:45 PM, Larry Masinter wrote:

> I think there are a common set of requirements for archivable, accessible, Unicode, hyperlinked,
reliably printable technical specifications suitable for standardization, as well as some unique
requirements of each organization in order to deal with differing legacy, audiences, and compatibility requirements.

For the folks on spec-prod: note that Larry started that sentence with "I think that...". There are some
people on the rfc-interest list who agree with him about the requirements, and some who do not. I propose
that you don't assume that Larry is right, and I don't propose that you ask the IETF what your requirements
should be.

--Paul Hoffman

_______________________________________________
rfc-interest mailing list
rfc-interest <at> rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest
Permalink | Reply |
headers
Tab Atkins Jr. | 9 May 2012 10:14
Picon
Gravatar

Re: [rfc-i] IETF RFC format <-> W3C pubrules

On Wed, May 9, 2012 at 5:14 AM, Larry Masinter <masinter <at> adobe.com> wrote:
> What I should have said was that, while there are different requirements from each organization, the
intersection of requirements is likely to be substantial.  The requirements might be different enough
that sharing tooling is impossible. But a discussion over requirements and an evaluation of
requirements for tooling are interesting.
>
> The particular requirements I listed ("archivable, accessible, Unicode, hyperlinked, reliably
printable, technical specifications, suitable for standardization") should not have been taken as
definitive or accepted -- I don't think either group has consensus on requirements.

In contrast, I would assume that those particular requirements are
uncontroversial and widely accepted.  They don't set a very high bar,
but it's a very useful bar.  I honestly can't think of a reason why
anyone would object to any of those.

Asking for consistency in styles or shared toolchains or the like is
definitely a step further, and one that I don't believe is necessary
(but wouldn't object to).  We can discuss these sorts of things.  But
if we can't even agree that documents should be hyperlinked and
unicode, then I'm not sure how we can actually discuss anything.  That
would be a pretty fundamental disconnect.

~TJ
Permalink | Reply |
headers
Phillip Hallam-Baker | 9 May 2012 13:12
Picon

Re: IETF RFC format <-> W3C pubrules

I note that as is often the case when the blatantly obvious is said we
have disagreement by unresolved reference.

If you can't give a reason for a disagreement then you should probably
think a bit before posting and wait until you can state what the
disagreement is.

We have two standards bodies here. What is the reason to NOT have a
common standard?

BTW the only 'tools' I needed to produce W3C docs was the bit of code
to rip out the style crud produced by Microsoft Word and another that
produced the index.

I used the same tools to produce W3C and OASIS docs.

On Tue, May 8, 2012 at 10:55 PM, Paul Hoffman <paul.hoffman <at> vpnc.org> wrote:
> On May 8, 2012, at 7:45 PM, Larry Masinter wrote:
>
>> I think there are a common set of requirements for archivable, accessible, Unicode, hyperlinked,
reliably printable technical specifications suitable for standardization, as well as some unique
requirements of each organization in order to deal with differing legacy, audiences, and compatibility requirements.
>
> For the folks on spec-prod: note that Larry started that sentence with "I think that...". There are some
people on the rfc-interest list who agree with him about the requirements, and some who do not. I propose
that you don't assume that Larry is right, and I don't propose that you ask the IETF what your requirements
should be.
>
> --Paul Hoffman
>
> _______________________________________________
> rfc-interest mailing list
> rfc-interest <at> rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

--

-- 
Website: http://hallambaker.com/
Permalink | Reply |
headers
Julian Reschke | 9 May 2012 14:09
Picon
Picon

Re: IETF RFC format <-> W3C pubrules

On 2012-05-09 13:12, Phillip Hallam-Baker wrote:
> I note that as is often the case when the blatantly obvious is said we
> have disagreement by unresolved reference.
>
> If you can't give a reason for a disagreement then you should probably
> think a bit before posting and wait until you can state what the
> disagreement is.
>
> We have two standards bodies here. What is the reason to NOT have a
> common standard?
>
>
> BTW the only 'tools' I needed to produce W3C docs was the bit of code
> to rip out the style crud produced by Microsoft Word and another that
> produced the index.
>
> I used the same tools to produce W3C and OASIS docs.

...which means: little metadata or no metadata to rely on, right?
Permalink | Reply |
headers
Phillip Hallam-Baker | 9 May 2012 14:57
Picon

Re: IETF RFC format <-> W3C pubrules

On Wed, May 9, 2012 at 8:09 AM, Julian Reschke <julian.reschke <at> gmx.de> wrote:
> On 2012-05-09 13:12, Phillip Hallam-Baker wrote:
>>
>> I note that as is often the case when the blatantly obvious is said we
>> have disagreement by unresolved reference.
>>
>> If you can't give a reason for a disagreement then you should probably
>> think a bit before posting and wait until you can state what the
>> disagreement is.
>>
>> We have two standards bodies here. What is the reason to NOT have a
>> common standard?
>>
>>
>> BTW the only 'tools' I needed to produce W3C docs was the bit of code
>> to rip out the style crud produced by Microsoft Word and another that
>> produced the index.
>>
>> I used the same tools to produce W3C and OASIS docs.
>
>
> ...which means: little metadata or no metadata to rely on, right?

I am not sure quite what you mean there.

One of the reasons I think support for metadata sucks in every tool in
existence is that they are all wysiwyg and metadata is something you
don't see by definition.

What I want is a tool that supports an editing mode that is NEITHER
WYSIWYG or raw markup. I want to see my text in properly formatted
paragraphs that also disclose the semantic markup.

So if I had transcluded some chunk o' boilerplate there would be some
sort of mark at the start saying <include:ipr2012> followed by the
transcluded text. So I could read the editing copy and see immediately
what is going on.

I only want to see metadata that matters, not every <P> tag.

It would be really nice if there was a toolset out there that
generated and made use of a common set of metadata. But that has not
happened.

For example, it should be possible to cut an paste a citation from one
document to another in such a way that tools are able to reformat it
to apply whatever deranged nonsense of a citation format is required
at the other end. I don't see that as existing.

Pretty much every tool there is to manage citations sucks. I have
tried end note and it sucks because it is an afterthought. The
citation handling in Word is stovepiped to a few formats that are all
stupid and few other things bother at all.

It really should not be difficult, A 'database' of citations should
require no more than an HTML document with a list of citations.

It should be possible to drop in a citation by just typing in
cite:rfc1234 or something similar.

--

-- 
Website: http://hallambaker.com/
Permalink | Reply |
headers
Iljitsch van Beijnum | 9 May 2012 15:11
Favicon

Re: IETF RFC format <-> W3C pubrules

On 9 May 2012, at 14:57 , Phillip Hallam-Baker wrote:

> It should be possible to drop in a citation by just typing in
> cite:rfc1234 or something similar.

No, that's not a good solution because you then still need a special tool to resolve that syntax into
something useful.

Just include a link to the canonical location of what's cited. Simple to do (just paste the link), gives
decent results without tools (just hover or click the link) and very good results with tools (get the
citation text in the format du jour from the citation database).
Permalink | Reply |
headers
Julian Reschke | 9 May 2012 15:11
Picon
Picon

Re: IETF RFC format <-> W3C pubrules

On 2012-05-09 14:57, Phillip Hallam-Baker wrote:
> On Wed, May 9, 2012 at 8:09 AM, Julian Reschke<julian.reschke <at> gmx.de>  wrote:
>> On 2012-05-09 13:12, Phillip Hallam-Baker wrote:
>>>
>>> I note that as is often the case when the blatantly obvious is said we
>>> have disagreement by unresolved reference.
>>>
>>> If you can't give a reason for a disagreement then you should probably
>>> think a bit before posting and wait until you can state what the
>>> disagreement is.
>>>
>>> We have two standards bodies here. What is the reason to NOT have a
>>> common standard?
>>>
>>>
>>> BTW the only 'tools' I needed to produce W3C docs was the bit of code
>>> to rip out the style crud produced by Microsoft Word and another that
>>> produced the index.
>>>
>>> I used the same tools to produce W3C and OASIS docs.
>>
>>
>> ...which means: little metadata or no metadata to rely on, right?
>
> I am not sure quite what you mean there.

A way to programatically extract all the information xml2rfc captures 
for us, such as author names, WG information, "updates"/"obsoletes" 
information, references, ABNF, copyright status, ...

> One of the reasons I think support for metadata sucks in every tool in
> existence is that they are all wysiwyg and metadata is something you
> don't see by definition.

Yes. One of the reasons I do not like WYSISYG tools.

> What I want is a tool that supports an editing mode that is NEITHER
> WYSIWYG or raw markup. I want to see my text in properly formatted
> paragraphs that also disclose the semantic markup.
>
> So if I had transcluded some chunk o' boilerplate there would be some
> sort of mark at the start saying<include:ipr2012>  followed by the
> transcluded text. So I could read the editing copy and see immediately
> what is going on.
>
> I only want to see metadata that matters, not every<P>  tag.
>
>
> It would be really nice if there was a toolset out there that
> generated and made use of a common set of metadata. But that has not
> happened.
>
> For example, it should be possible to cut an paste a citation from one
> document to another in such a way that tools are able to reformat it
> to apply whatever deranged nonsense of a citation format is required
> at the other end. I don't see that as existing.
>
> Pretty much every tool there is to manage citations sucks. I have
> tried end note and it sucks because it is an afterthought. The
> citation handling in Word is stovepiped to a few formats that are all
> stupid and few other things bother at all.
>
>
> It really should not be difficult, A 'database' of citations should
> require no more than an HTML document with a list of citations.
>
> It should be possible to drop in a citation by just typing in
> cite:rfc1234 or something similar.

For xml2rfc, we are very close to that (at least for standard references).

Best regards, Julian
Permalink | Reply |
headers
Paul E. Jones | 9 May 2012 15:19
Favicon

Re: IETF RFC format <-> W3C pubrules

On 5/9/2012 9:11 AM, Julian Reschke wrote:
>>> ...which means: little metadata or no metadata to rely on, right?
>>
>> I am not sure quite what you mean there.
>
> A way to programatically extract all the information xml2rfc captures 
> for us, such as author names, WG information, "updates"/"obsoletes" 
> information, references, ABNF, copyright status, ...

The RFC Editor publishes all of this metadata as an XML document that is 
independent of any RFC.  Why would we need to have this information 
inside the RFC itself?  And if we did, some information would still be 
lacking.  For example, if an RFC is updated or is made obsolete, the XML 
document published by the RFC Editor would contain that information, but 
an RFC document obviously cannot predict the future.

I have a tool (not xml2rfc) that provides this metadata to me based on 
the aforementioned XML document.  I don't see a need to have it somehow 
bound to the format of the RFC itself.

Paul
Permalink | Reply |
headers
Julian Reschke | 9 May 2012 15:28
Picon
Picon

Re: IETF RFC format <-> W3C pubrules

On 2012-05-09 15:19, Paul E. Jones wrote:
> On 5/9/2012 9:11 AM, Julian Reschke wrote:
>>>> ...which means: little metadata or no metadata to rely on, right?
>>>
>>> I am not sure quite what you mean there.
>>
>> A way to programatically extract all the information xml2rfc captures
>> for us, such as author names, WG information, "updates"/"obsoletes"
>> information, references, ABNF, copyright status, ...
>
> The RFC Editor publishes all of this metadata as an XML document that is
> independent of any RFC. Why would we need to have this information
> inside the RFC itself? And if we did, some information would still be

We don't need it in the RFC, but it's useful to have. It allows you to 
run checks *before* the RFC is published. For the same reason it's 
useful in Internet Drafts.

Furthermore, lots of the information I mentioned is *not* in the RFC 
database.

> ...

Best regards, Julian
Permalink | Reply |
headers
Phillip Hallam-Baker | 9 May 2012 15:34
Picon

Re: IETF RFC format <-> W3C pubrules

We would be much more likely to get widespread support for metadata
that is supported by tools if W3C, OASIS and IETF all agree to do the
same thing.

On Wed, May 9, 2012 at 9:28 AM, Julian Reschke <julian.reschke <at> gmx.de> wrote:
> On 2012-05-09 15:19, Paul E. Jones wrote:
>>
>> On 5/9/2012 9:11 AM, Julian Reschke wrote:
>>>>>
>>>>> ...which means: little metadata or no metadata to rely on, right?
>>>>
>>>>
>>>> I am not sure quite what you mean there.
>>>
>>>
>>> A way to programatically extract all the information xml2rfc captures
>>> for us, such as author names, WG information, "updates"/"obsoletes"
>>> information, references, ABNF, copyright status, ...
>>
>>
>> The RFC Editor publishes all of this metadata as an XML document that is
>> independent of any RFC. Why would we need to have this information
>> inside the RFC itself? And if we did, some information would still be
>
>
> We don't need it in the RFC, but it's useful to have. It allows you to run
> checks *before* the RFC is published. For the same reason it's useful in
> Internet Drafts.
>
> Furthermore, lots of the information I mentioned is *not* in the RFC
> database.
>
>> ...
>
>
> Best regards, Julian

--

-- 
Website: http://hallambaker.com/
Permalink | Reply |
headers
Leonard Rosenthol | 9 May 2012 15:34
Picon
Favicon

Re: IETF RFC format <-> W3C pubrules

You need it in the RFC (aka the published document) if you want it to be archived - since in that context, the
property of "completely stand-alone" applies.  

Leonard

-----Original Message-----
From: rfc-interest-bounces <at> rfc-editor.org [mailto:rfc-interest-bounces <at> rfc-editor.org] On
Behalf Of Julian Reschke
Sent: Wednesday, May 09, 2012 9:29 AM
To: Paul E. Jones
Cc: rfc-interest; Paul Hoffman; spec-prod <at> w3.org
Subject: Re: [rfc-i] IETF RFC format <-> W3C pubrules

On 2012-05-09 15:19, Paul E. Jones wrote:
> On 5/9/2012 9:11 AM, Julian Reschke wrote:
>>>> ...which means: little metadata or no metadata to rely on, right?
>>>
>>> I am not sure quite what you mean there.
>>
>> A way to programatically extract all the information xml2rfc captures 
>> for us, such as author names, WG information, "updates"/"obsoletes"
>> information, references, ABNF, copyright status, ...
>
> The RFC Editor publishes all of this metadata as an XML document that 
> is independent of any RFC. Why would we need to have this information 
> inside the RFC itself? And if we did, some information would still be

We don't need it in the RFC, but it's useful to have. It allows you to run checks *before* the RFC is published.
For the same reason it's useful in Internet Drafts.

Furthermore, lots of the information I mentioned is *not* in the RFC database.

> ...

Best regards, Julian
_______________________________________________
rfc-interest mailing list
rfc-interest <at> rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest
Permalink | Reply |
headers
Paul E. Jones | 9 May 2012 15:41
Favicon

Re: IETF RFC format <-> W3C pubrules


But we could always add metadata to an RFC published as an HTML document 
if there is something we need, regardless of the tool used to produce 
the RFC.

What is that metadata is needed in the RFC, though?  I'm at a loss for 
that.  I see the value in having it published separately, as it's 
something I can use.  The one piece of data I find most useful (what 
RFCs updated or replaced a given RFC) obviously could not be put into 
the RFC.

Paul

On 5/9/2012 9:34 AM, Leonard Rosenthol wrote:
> You need it in the RFC (aka the published document) if you want it to be archived - since in that context, the
property of "completely stand-alone" applies.
>
> Leonard
>
> -----Original Message-----
> From: rfc-interest-bounces <at> rfc-editor.org [mailto:rfc-interest-bounces <at> rfc-editor.org] On
Behalf Of Julian Reschke
> Sent: Wednesday, May 09, 2012 9:29 AM
> To: Paul E. Jones
> Cc: rfc-interest; Paul Hoffman; spec-prod <at> w3.org
> Subject: Re: [rfc-i] IETF RFC format<->  W3C pubrules
>
> On 2012-05-09 15:19, Paul E. Jones wrote:
>> On 5/9/2012 9:11 AM, Julian Reschke wrote:
>>>>> ...which means: little metadata or no metadata to rely on, right?
>>>> I am not sure quite what you mean there.
>>> A way to programatically extract all the information xml2rfc captures
>>> for us, such as author names, WG information, "updates"/"obsoletes"
>>> information, references, ABNF, copyright status, ...
>> The RFC Editor publishes all of this metadata as an XML document that
>> is independent of any RFC. Why would we need to have this information
>> inside the RFC itself? And if we did, some information would still be
> We don't need it in the RFC, but it's useful to have. It allows you to run checks *before* the RFC is
published. For the same reason it's useful in Internet Drafts.
>
> Furthermore, lots of the information I mentioned is *not* in the RFC database.
>
>> ...
> Best regards, Julian
> _______________________________________________
> rfc-interest mailing list
> rfc-interest <at> rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
Permalink | Reply |
headers
Phillip Hallam-Baker | 9 May 2012 15:55
Picon

Re: IETF RFC format <-> W3C pubrules

One way to address 90% of the issue issue would be to simply require:

1) The IETF publish all documents as HTML documents in a proper HTML
markup (i.e. one that uses proportional fonts, bold, italics,
different type styles to denote headings etc.)

2) It be possible to extract a XML2RFC format source from the HTML
document without loss of information.

3) That the HTML markup make use of the same microformat as the W3C
wherever that is possible.

That would seem to me to cover everything apart from the issue of
diagrams. In short I propose

1) Use the existing standard that EVERYONE else on the planet uses
2) Ensure support for legacy systems
3) Don't invent anything new just for the sake of it

I also propose collecting metrics:

* The IETF should measure the number of drafts etc. that are
downloaded in the HTML and caveman formats for cases where both are
available.

* Ten of the top twenty most commonly downloaded RFCs should be made
available in both formats to see whether this increases the number of
accesses.

For the measurement to be fair the caveman and HTML forms should have
equal prominence in the IETF tools. At present I have to download the
XML format and convert it myself by hand which makes it an unfair
comparison.
Permalink | Reply |
headers
Iljitsch van Beijnum | 9 May 2012 15:55
Favicon

Re: IETF RFC format <-> W3C pubrules

On 9 May 2012, at 15:41 , Paul E. Jones wrote:

> What is that metadata is needed in the RFC, though?  I'm at a loss for that.  I see the value in having it
published separately, as it's something I can use.  The one piece of data I find most useful (what RFCs
updated or replaced a given RFC) obviously could not be put into the RFC.

(Can you guys please not quote everything that came before? A little editing goes a long way.)

I think some of us, including myself, have been a bit careless using the word(s) "metadata" in this
discussion. What we need most of all is to mark up text that's already there as being the publication date,
an author, a reference to an RFC, etc. This allows for much more robust tools because this way we don't have
to guess at the meaning of something just from its place in the document.

On 9 May 2012, at 15:34 , Phillip Hallam-Baker wrote:

> We would be much more likely to get widespread support for metadata
> that is supported by tools if W3C, OASIS and IETF all agree to do the
> same thing.

Perhaps it would be useful to come up with the intersection of what all of these need and then standardize
those elements. I'm going to assume HTML as the basis for such a format. What's mostly needed here is class
and id definitions and an agreement on what subset of HTML to use. Each organization can then add more
esoteric stuff as needed, and at some point I'm sure common stylesheets and tools will start to appear once
thins settle down a bit.

As for the way forward for the RFC format, it's been a while since I saw anyone disagreeing with HTML. If we can
make some kind of transform between XML2RFC and a new HTML format (in both directions) we should be in a good
position to start some experimentation where people can write drafts in the new format and then use
HTML2XML2RFC to derive the current format. Then once we know what we want we really need we can refine the
new format to address the issues that exist today with XML2RFC. Coordination with OASIS and W3C can happen concurrently.
Permalink | Reply |
headers
Phillip Hallam-Baker | 9 May 2012 16:02
Picon

Re: IETF RFC format <-> W3C pubrules

On Wed, May 9, 2012 at 9:55 AM, Iljitsch van Beijnum <iljitsch <at> muada.com> wrote:

> As for the way forward for the RFC format, it's been a while since I saw anyone disagreeing with HTML. If we
can make some kind of transform between XML2RFC and a new HTML format (in both directions) we should be in a
good position to start some experimentation where people can write drafts in the new format and then use
HTML2XML2RFC to derive the current format. Then once we know what we want we really need we can refine the
new format to address the issues that exist today with XML2RFC. Coordination with OASIS and W3C can happen concurrently.

I suspect that the coordination need be little more than someone
making a list of proposals and someone at W3C who knows microformats
to say which already exist and which one to choose where there is a
choice.

--
Website: http://hallambaker.com/
Permalink | Reply |
headers
Paul E. Jones | 9 May 2012 16:38
Favicon

Re: IETF RFC format <-> W3C pubrules

On 5/9/2012 9:55 AM, Iljitsch van Beijnum wrote:
> On 9 May 2012, at 15:41 , Paul E. Jones wrote:
>
>> >  What is that metadata is needed in the RFC, though?  I'm at a loss for that.  I see the value in having it
published separately, as it's something I can use.  The one piece of data I find most useful (what RFCs
updated or replaced a given RFC) obviously could not be put into the RFC.
> (Can you guys please not quote everything that came before? A little editing goes a long way.)

Better?  Note that some HTML programs do not make this so easy.  This 
one I am using today does, but it's not my preferred client.

> I think some of us, including myself, have been a bit careless using the word(s) "metadata" in this
discussion. What we need most of all is to mark up text that's already there as being the publication date,
an author, a reference to an RFC, etc. This allows for much more robust tools because this way we don't have
to guess at the meaning of something just from its place in the document.

This makes sense.  I agree marking up text to identify important 
elements is reasonable.  We should identify what those are and decide 
what class values to assign.

Paul
Permalink | Reply |
headers
Leonard Rosenthol | 9 May 2012 16:22
Picon
Favicon

Re: IETF RFC format <-> W3C pubrules

The problem is that then you divorce the "source" material from the "published" material - which seems to be
an issue for some people.  

Document provenance is indeed an important concept and there are various groups studying that problem,
for different perspectives.

Leonard

-----Original Message-----
From: Paul E. Jones [mailto:paulej <at> packetizer.com] 
Sent: Wednesday, May 09, 2012 9:42 AM
To: Leonard Rosenthol
Cc: julian.reschke <at> gmx.de; rfc-interest; Paul Hoffman; spec-prod <at> w3.org
Subject: Re: [rfc-i] IETF RFC format <-> W3C pubrules

But we could always add metadata to an RFC published as an HTML document if there is something we need,
regardless of the tool used to produce the RFC.

What is that metadata is needed in the RFC, though?  I'm at a loss for that.  I see the value in having it
published separately, as it's something I can use.  The one piece of data I find most useful (what RFCs
updated or replaced a given RFC) obviously could not be put into the RFC.

Paul

On 5/9/2012 9:34 AM, Leonard Rosenthol wrote:
> You need it in the RFC (aka the published document) if you want it to be archived - since in that context, the
property of "completely stand-alone" applies.
>
> Leonard
>
> -----Original Message-----
> From: rfc-interest-bounces <at> rfc-editor.org 
> [mailto:rfc-interest-bounces <at> rfc-editor.org] On Behalf Of Julian 
> Reschke
> Sent: Wednesday, May 09, 2012 9:29 AM
> To: Paul E. Jones
> Cc: rfc-interest; Paul Hoffman; spec-prod <at> w3.org
> Subject: Re: [rfc-i] IETF RFC format<->  W3C pubrules
>
> On 2012-05-09 15:19, Paul E. Jones wrote:
>> On 5/9/2012 9:11 AM, Julian Reschke wrote:
>>>>> ...which means: little metadata or no metadata to rely on, right?
>>>> I am not sure quite what you mean there.
>>> A way to programatically extract all the information xml2rfc 
>>> captures for us, such as author names, WG information, "updates"/"obsoletes"
>>> information, references, ABNF, copyright status, ...
>> The RFC Editor publishes all of this metadata as an XML document that 
>> is independent of any RFC. Why would we need to have this information 
>> inside the RFC itself? And if we did, some information would still be
> We don't need it in the RFC, but it's useful to have. It allows you to run checks *before* the RFC is
published. For the same reason it's useful in Internet Drafts.
>
> Furthermore, lots of the information I mentioned is *not* in the RFC database.
>
>> ...
> Best regards, Julian
> _______________________________________________
> rfc-interest mailing list
> rfc-interest <at> rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
Permalink | Reply |
headers
Phillip Hallam-Baker | 9 May 2012 15:33
Picon

Re: IETF RFC format <-> W3C pubrules

The secretariat can even pull the data from non XML documents.

HTML has exactly the same expressive power as the XML2RFC data format.
If you want to you can even use XML2RFC to generate your HTML source.

In fact one of the design constraints we might use is that it must be
possible to round trip from XML2RFC to HTML and back without losing
information.

XML2RFC is not beyond reproach as a doc format. In fact I find it
pretty awful. There is really no reason that a <list> has to be in a
<t>. It is inconsistent with text sometimes turning up in attributes
and sometimes not.

To encode the same information in a HTML document the class= attribute
should be used. This then allows the stylesheet to be used to expose
(or hide) the relevant information. If you are using a good HTML
editor you can even edit and see the stylesheet changes automatically.

<p class="author"><span class="firstname">Phillip</span><span
class="lastname>Hallam-Baker></p>

<h1 class="abstract">Abstract</h1>

Since there is very little metadata in RFCs, I don't see much of a problem here.

On Wed, May 9, 2012 at 9:19 AM, Paul E. Jones <paulej <at> packetizer.com> wrote:
> On 5/9/2012 9:11 AM, Julian Reschke wrote:
>>>>
>>>> ...which means: little metadata or no metadata to rely on, right?
>>>
>>>
>>> I am not sure quite what you mean there.
>>
>>
>> A way to programatically extract all the information xml2rfc captures for
>> us, such as author names, WG information, "updates"/"obsoletes" information,
>> references, ABNF, copyright status, ...
>
>
> The RFC Editor publishes all of this metadata as an XML document that is
> independent of any RFC.  Why would we need to have this information inside
> the RFC itself?  And if we did, some information would still be lacking.
>  For example, if an RFC is updated or is made obsolete, the XML document
> published by the RFC Editor would contain that information, but an RFC
> document obviously cannot predict the future.
>
> I have a tool (not xml2rfc) that provides this metadata to me based on the
> aforementioned XML document.  I don't see a need to have it somehow bound to
> the format of the RFC itself.
>
> Paul
>

--

-- 
Website: http://hallambaker.com/
Permalink | Reply |
headers
Joe Hildebrand | 9 May 2012 18:03
Picon
Favicon
Gravatar

Re: IETF RFC format <-> W3C pubrules

On 5/9/12 6:57 AM, "Phillip Hallam-Baker" <hallam <at> gmail.com> wrote:

>> ...which means: little metadata or no metadata to rely on, right?
> 
> I am not sure quite what you mean there.

A really good example I've heard is "I want to pull out all of the ABNF and
run it through a separate tool to ensure it is correct".  Imagine similar
markup for ASN.1 descriptions, etc.

Metadata doesn't mean just author and publish date.

--

-- 
Joe Hildebrand
Permalink | Reply |
headers
Julian Reschke | 9 May 2012 18:11
Picon
Picon

Re: IETF RFC format <-> W3C pubrules

On 2012-05-09 18:03, Joe Hildebrand wrote:
> On 5/9/12 6:57 AM, "Phillip Hallam-Baker"<hallam <at> gmail.com>  wrote:
>
>>> ...which means: little metadata or no metadata to rely on, right?
>>
>> I am not sure quite what you mean there.
>
> A really good example I've heard is "I want to pull out all of the ABNF and
> run it through a separate tool to ensure it is correct".  Imagine similar
> markup for ASN.1 descriptions, etc.
>
> Metadata doesn't mean just author and publish date.

Another one is: "I want to mechanically check that all IETF and W3C 
references are up-to-date".

Best regards, Julian
Permalink | Reply |
headers
Phillip Hallam-Baker | 9 May 2012 18:13
Picon

Re: IETF RFC format <-> W3C pubrules

Yes, I agree that would be very useful stuff to have when considering
a new format.

It is pretty easy to add in with HTML. Just define an XML attribute
and drop it in. It would probably be some variant of class

<p class="ABNF">
stuff....
</p>

On Wed, May 9, 2012 at 12:03 PM, Joe Hildebrand <jhildebr <at> cisco.com> wrote:
> On 5/9/12 6:57 AM, "Phillip Hallam-Baker" <hallam <at> gmail.com> wrote:
>
>>> ...which means: little metadata or no metadata to rely on, right?
>>
>> I am not sure quite what you mean there.
>
> A really good example I've heard is "I want to pull out all of the ABNF and
> run it through a separate tool to ensure it is correct".  Imagine similar
> markup for ASN.1 descriptions, etc.
>
> Metadata doesn't mean just author and publish date.
>
> --
> Joe Hildebrand
>

--

-- 
Website: http://hallambaker.com/
Permalink | Reply |
headers
Sandro Hawke | 11 May 2012 18:38
Picon
Favicon
Gravatar

Re: [rfc-i] IETF RFC format <-> W3C pubrules

On Wed, 2012-05-09 at 08:57 -0400, Phillip Hallam-Baker wrote:
...
> For example, it should be possible to cut an paste a citation from one
> document to another in such a way that tools are able to reformat it
> to apply whatever deranged nonsense of a citation format is required
> at the other end. I don't see that as existing.
> 
> Pretty much every tool there is to manage citations sucks. I have
> tried end note and it sucks because it is an afterthought. The
> citation handling in Word is stovepiped to a few formats that are all
> stupid and few other things bother at all.
> 
> 
> It really should not be difficult, A 'database' of citations should
> require no more than an HTML document with a list of citations.

Just following on this thread, here's a somewhat extreme strawman,
which probably shows my W3C bias.

How about having the citations and references section all generated
automatically?  Have the generator use:

  1. The HTML links going out of the document

  2. Some indicator of whether a particular outbound link target
     should not be considered a citation, or if it is one, whether it
     should be considered non-normative.  In HTML this could be done
     with a class attribute; alternatively, it could be done via a
     list of URLs somewhere in the document metadata.

  3. Some URL->Citation databases.  Ideally, all the citation
     information could be found by dereferencing the URL and looking
     at standard metadata.  Until then, some databases can backfill
     that information.  I'd hope we could suffice with one of these
     databases at W3C and one for the RFCs.  I'd hope they could use
     the same format.

In the case of wanting to cite something which has no plausible URL, I
suggest one be created, giving some useful information about the cited
item for people who do not have access to a suitable library.

   -- Sandro
Permalink | Reply |
headers
Phillip Hallam-Baker | 11 May 2012 20:11
Picon

Re: IETF RFC format <-> W3C pubrules

OK, this is getting a little far off the course but what you are
highlighing is that compiling citations is really the sort of project
where a network effort can really pay off.

And don't just think of this for citations either. The big stumbling
block for semantic Web as I see it is a chicken and egg problem.
People don't do metadata when it isn't used. People can't use metadata
when it isn't present. When the CD spec was first developed, they had
a scheme there to encode the track names. It wasn't ever used until
the rippers came along and so almost nobody bothered to fill it.

A group effort does not need to be a permanent fixture, it could
merely be transitional, until people start filling in the metadata
themselves.

Let us imagine that there are multiple services that host citation
databases and I can open an account at any one I choose (that accepts
me). The services may or may not share data between each other.

A citation generator tool would go over the source of a document and
attempt to map any form of citation it understood (URL, paper name,
etc) to a citation by querying the service(s) that the user had
configured.

Depending on the configuration of the tool I could then complete the
references by entering any remaining unresolved references in my
document or by logging into my account and updating them there. In
either case I could choose to make my citation data available to other
people or not. Having the 'or not' piece being essential since keeping
grotty data out of a database is always more important than simply
aggregating poor data.

A tool could be made to work without accounts of course, but accounts
make things much easier as that allows the citation search to be
personalized. Expanding RFC822 to a citation to the IETF doc is pretty
obvious for someone like me but may not be for someone in a different
field.

Using accounts also makes it possible to write a tool that runs
without requiring user input. I really loathe tools that try to lock
me into their particular workflow. Like all those tools that offer to
download pictures from a flash card and save them on the hard drive
that then try to force you to look at the pictures and catalog them at
the same time.

Rather than rush to a spec though, I think this should be thought of
as something we might build into a spec production toolset for
internal SDO use but with a view to opening it up for wider use later
on.

On Fri, May 11, 2012 at 12:38 PM, Sandro Hawke <sandro <at> w3.org> wrote:
> On Wed, 2012-05-09 at 08:57 -0400, Phillip Hallam-Baker wrote:
> ...
>> For example, it should be possible to cut an paste a citation from one
>> document to another in such a way that tools are able to reformat it
>> to apply whatever deranged nonsense of a citation format is required
>> at the other end. I don't see that as existing.
>>
>> Pretty much every tool there is to manage citations sucks. I have
>> tried end note and it sucks because it is an afterthought. The
>> citation handling in Word is stovepiped to a few formats that are all
>> stupid and few other things bother at all.
>>
>>
>> It really should not be difficult, A 'database' of citations should
>> require no more than an HTML document with a list of citations.
>
> Just following on this thread, here's a somewhat extreme strawman,
> which probably shows my W3C bias.
>
> How about having the citations and references section all generated
> automatically?  Have the generator use:
>
>  1. The HTML links going out of the document
>
>  2. Some indicator of whether a particular outbound link target
>     should not be considered a citation, or if it is one, whether it
>     should be considered non-normative.  In HTML this could be done
>     with a class attribute; alternatively, it could be done via a
>     list of URLs somewhere in the document metadata.
>
>  3. Some URL->Citation databases.  Ideally, all the citation
>     information could be found by dereferencing the URL and looking
>     at standard metadata.  Until then, some databases can backfill
>     that information.  I'd hope we could suffice with one of these
>     databases at W3C and one for the RFCs.  I'd hope they could use
>     the same format.
>
> In the case of wanting to cite something which has no plausible URL, I
> suggest one be created, giving some useful information about the cited
> item for people who do not have access to a suitable library.
>
>   -- Sandro
>
>

--

-- 
Website: http://hallambaker.com/
Permalink | Reply |
headers
Larry Masinter | 17 May 2012 04:05
Picon
Favicon
Gravatar

Re: IETF RFC format <-> W3C pubrules


> Just following on this thread, here's a somewhat extreme strawman,
> which probably shows my W3C bias.

It should be a requirement that the authoring format => distribution format process *can* be accomplished
offline.  I think this might be as simple as allowing citation expansions to be downloaded when online.

Also: citations should always be to dated links, and the process of updating a citation to the "latest"
version based on URI to a location that is updated would encourage people to produce documents without
actually reviewing the updates. While sometimes that's warranted (when the citer and cited are by the
same author and are being prepared at the same time), but generally it isn't.

Both IETF and W3C struggle with updating citations, and I think the requirements are similar.

There is a "citation checker" tool for reviewing document citations, adding the ability to automatically
check citations seems like a requirement that is currently met, and that any updates should preserve.

Larry
--
http://larry.masinter.net
Permalink | Reply |
headers
Sandro Hawke | 11 May 2012 18:45
Picon
Favicon
Gravatar

Re: IETF RFC format <-> W3C pubrules

[re-sending, now that I'm subscribed to rdf-interest.  I'm not sure how
you thought two lists could talk to each other, Larry, when one of them
refuses postings from people not already on it...]

On Wed, 2012-05-09 at 08:57 -0400, Phillip Hallam-Baker wrote:
...
> For example, it should be possible to cut an paste a citation from one
> document to another in such a way that tools are able to reformat it
> to apply whatever deranged nonsense of a citation format is required
> at the other end. I don't see that as existing.
> 
> Pretty much every tool there is to manage citations sucks. I have
> tried end note and it sucks because it is an afterthought. The
> citation handling in Word is stovepiped to a few formats that are all
> stupid and few other things bother at all.
> 
> 
> It really should not be difficult, A 'database' of citations should
> require no more than an HTML document with a list of citations.

Just following on this thread, for now, here's a somewhat extreme
strawman, which probably shows my W3C bias.

How about having the citations and references section all generated
automatically?  Have the generator use:

  1. The HTML links going out of the document

  2. Some indicator of whether a particular outbound link target
     should not be considered a citation, or if it is one, whether it
     should be considered non-normative.  In HTML this could be done
     with a class attribute; alternatively, it could be done via a
     list of URLs somewhere in the document metadata.

  3. Some URL->Citation databases.  Ideally, all the citation
     information could be found by dereferencing the URL and looking
     at standard metadata.  Until then, some databases can backfill
     that information.  I'd hope we could suffice with one of these
     databases at W3C and one for the RFCs.  I'd hope they could use
     the same format.

In the case of wanting to cite something which has no plausible URL, I
suggest one be created, giving some useful information about the cited
item for people who do not have access to a suitable library.

   -- Sandro
Permalink | Reply |
headers
Paul Hoffman | 9 May 2012 16:20

Re: IETF RFC format <-> W3C pubrules

On May 9, 2012, at 4:12 AM, Phillip Hallam-Baker wrote:

> I note that as is often the case when the blatantly obvious is said we
> have disagreement by unresolved reference.
> 
> If you can't give a reason for a disagreement then you should probably
> think a bit before posting and wait until you can state what the
> disagreement is.

Many proposals other than "HTML as the canonical form" were made at the IETF meeting in Paris. The fact that
you were not there does not mean that they were not proposed.

--Paul Hoffman
Permalink | Reply |
headers
Iljitsch van Beijnum | 9 May 2012 16:23
Favicon

Not HTML? was: Re: IETF RFC format <-> W3C pubrules

On 9 May 2012, at 16:20 , Paul Hoffman wrote:

> Many proposals other than "HTML as the canonical form" were made at the IETF meeting in Paris.

Can the people who made these proposals let us know if they still stand behind them in light of the past weeks
of discussion?
Permalink | Reply |
headers
Phillip Hallam-Baker | 9 May 2012 17:16
Picon

Re: IETF RFC format <-> W3C pubrules

This is now the second post where you have failed to mention what they
are or give a justification for continuing to consider them.

I have invariably found that people who claim that there is a really
good reason to take a course of action that they refuse to disclose
despite requests to do so have no real argument to make.

IETF process is that decisions are made on the Internet and not in
meetings. If people think those reasons are valid they should write
'em up and post here.

On Wed, May 9, 2012 at 10:20 AM, Paul Hoffman <paul.hoffman <at> vpnc.org> wrote:
> On May 9, 2012, at 4:12 AM, Phillip Hallam-Baker wrote:
>
>> I note that as is often the case when the blatantly obvious is said we
>> have disagreement by unresolved reference.
>>
>> If you can't give a reason for a disagreement then you should probably
>> think a bit before posting and wait until you can state what the
>> disagreement is.
>
> Many proposals other than "HTML as the canonical form" were made at the IETF meeting in Paris. The fact that
you were not there does not mean that they were not proposed.
>
> --Paul Hoffman
>

--

-- 
Website: http://hallambaker.com/
Permalink | Reply |
headers
Paul Hoffman | 9 May 2012 17:31

Re: IETF RFC format <-> W3C pubrules

On May 9, 2012, at 8:16 AM, Phillip Hallam-Baker wrote:

> This is now the second post where you have failed to mention what they
> are or give a justification for continuing to consider them.
> 
> I have invariably found that people who claim that there is a really
> good reason to take a course of action that they refuse to disclose
> despite requests to do so have no real argument to make.

"Refuse" is just typical trolling. Heather Flanagan, the RSE, has told us what her desired process is, and
many of us intend to follow it. When she asks for written proposals (a follow-on to her request for
presented proposals that many of us made in Paris), many of us intend to do so.

> IETF process is that decisions are made on the Internet and not in
> meetings. If people think those reasons are valid they should write
> 'em up and post here.

Note that this has *nothing* to do with IETF process. As has been made clear over the past few years on this
very list, the RFC Series is not bound by the IETF process at all.

--Paul Hoffman
Permalink | Reply |
headers
Phillip Hallam-Baker | 9 May 2012 17:40
Picon

Re: IETF RFC format <-> W3C pubrules

Note: a third non responsive response.

Are you actually going to answer the question?

What are the other formats that you think should be considered and why?

I suggest that before responding with a fourth non-response you
actually address the question I and others asked.

I am not interested in you being a process Pharisee either.

On Wed, May 9, 2012 at 11:31 AM, Paul Hoffman <paul.hoffman <at> vpnc.org> wrote:
> On May 9, 2012, at 8:16 AM, Phillip Hallam-Baker wrote:
>
>> This is now the second post where you have failed to mention what they
>> are or give a justification for continuing to consider them.
>>
>> I have invariably found that people who claim that there is a really
>> good reason to take a course of action that they refuse to disclose
>> despite requests to do so have no real argument to make.
>
> "Refuse" is just typical trolling. Heather Flanagan, the RSE, has told us what her desired process is, and
many of us intend to follow it. When she asks for written proposals (a follow-on to her request for
presented proposals that many of us made in Paris), many of us intend to do so.
>
>> IETF process is that decisions are made on the Internet and not in
>> meetings. If people think those reasons are valid they should write
>> 'em up and post here.
>
> Note that this has *nothing* to do with IETF process. As has been made clear over the past few years on this
very list, the RFC Series is not bound by the IETF process at all.
>
> --Paul Hoffman
>

--

-- 
Website: http://hallambaker.com/
Permalink | Reply |
headers
Joe Hildebrand | 9 May 2012 18:01
Picon
Favicon
Gravatar

Re: IETF RFC format <-> W3C pubrules


On 5/9/12 9:40 AM, "Phillip Hallam-Baker" <hallam <at> gmail.com> wrote:

> Note: a third non responsive response.
> 
> Are you actually going to answer the question?
> 
> What are the other formats that you think should be considered and why?

https://datatracker.ietf.org/meeting/83/materials.html#wg-rfcform

- Just add UTF-8
- Just add URLs
- TeX input
- PDF/A

Note: Personally, I think all of these but the TeX input do not meet the
requirements for which we're starting to see a little bit of emerging
consensus.  I'm only interested in the HTML output of the TeX input, to
ensure that it meets the requirements.  As such, TeX could be just one more
precursor toolchain for those that like it.

--

-- 
Joe Hildebrand
Permalink | Reply |
headers
Paul Hoffman | 9 May 2012 18:11

Re: IETF RFC format <-> W3C pubrules

On May 9, 2012, at 9:01 AM, Joe Hildebrand wrote:

> https://datatracker.ietf.org/meeting/83/materials.html#wg-rfcform
> 
> - Just add UTF-8
> - Just add URLs
> - TeX input
> - PDF/A

FWIW, quoting just from the title of the slideware doesn't do justice to the actual proposals. At least one
of those was significantly different than its title.

--Paul Hoffman
Permalink | Reply |
headers
Joe Hildebrand | 9 May 2012 18:16
Picon
Favicon
Gravatar

Re: IETF RFC format <-> W3C pubrules

On 5/9/12 10:11 AM, "Paul Hoffman" <paul.hoffman <at> vpnc.org> wrote:

> On May 9, 2012, at 9:01 AM, Joe Hildebrand wrote:
> 
>> https://datatracker.ietf.org/meeting/83/materials.html#wg-rfcform
>> 
>> - Just add UTF-8
>> - Just add URLs
>> - TeX input
>> - PDF/A
> 
> FWIW, quoting just from the title of the slideware doesn't do justice to the
> actual proposals. At least one of those was significantly different than its
> title.

I apologize for the gross simplification being misleading.  I encourage
folks who want to understand what has been discussed to read the slides and
the minutes. 

--

-- 
Joe Hildebrand
Permalink | Reply |
headers
Phillip Hallam-Baker | 9 May 2012 19:16
Picon

Re: IETF RFC format <-> W3C pubrules

I see no reason to apologize

The author of the document is in this thread and could have clarified
the matter if he wanted to. In fact he is the one refusing to explain
himself.

I think what he was trying to do here was to assert that no decision
had been made so he could continue to claim support for his own scheme
which seems to have no interest here.

I don't see a need to cater to people who want to play silly games
like that. Lets argue the case on the merits rather than appeal to
irrelevant process claims.

My process is to focus on the proposals and ignore process.

On Wed, May 9, 2012 at 12:16 PM, Joe Hildebrand <jhildebr <at> cisco.com> wrote:
> On 5/9/12 10:11 AM, "Paul Hoffman" <paul.hoffman <at> vpnc.org> wrote:
>
>> On May 9, 2012, at 9:01 AM, Joe Hildebrand wrote:
>>
>>> https://datatracker.ietf.org/meeting/83/materials.html#wg-rfcform
>>>
>>> - Just add UTF-8
>>> - Just add URLs
>>> - TeX input
>>> - PDF/A
>>
>> FWIW, quoting just from the title of the slideware doesn't do justice to the
>> actual proposals. At least one of those was significantly different than its
>> title.
>
> I apologize for the gross simplification being misleading.  I encourage
> folks who want to understand what has been discussed to read the slides and
> the minutes.
>
> --
> Joe Hildebrand
>
> _______________________________________________
> rfc-interest mailing list
> rfc-interest <at> rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

--

-- 
Website: http://hallambaker.com/
Permalink | Reply |
headers
Phillip Hallam-Baker | 9 May 2012 18:17
Picon

Re: IETF RFC format <-> W3C pubrules

We can certainly do everything with tex that we can do with HTML and
everything we want with HTML.

Problem with TeX is that it is a Turing complete language which means
that it provides way more flexibility than we would want. I would
expect that we ended up using LaTeX which is not quite the same thing.

For my thesis I had examples in TeX that compiled and executed during
the document production process. That is baaaaad precedent.

On Wed, May 9, 2012 at 12:01 PM, Joe Hildebrand <jhildebr <at> cisco.com> wrote:
>
>
>
> On 5/9/12 9:40 AM, "Phillip Hallam-Baker" <hallam <at> gmail.com> wrote:
>
>> Note: a third non responsive response.
>>
>> Are you actually going to answer the question?
>>
>> What are the other formats that you think should be considered and why?
>
> https://datatracker.ietf.org/meeting/83/materials.html#wg-rfcform
>
> - Just add UTF-8
> - Just add URLs
> - TeX input
> - PDF/A
>
> Note: Personally, I think all of these but the TeX input do not meet the
> requirements for which we're starting to see a little bit of emerging
> consensus.  I'm only interested in the HTML output of the TeX input, to
> ensure that it meets the requirements.  As such, TeX could be just one more
> precursor toolchain for those that like it.
>
> --
> Joe Hildebrand
>

--

-- 
Website: http://hallambaker.com/
Permalink | Reply |
headers
Martin Rex | 10 May 2012 16:58
Picon
Favicon

Re: IETF RFC format <-> W3C pubrules

Phillip Hallam-Baker wrote:
> 
> This is now the second post where you have failed to mention what they
> are or give a justification for continuing to consider them.
> 
> I have invariably found that people who claim that there is a really
> good reason to take a course of action that they refuse to disclose
> despite requests to do so have no real argument to make.
> 
> IETF process is that decisions are made on the Internet and not in
> meetings. If people think those reasons are valid they should write
> 'em up and post here.

You're confusing some things here.  For cross-area topics, the
discussion during plenaries matter *SIGNIFICANTLY* more than discussion
on ietf-discuss or any other IETF discussion list, since they actively
reach a much larger fraction of the active IETF participants.

Example: "The Danvers Doctrine"
  http://tools.ietf.org/html/rfc3365#section-6

For working group session at IETF meeting, gauging consensus of the
room by various means, including show-of-hands or humming is also a
very regular and appropriate IETF process tool.  But the difference
with WGs is, that consensus gauging on IETF meetings will need to
be confirmed on the IETF mailing list.

The huge advantage of RFCs in ASCII is not only that they still work
fine 30 years after publication, but that they also work fine during
EMail discussions (we do not need HTML Email for discussing sections
of the documents), they work fine in the Errata process, and most
importantly, they work fine in the "diff two different versions of
the document", the 2-column side-by-side comparison at tools.ietf.org.

btw. checking frequency of online access to see which format is
more popular gives meaningless results.  During discussions on IETF
mailing lists, I use URLs to the tools-html format, because it
allows to point to sections _and_ alternatively to pages(!), and the
latter is often necessary for long sections or long appendixes.

For reading RFCs, I often use the downloaded, plain ascii version instead.
I have a local mirror of all RFCs and all I-Ds, and I sometimes use
"grep" on it...

-Martin
Permalink | Reply |
headers
Phillip Hallam-Baker | 9 May 2012 13:06
Picon

Re: FW: IETF RFC format <-> W3C pubrules

I have worked with W3C since the very start. There has been one format
from start to finish. It has always been HTML.

HTML has developed over time and there have been tools to check nits.
But those appeared in W3C before they appeared in IETF.

The RFC2XML tool is a one off because the only thing it is good for is
to make RFCs. There is a lot more interest in making tools that
produce HTML because that is a format people like to use rather than
hate the sight of.

On Tue, May 8, 2012 at 9:51 PM, Bjoern Hoehrmann <derhoermi <at> gmx.net> wrote:
> * Iljitsch van Beijnum wrote:
>>On 8 May 2012, at 20:20 , Larry Masinter wrote:
>>> One of the tools is ReSpec.js  http://dev.w3.org/2009/dap/ReSpec.js/documentation.html
>>> which might be adaptable for IETF use.
>>
>>Although it would seem to make sense for the two to work together,
>>wouldn't it be a huge liability for both of them to depend on the other
>>for something so crucial?
>
> RFC 2629 (the xml2rfc format) has been around for about as long as I
> have been involved with the W3C and the IETF. `xml2rfc` is still alive
> and kicking, with very broad adoption. In contrast, the W3C has used
> any number of formats and toolchains during the period. As the people
> who made or maintained the formats and toolchains lose interest, the
> formats and the toolchains die "quickly". I'd suggest to keep in mind
> that the IETF output is an order of magnitude greater than that of the
> W3C.
>
> The W3C is also unlikely to coordinate tool development with non-W3C
> parties. For instance, HTML Tidy http://tidy.sf.net/ originated there,
> but maintenance of the tool became a problem, so a couple of people,
> including myself, took over maintenance and development in form of a
> SourceForge project. The W3C showed no interest in that over the years
> until last year, when I published a patch for rudimentary "HTML5" sup-
> port. Then the W3C took the latest sources and my patch, and created a
> fork, publicized it, and has since "maintained" the fork in a manner
> incompatible with established practises and goals of the SourceForge
> project. The W3C made no attempt whatsoever to announce, discuss, or
> otherwise coordinate their fork with the HTML Tidy project, including
> no attempts to express dissatisfaction prior to their hostile take-
> over. And while I very explicitly asked for feedback when I published
> my patch for "HTML5" support they used to create their fork -- and they
> certainly seem to have found issues with it -- no feedback ever made
> its way into my inbox.
>
> So I would not see this as a "huge liability", just as, plainly, silly.
> --
> Björn Höhrmann · mailto:bjoern <at> hoehrmann.de · 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/
> _______________________________________________
> rfc-interest mailing list
> rfc-interest <at> rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

--

-- 
Website: http://hallambaker.com/
Permalink | Reply |
headers
Phillip Hallam-Baker | 9 May 2012 13:02
Picon

Re: FW: IETF RFC format <-> W3C pubrules

I see no problem whatsoever.

They are bot standards organizations, this is a standard. W3C has put
vastly more expertise into this problem than IETF has ever done or
could hope to.

Instead of talking about accessibility W3C has actual experts who have
studied the field and talk to actual people with actual disabilities.

All that would be required for IETF to adopt the W3C pubrules wold be
an IETF stylesheet.

On Tue, May 8, 2012 at 2:24 PM, Iljitsch van Beijnum <iljitsch <at> muada.com> wrote:
> On 8 May 2012, at 20:20 , Larry Masinter wrote:
>
>> Here’s a quick summary:
>
> Thanks, I'll read up when I get a change. However:
>
>> One of the tools is ReSpec.js  http://dev.w3.org/2009/dap/ReSpec.js/documentation.html which
might be adaptable for IETF use.
>
> Although it would seem to make sense for the two to work together, wouldn't it be a huge liability for both of
them to depend on the other for something so crucial?
> _______________________________________________
> rfc-interest mailing list
> rfc-interest <at> rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

--

-- 
Website: http://hallambaker.com/
Permalink | Reply |
headers
Liam R E Quin | 29 Apr 2012 06:44
Picon
Favicon

Re: IETF RFC format <-> W3C pubrules

On Sat, 2012-04-28 at 20:50 -0700, Larry Masinter wrote:
[...]
> I think it is feasible and would be a great breakthrough if IETF
> and W3C specification formats could converge.

+1

Liam

--

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Permalink | Reply |

Gmane