RSE Wiki Archive

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
Attendees: Julian, Nevil, Paul, Joe, Tony, Alice, Robert

Absent: Adam, Dave, Teda. Agenda bash0. Administrivia
    - Next call scheduled for 26 June

1. Status of existing drafts
   - xml2rfc v2
A new draft has been submitted; made a fix re: lists style inheritance; very close to having something will be ready to review. Can ask for an early GenART review now.

The other open thing is the terminology question which we will cover in the v3 discussion.

   - PDF
     * created from XML, should look more like HTML than TXT
Is this good enough to post to the data tracker?

   - SVG
Has been working on the SVG checking program. Allowing people to use whatever package they want to to produce SVG and run it through the checker with a “write a new file” option set should work. The XML namespace - some of the packages pull in files with their particular definition of attributes in them, and then use them throughout the file. We have to allow the ones that come from W3C, but we should probably pull out any that don’t come from W3C - is that reasonable? Yes, but we can’t just rely on the the name to indicate what is from W3C.

(Tony) how much additional effort to turn the checker into a minimizer? Nevil has already done most of that.

   - HTML
     * profile for v3 or general document?
(Paul) is this draft meant to be a guide for the tool maker about what is supposed to come out? (Joe) what are the other choices? (Paul) That this is what a good HTML-ized RFC should look like that might not start from the XML. (Joe) don’t see the difference. (Paul) We would start by changing the language a bit to remove the 2119 language. (Robert) makes me happier too, because want to just be able to point to this.

(Paul) Other related things: the canonical XML is now for both drafts and RFCs, and assume we want identical HTML output for the two of them (other than obvious header differences)? (Joe) we don’t have as much control over why the I-D format will be, other than to offer suggestions. If the tool is going to output this kind of HTML, and the tool is also used for the draft processor, it will put out the same HTML. (Joe) it might have the same markup, but we can’t necessary require that.

(Paul) do I talk about the draft processor in v3? Heather needs to get that clear soon about when we talk about processing canonical XML as for drafts, do we talk about that in the v3 doc. Right now the I-D stuff is in an appendix with a note that it will be moved somewhere someday, and this needs to resolved. This needs to be resolved for the HTML and PDF as well.

(Paul) Did we come to agreement on the text-based thing; will this format lose text that should be seen if it is processed through one of the common text based browsers? Paul or Joe to come up with better wording to indicate this should be readable through a plain text browser (but it doesn’t have to be pretty). We just need to not lose text. (Joe) Places where in the prototypes was using CSS to insert text is not cool. This is an interesting requirement because of how it impacts the CSS.

(Paul) Section 3.3.6-3.3.7, 3.3.3 talk about how to show packet formats, ascii art, etc - this implies you are going to use a figure. There is nothing special about the HTML of that, so we shouldn’t be talking about artwork in multiple places. (Joe) Generally, yes, but for each of the specific kinds of art work, should talk about how they are rendered. In particular for SVG, figuring out what the alt text should look like. It is a question of how to get he SVG into the HTML, so that if you are not going to render the SVG, some text will show up. For example, you may have to wrap an object tag around that. Paul will propose collapsing all the art things into one section to describe what it needs to do. (Nevil) there will only be a few special cases that fit with the idea of automated ways to produce text. Complicated diagrams will involve write ups.

(Paul) 3.2.12 reference format. (Julian) there are multiple ways to do this, and there are few tools that make use of this. Recommend we leave this alone unless we have a use case for this. (Joe) if we have semantic markup in the XML, would hate to lose it in the HTML. (Paul) we have multiple styles of markup in the XML to get the same output, which makes picking one for HTML problematic. (Julian) What kind of format would you like to be in there? (Joe) if there were a micro-format for bibliographic data, that’s what I would like, but there isn’t one far enough along to use. Just doing spans copying the XML elements…? (Julian) what is in the HTML as text is already a transformation of what is in the XML. (Joe) suggesting that as you copy from an element in the XML into wherever it ends up in the HTML, surround that text with a span element and add a class. (Julian) how would that help with author names, since sometimes they might be first name, last name or last name, first name? You would have to mark up last names and initials separately. This is a lot of overhead for something with limited use. (Paul) agree with Julian; having a div with a unique ID for each reference, where that unique ID will duplicate the link into the reference.. (Joe) don’t understand the overhead problem - we are not trying to save bytes, it won’t look different to users, and the complexity in tooling is not that high since there is no semantic processing. (Julian) we had decided that the XML format does not need to run through the HTML. The XML format has all the semantic information that we have, and reluctant to say here are special cases about copying the semantic information into HTML markup. IF there were standard formats, that would be interesting, but just for the heck of it? (Joe) we are putting a great deal of semantic information in the HTMl already. (Julian) the point of the semantic markup is to allow us to do the right thing with browsers and screen readers. **taking this to the list

