User Tools

Site Tools


Julian - ok Joe Ted - ok Tony Paul - ok Alice - ok Adam - no Dave - ok Nevil - ok Robert - ok

0. Agenda bash

1. Status on drafts

  1. draft-hildebrand-html-rfc
  2. draft-reschke-xml2rfc-latest

Looks like there is quite a bit of discussion at this point between Julian, Paul, and Tony on the xml2rfc mailing list. Is mediation required? * Julian reasonably happy with structure of doc, except for the open question on fragments in main section; no one seems to like them so probably will remove them; about 20 or so attributes have no discussion at all yet cross references, anchors and lists are the most contentious * Plausibly make this complete in December for the v2 section * Julian wants to have the v3 discussion in parallel with the v2 work; discussions on what to add will be more interesting; want Alice and Sandy to go through the document and send editorial feedback and discuss their use of xml2rfc; also plans to add more examples * Alice - has looked at it and a detailed review is planned Hard to design change in a vocabulary if you don't understand existing vocabulary * Paul - agree. As Julian and Paul are discovering, there is not a common understanding on what the vocabulary is and how it is used, esp. by the RPC * example - need feedback on what special characters are actually used to put line breaks or avoid line breaks * Paul - fine to have discussion about v3 live on xml2rfc is ok, but it would better on rfc-interest to get people away from thinking about the xml2rfc tool for v3; might have an issue in terms of setting up a bias for the conversation; need to remind peole that it's not about making the smallest number of changes, that it is more important to make the right number of changes for this to become a canonical format and have it become part of tooling later *Dave - what is in the authoritative RFC format should be in rfc-interest, as opposed to “here is what a particular tool is to generate the canonical format” * Julian - so, keep discussion on existing vocal on xml2rfc, bu when we start discussing new elements have that discussion on rfc-interest * Julian - what do we want to call this? Julian wants to use xml2rfc, but Paul wants to move away from that * Paul - people are familiar and happy with the term, bout that is because they are thinking through the current state of thing; either rwe leave that as the v2 name and come up with a new name for v3, or come up with a more neutral name for both; in 5 years, people won't be thinking in terms of the “2rfc” thing; we want people to be thinking of the XML as the canonical format, so things like rfc2html, or rfc2txt; application/rfc-xml * so working assumption will be that it is an evolution of what we have, and we will use the same media type - application/

want to submit I-D as new RFC format, and then the website will do the necessary conversion; want people to be able to directly submit the XML

* Robert - The natural pressure will be taking people to author in this format, and that means we should make it as easy as possible for the IETF to pick it up as an input format for I-D. The only thing likely to get in the way is tooling, so we just need to take that in to account. * Julian - The format will have all the info that the I-D needs, so nothing new should be required. * Robert - there is nothing concrete for them to be thinking about yet; they need something more baked. We accept draft now in xml and the text that it is derived from; the notion that we could take these in parallel and the input to the draft could be just XML will be a policy decision that someone has to make along the way. But until we can easily talk to them being the right input format and process, they are unlikely to make any strong decisions. The interesting question will be that it is not ok to take the txt, but they won't be willing to trigger that decision for some time * Paul volunteers to do a wiki page on what the effects might be to the I-D. Expect to have this as an in-between meeting consideration during an informal tele chat; the critical part of the conversation will come down on whether we require this format as input (HF which we won't - we will always accept txt or xml) * Ted - one of the thing the IESG will ask about is if the thing that was reviewed was txt, and it gets converted - will that be a problem? the check will be during AUTH48 to make sure it produces as it should, but it shouldn't be functionally different than today * Julian - what about non-ASCII characters and SVG artwork; at some point we will see that whatever is in the final I-D including images and characters needs to be in what the IESG reviews * Alice - any changes beyond editorial do go back to ADs or Stream Managers of approval

  1. would the other output formats benefit from having I-Ds describing their requirements?

PDF - TXT - not sure this needs anything other than the style guide. The non-ASCII description applies to all output formats.

* Ted - Having a doc describing the SVG profile would be a very good idea and is possibly the most pressing * Paul - the PDF draft should be at most a paragraph long; if they can be reduced that much, it shouldn't be a draft * Dave - what if we had one I-D with a section for format? * Paul - reasonable, but have a separate doc for XMLv3 draft? Then group the others as the non-canonical one and tack them on the HTML

For reviewing Joe's draft * Julian - was waiting for Joe to strip out the other stuff * Paul - look at the live site, that should be up to date (Others on the call encouraged to do that as well)

2. SVG profile - should this be suggested to the W3C as a standard SVG profile? (referring to the “micro” spec we'd talked about briefly on the list) * Tony or Adam might be willing to step up on this - HF to reach out to them; Nevil also willing to do this * Paul - suggest “start here (with Tiny) and subtract this”; if we tried to go through the W3C, that's vast over kill * Dave - after we have done this, then we can send it to the W3C WG as an “FYI” - they can then pick it up if there is more interest * Paul - certainly can send them a pointer as something of interest when we have a draft, just to get more expert reviewers

Next call scheduled for Wednesday, 11 December 2013 @ 20:00 UTC

design/20131127-notes.txt · Last modified: 2013/12/19 16:35 by rsewikiadmin