Paul to send HF an update with a bunch of diffs, HF to post the changes in anew draft next week

   - plain text
     * ToC - yes or no? (current answer = yes)
This is just the doc structure - like the ToC we have except with the series of dots removed and page numbers removed; indentation would remain the same

     * pagination and associated running headers/footers - yes or no? (current answer = no)

There are a number of people who will strongly want pagination because their current tools depend on it
(Joe) the tools will break because of BOMs and non-ASCII characters as well.
(Julian) Getting rid of pagination will be good because it gets rid of a bunch of work to get the pagination correct. If we have one output format that has pages, then we will still have pages
(Robert) the thing we can do right now, if there is a middle ground of these people, what can we provide? We don’t have to produce exactly the old format, but there should be a middle ground somewhere.
(Joe) what we have talked about in the past - if you want to maintain compatibility, is the text format getting uglier intentionally. Instead of unicode characters, you see their names with syntax to set them off.
(Julian) the other thing we should have as answers to needing page breaks; if we decide to put in page breaks, we will not put in effort to properly handle widows and orphans. There will be no future manual tuning of vertical whitespace.

(Paul) this is why we talked about having two text outputs - one text format for people who have these tools, and another text format that is sort of readable. We decided not to do that since not to many people would read this anyway and having two text formats would be confusing. But it remains an option for those people who need the old format for tools.

(Joe) could be convinced to do two forms or ugly text.

(Julian) do we have evidence of tools that require page breaks? (Alice) we use page breaks like the IESG does to measure work load, and do work allocation that way. (Julian) we could find a different metric. (Robert) I need to know what that metric is. (Paul) line count divided by 58? (Robert) then you have to define line. (Joe) word count divided by some metric of average per page.  

(Robert) suggest not having a publication format that is a paginated text, but instead having a community-supported tool that they can run over the unpaginated version to bust it back to the old shape. (Julian) could we ask the people who think they need pagination or tools, what tools they are? (Robert) we need to wait for this to come out of the woodwork.

Definitely take this to the IAB session at IETF 90; HF to also ask a few of the strong text supporters

     * have a max line length for art - yes or no? (current answer = 85)
     * line wrapping - yes or no? (current answer = no)

Taking the last two items back to the list

   - xml2rfc v3 (Paul, what's left for this?)
     * the use of 'representation' and/or 'format' in the v3 draft

Paul has gotten some good feedback from Tony. Have open questions on micro tools and a few other things. The topic raised by Julian re: representation vs format, Dave Crocker noted that the word 'format' was used everywhere. Paul then made changes throughout the doc where 'format' is used only when we’re talking about the serialization of what’s coming out of the processor, and a 'representation' (the document the processor puts out). A document is a thing the processor puts out. It inputs it out in a particular serialization, and that is the format. A representation is an instantiation of the format. It is producing representations based on the HTML format. Like a view. (Julian) will have to go through the doc to decide if the distinction has any relevance. Right now, if look through the document and see 'representation' it doesn’t seem to match the above definition. Will need a statement defining what the term means in this context. Paul to add that after hashing out the language
  
2. AOB (if there is time; else continue on list)
   - Terminology
     * "principal publication format" - ok?

(Paul) Not ok. Not ok with making one more equal than others, either, at least not until the community has indicated which is preferred.

(Heather) we are partly trying to define what to give over during a subpoena. (Robert, Paul) give them everything with a standardized cover letter satiating that the XML is the canonical thing which everything is derived from, and since you are worried about what people have read, they could have read all of them.

(Robert) instead of saying the XML is the canonical format of the RFC; say the XML _is_ the RFC. (Joe) we are going to get push back from that, because then no one can read the RFC. If the XML is what’s immutable, and the XML is the RFC, and yet the thing you read is changeable (Robert) what you read is changeable, therefore it is not the RFC. 

(Paul) agree with Joe; the things that you are reading are not the RFC, but we can’t say that the thing you can’t read is the RFC. Saying it is the canonical format is better than that, though even that is imperfect. (Alice) like calling it the source format is my own preference, but that ship has sailed. Wonder if they will when they hear Robert’s suggestion.

(Robert) if we can get the community to understand that when we make this change in our publication format, you can look at the HTML, but if you want to get down to resolving any detailed questions, you have to look at the XML.

   - Mystery AOB from Paul
Markup for 2119 language; to be taken back to the list

   - From Russ: I'd like to see a timeline for the RFC Editor being ready for the new format.  Without that, the IESG cannot make any decisions about when to start accepting I-Ds in the new format.
RSE Wiki Archive

User Tools

Site Tools

Page Tools
