Subject: Re: [TOOLS-DEVELOPMENT] Tools Call Agenda -- 5 July 2016 at 1:00 Eastern

From: Robert Sparks <[email-masked]>
Date: Mon, 4 Jul 2016 09:56:50 -0500

Notes for tomorrow's call

On 6/28/16 12:52 PM, Russ Housley wrote:
> Tools Call Agenda -- 5 July 2016 at 1:00 Eastern
>
> 1. Datatracker Projects
>     - Expected Datatracker Releases -- Robert and Henrik
>       -- http://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan
The last few releases have included significant changes. The easiest
ones to see are the ones the releases are labelled with:
- account creation changes to help slow the creation of spam accounts
- interim meeting management
- Enhanced testing at both development and deployment time

The most recent release contained a change that all here should
keep in mind going forward:
- We moved from database-backed session storage to memory-backed
    session storage. At the same time we changed when sessions timeout
    (from effectively never, to 4 weeks of inactivity). The sessions 
refresh
    with each request. A direct consequence is that if  a user doesn't touch
    the tracker for 4 weeks, the next time he uses the tracker, he'll have
    to login again.

We adjusted the priority of the items on the mergeplan:
https://trac.tools.ietf.org/tools/ietfdb/wiki/MergePlan
moving a release supporting meeting floorplans to the top, so that it
would  be out in time for applications like Tom Pusateri's iPhone app
to be modified before Berlin.

We also identified a task that needs to be tracked separately, and
have an initial priority set for it: reforming  the code used at 
tools.ietf.org
to make html versions of drafts into a library and having the tracker 
use it
to display drafts. (This will address several bugs related to display of
non-utf8 characters in drafts on the datatracker page). (see
https://trac.tools.ietf.org/tools/ietfdb/browser/trunk/PLAN line 40).

>     - Contracts for Datatracker Enhancements -- Robert
>       -- Interim Meeting Management
Done, merged, and released.
>       -- Tracking Internet-Draft Manual Post Requests
Spherical cow is addressing bugs found in testing.
I expect to walk through this new functionality with the secretariat
before or during the Berlin meeting. It will probably be just after
Berlin before this is deployed into production.

>       -- Review Tracking
Significant progress - Ole is providing instructions for setting up
a test instance of what's been implemented so far. I plan to do several
1-1 walkthroughs in Berlin. Support for assigning reviews is finishing up.
Views for individual reviewers (what are my assignments, and what have
I done in the past), and statistics views remain.
>     - Meeting Materials Management -- Robert
>     - Merge Meeting Materials and Proceedings -- Robert
No change on those two since the last tools call.
I plan to spend time on them with Ryan in Berlin.
>     - Author Statistics -- Russ
>
> 2. Community & Other Projects
>     - Improvements to the mail archive application -- Robert and Ryan
Underway - Ryan can report progress.
>     - IETF Website Makeover -- Greg and Joe
>
> 3. RFC Services Projects
>     - Contracts for Improvements to RFC Services -- Heather
>       -- RFC Editor Statistics and Metrics
>     - RSE's Design Teams -- Heather
>     - RFC Format-related SOWs -- Robert
>     - CSS for the RFCs -- Heather
>
> 4. Transition of Mission Critical Tools
>     - Moving issue trackers and wikis for IETF WGs on ietf.org -- Henrik
>
> 5. Server Infrastructure
>     - Migrate from Django 1.8 to 1.9 -- Henrik
>     - Migrate from MySQL to PostgreSQL -- Henrik
>     - CDN support for HTML and PDF I-Ds -- Henrik
>     - Mailman and internationalized email addresses -- Glen
>
> 6. IDIQ Contractors
>     - RFP for more IDIQ contractors -- Ray
>
> 7. Parking Lot
>     - Discontinue MonArch email archives -- Robert
>     - Improve infrastructure for finding and fetching artifacts -- Robert
>     - Author information for very old I-Ds in the datatracker -- Robert
>     - Replace I-Ds in proceedings with links to archive copy?
>     - Performance improvements and transition to Postgres -- Henrik
>     - VM Architecture for Servers -- Robert
>     - Submit an I-D directly from GitHub
>
> 8. AOB
>
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-development

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Mon, 4 Jul 2016 15:38:48 -0700

Possible regrets - I have this on my calendar for the second Tuesday,
and I'll be at an appointment until sometime between 10am and 11am.
Updates below.

On 6/28/16 10:52 AM, Russ Housley wrote:
> ...

John Levine's code works and is being used in a test environment by the
RPC. Robert did a review of said code and noted that John was missing
out on regression testing. Robert and John discussed this for a bit, and
I think John understands what's needed to wrap this up (Robert, please
correct me if you think otherwise). John had to do the ICANN thing last
week, but expects to get back to this project this week. I expect there
will be a few f2f meetings to finish up any final questions; we'll get
this formally into production after that.

>    - RSE's Design Teams -- Heather

Joe and Paul wrapped up the last two major drafts (HTML, preptool) last
week. Julian is still finding nits and bugs as he works on implementing
the drafts; it's great to get the feedback, but we're not going to stop
the draft publication in order to fix all the nits he's finding. Julian
would prefer that this round of publication have the docs under
"Experimental" but according to RFC 4845, "Generally speaking, the IAB
does not publish Standards-Track or Experimental RFCs."

The CSS draft, which is highly dependent on the HTML draft, has also
been updated and is ready to go.

I have sent a note to the RSOC asking if there are any last objections
or concerns to asking the IAB to approve these for publication.

>    - RFC Format-related SOWs -- Robert

The IAB has to approve the drafts for publication, but I think they are
ready to go. Finally. Do you think we still need to push the RFP out and
do the other projects on the tools list first, so we can keep the budget
moving along?

>    - CSS for the RFCs -- Heather

I've updated the SoW based on comments received--Russ, I'm assuming you
were ok with the updates given you suggested to Ray that we move
forward--and the CSS I-D is now waiting on approval for publication. I
think it makes sense to post the RFP as soon as the CSS draft is
approved, given where we are with it.

Please let me know if you have any questions!

-Heather

---

From: Russ Housley <[email-masked]>
Date: Tue, 5 Jul 2016 12:29:39 -0400

Robert:

This seems to be related to making HTML and PDF and versions of the I-Ds more friendly to the CDN.  Did I miss something?

Russ

On Jul 4, 2016, at 10:56 AM, Robert Sparks <[email-masked]> wrote:

> have an initial priority set for it: reforming  the code used at tools.ietf.org
> to make html versions of drafts into a library and having the tracker use it

---

From: Robert Sparks <[email-masked]>
Date: Tue, 5 Jul 2016 11:35:46 -0500

> This seems to be related to making HTML and PDF and versions of the I-Ds more friendly to the CDN.  Did I miss something?
They're only tangentially related as I understand the efforts.

One activity involves changing how pages are served at tools.ietf.org to 
make them servable through the CDN (assuming we want the pdf and html 
versions served from tools.ietf.org as we do now). I think Henrik has 
plans to make some tweaks to the content of the pages to facilitate that 
(mostly paths involved in generated links), but it's not a big change to 
the generation code itself.

The other involves refactoring the code that generates the pages into a 
library that both tools.ietf.org and datatracker.ietf.org can use, and 
then changing datatracker.ietf.org to use that library.

Henrik, please correct any details I've gotten wrong or have left out.

RjS

---

From: Robert Sparks <[email-masked]>
Date: Tue, 5 Jul 2016 11:48:10 -0500

I'm not seeing a bridge for this yet?

---

From: Russ Housley <[email-masked]>
Date: Tue, 5 Jul 2016 13:54:41 -0400

Robert:

Thanks for explaining the two efforts.  We seems to have a small disconnect one one of them.  I thought the effort was to figure out how to the the HTNL and PDF versions of I-Ds on ww.ietf.org so that they can be served by the CDN.

Russ

On Jul 5, 2016, at 12:35 PM, Robert Sparks <[email-masked]> wrote:

> One activity involves changing how pages are served at tools.ietf.org to make them servable through the CDN (assuming we want the pdf and html versions served from tools.ietf.org as we do now). I think Henrik has plans to make some tweaks to the content of the pages to facilitate that (mostly paths involved in generated links), but it's not a big change to the generation code itself.
> 
> The other involves refactoring the code that generates the pages into a library that both tools.ietf.org and datatracker.ietf.org can use, and then changing datatracker.ietf.org to use that library.
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 5 Jul 2016 14:01:43 -0400

> do the other projects on the tools list first, so we can keep the budget

During the tools call, we asked everyone on this list to review the SOWs that go with these I-Ds.  The goal is to issue an RFC shortly after Berlin, which assumes that the IAB approval will come in that time period.

Even if the award is made in early September, I do not think that the work will be finished in 2016.

> approved, given where we are with it.

I see that the CSS I-D has been updated to alight with the now-stable HTML I-D.

Do you need to make an changes to the CSS SOW?

Russ

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Tue, 5 Jul 2016 11:05:33 -0700

> Even if the award is made in early September, I do not think that the work will be finished in 2016.

Agreed.

> Do you need to make an changes to the CSS SOW?

I don't believe so, not beyond what we've already discussed (see attached).

-heather

---

From: Russ Housley <[email-masked]>
Date: Tue, 5 Jul 2016 14:20:06 -0400

With the recent change to the CSS for RFCs SOW, I think this is ready to go out as an RFP.  Does anyone concerns?

Russ

---

From: Julian Reschke <[email-masked]>
Date: Tue, 5 Jul 2016 20:28:58 +0200

> With the recent change to the CSS for RFCs SOW, I think this is ready to go out as an RFP.  Does anyone concerns?

Repeating my feedback I send last month:

"I have several concerns:

- the HTML spec can act as a guideline, but it's not complete; it should 
be made clear that this still is a moving target

- it's unclear how designing the CSS has any impact on PDF, unless we 
plan to produce the PDF from HTML (which I would strongly support), in 
which case mentioning it here doesn't make a lot of sense

- suitability of printing/pagination of the styled HTML doesn't seem to 
be mentioned"

Best regards, Julian

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Tue, 5 Jul 2016 11:38:05 -0700

On 7/5/16 11:28 AM, Julian Reschke wrote:
> On 2016-07-05 20:20, Russ Housley wrote: >> With the recent change to the CSS for RFCs SOW, I think this is >>
ready to go out as an RFP.  Does anyone concerns? >> >> Russ ... > > >
Repeating my feedback I send last month:
Apologies - I thought I'd responded to you, but instead had responded to
these concerns in a thread with Russ.

> > "I have several concerns: > > - the HTML spec can act as a guideline,
but it's not complete; it > should be made clear that this still is a
moving target
I think that is clear in the I-Ds themselves.

> plan to produce the PDF from HTML (which I would strongly support), >
in which case mentioning it here doesn't make a lot of sense
Right. I've removed the deliverable that says the PDF and HTML must stay
in sync; what's left says that the look between the two formats must be
as similar as possible.

> > - suitability of printing/pagination of the styled HTML doesn't seem >
to be mentioned"
That's in the CSS and HTML drafts themselves.

-Heather

---

From: Russ Housley <[email-masked]>
Date: Tue, 5 Jul 2016 14:47:06 -0400

Julian:

> I have several concerns:
> 
> - the HTML spec can act as a guideline, but it's not complete; it should be made clear that this still is a moving target

The note from Joe Hildebrand indicates that the HTML specification is now stable enough for development.

> - it's unclear how designing the CSS has any impact on PDF, unless we plan to produce the PDF from HTML (which I would strongly support), in which case mentioning it here doesn't make a lot of sense

The most recent update to the CSS for RFCs SOW is much more clear on this point.  I think the previous version was fuzzy.

> - suitability of priting/pagination of the styled HTML doesn't seem to be mentioned

Section 5 of draft-iab-rfc-css-01 seems to cover printing.

My understanding is that we will go forward with this set of documents for development.  I think of them as the as-designed drawings.  Then, once we have development experience, the documents will be updated to match the way that the tools actually work.  I think of these yet-to-be-written documents as the as-built drawings.  the IAB has been encouraging this two phase approach to this development.

Russ

---

From: Julian Reschke <[email-masked]>
Date: Tue, 5 Jul 2016 20:50:18 +0200

> The note from Joe Hildebrand indicates that the HTML specification is now stable enough for development.

Well, we'll find out :-)

> The most recent update to the CSS for RFCs SOW is much more clear on this point.  I think the previous version was fuzzy.

I just looked and it still talks about PDF all over the place; it's 
totally unclear from the SoW how CSS affects PDF.

> My understanding is that we will go forward with this set of documents for development.  I think of them as the as-designed drawings.  Then, once we have development experience, the documents will…

Ah, I missed that. Thanks.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 5 Jul 2016 20:58:58 +0200

> in sync; what's left says that the look between the two formats must be

I'll just quote on place:

"Create the initial strawman CSS for both HTML and PDF. This may be 
based on previous proofs-of-concept, or may be entirely new, at the 
discretion of the contractor;"

Unless I'm missing something (which is possible), this is really 
nonsensical. PDF does not use CSS. The CSS for HTML has absolutely 
*zero* effect on PDF unless we generate the PDF directly from HTML, and 
use software that takes CSS into account.

The easiest fix for this SoW is to get rid of all mentions of PDF.

Best regards, Julian

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Tue, 5 Jul 2016 12:56:57 -0700

Hi Julian,

On 7/5/16 11:50 AM, Julian Reschke wrote:
> On 2016-07-05 20:47, Russ Housley wrote: >> Julian: >> >>> I have several concerns: >>> >>> - the HTML spec can
act as a guideline, but it's not complete; it >>> should be made clear
that this still is a moving target >> >> The note from Joe Hildebrand
indicates that the HTML specification >> is now stable enough for
development. > > Well, we'll find out :-) > >>> - it's unclear how
designing the CSS has any impact on PDF, >>> unless we plan to produce
the PDF from HTML (which I would >>> strongly support), in which case
mentioning it here doesn't make >>> a lot of sense >> >> The most recent
update to the CSS for RFCs SOW is much more clear >> on this point.  I
think the previous version was fuzzy. > > I just looked and it still
talks about PDF all over the place; it's > totally unclear from the SoW
how CSS affects PDF.
The HTML and PDF need to look very similar, and if the implementer(s)
decide to create the PDF from the HTML using all the features described
in the PDF draft, then there may well be implications for the CSS. I
feel rather strongly that we need to leave the mentions of PDF in this
doc. Whoever designs the CSS needs to understand how closely these
things will be tied together.

-Heather

> >>> - suitability of priting/pagination of the styled HTML doesn't >>>
seem to be mentioned >> >> Section 5 of draft-iab-rfc-css-01 seems to
cover printing. >> >> My understanding is that we will go forward with
this set of >> documents for development.  I think of them as the
as-designed >> drawings.  Then, once we have development experience, the
documents >> will be updated to match the way that the tools actually
work.  I >> think of these yet-to-be-written documents as the as-built
>> drawings.  the IAB has been encouraging this two phase approach to >>
this development. > > Ah, I missed that. Thanks. > > Best regards,
Julian > > _______________________________________________
TOOLS-DEVELOPMENT > mailing list [email-masked] >
https://www.ietf.org/mailman/listinfo/tools-development >

---

From: Robert Sparks <[email-masked]>
Date: Tue, 5 Jul 2016 15:07:14 -0500

On 7/5/16 2:56 PM, Heather Flanagan (RFC Series Editor) wrote:

<trim/>

> >>>> - it's unclear how designing the CSS has any impact on PDF, >>> 
> unless we plan to produce the PDF from HTML (which I would >>> 
> strongly support), in which case mentioning it here doesn't make >>> a 
> lot of sense >> >> The most recent update to the CSS for RFCs SOW is 
> much more clear >> on this point.  I think the previous version was 
> fuzzy. > > I just looked and it still talks about PDF all over the 
> place; it's > totally unclear from the SoW how CSS affects PDF.
> decide to create the PDF from the HTML using all the features 
> described in the PDF draft, then there may well be implications for 
> the CSS. I feel rather strongly that we need to leave the mentions of 
> PDF in this doc. Whoever designs the CSS needs to understand how 
> closely these things will be tied together. 
It's probably worth capturing the distinction I think Julian is really 
looking for.

The CSS designer needs to be aware that we want to create PDF that looks 
very similar to the way HTML renders.
That will constrain the choices the designer makes to those that won't 
make creating that PDF _hard_.
The CSS designer should also be aware that we could choose to render PDF 
from the HTML, and not make choices that would make that hard.

That captures the connection between the HTML and PDF for the purposes 
of this document completely I think.

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Tue, 5 Jul 2016 21:14:40 +0000

This discussion makes me think that what we need is NOT a “CSS for RFCs” SOW, but instead a “Look&Feel for RFCs” SOW that covers both “CSS for HTML” and “PDF”.

                Tony

From: TOOLS-DEVELOPMENT <[email-masked]> on behalf of Robert Sparks <[email-masked]>
Date: Tuesday, July 5, 2016 at 4:07 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [TOOLS-DEVELOPMENT] CSS for RFCs SOW

<trim/>

> >>> - it's unclear how designing the CSS has any impact on PDF, >>> unless we plan to produce the PDF from HTML (which I would >>> strongly support), in which case mentioning it here doesn't make >>> a lot of sense >> >> The
most recent update to the CSS for RFCs SOW is much more clear >> on this point.  I think the previous version was fuzzy. > > I just looked and it still talks about PDF all over the place; it's > totally unclear from the SoW how CSS affects PDF.

The HTML and PDF need to look very similar, and if the implementer(s) decide to create the PDF from the HTML using all the features described in the PDF draft, then there may well be implications for the CSS. I feel rather strongly that we need to leave the mentions of PDF in this doc. Whoever designs the CSS needs to understand how closely these things will be tied together.
It's probably worth capturing the distinction I think Julian is really looking for.

The CSS designer needs to be aware that we want to create PDF that looks very similar to the way HTML renders.
That will constrain the choices the designer makes to those that won't make creating that PDF _hard_.
The CSS designer should also be aware that we could choose to render PDF from the HTML, and not make choices that would make that hard.

That captures the connection between the HTML and PDF for the purposes of this document completely I think.

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 06 Jul 2016 09:18:26 +0200

> Henrik, please correct any details I've gotten wrong or have left out.

You got it right.

Best,

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 06 Jul 2016 09:32:10 +0200

> Thanks for explaining the two efforts.  We seems to have a small disconnect one one of them.  I thought the effort was to figure out how to the the HTNL and PDF versions of I-Ds on ww.ietf.org so t…

Serving them on www.ietf.org is something we also can do, but it's not
going to bring CDN goodness to all the links out on the web which point
at tools.ietf.org, which is why I'm intending to look at whether cloudflare
can be made to cover part of tools.ietf.org.

Yes, I've vacillated regarding this, but your response to my question of
the purpose of serving these over CDN on an earlier tools call brought
home to me the number of links which already point at tools which won't
necessarily be helped by serving them with CDN on www, even if CDN-wise,
serving them on www would be cleanest.  Bah.  I'm still torn regarding
this.

Best regards,

	Henrik

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Wed, 6 Jul 2016 13:03:03 -0700

That's essentially what we have here. I don't think, however, that
calling it a "Look and Feel for RFCs RFP" will get the right bidders in
the room.

-Heather

On 7/5/16 2:14 PM, HANSEN, TONY L wrote:
>
> This discussion makes me think that what we need is NOT a “CSS for
> RFCs” SOW, but instead a “Look&Feel for RFCs” SOW that covers both
> “CSS for HTML” and “PDF”.
>
>  
>
>                 Tony
>
>  
>
> *From: *TOOLS-DEVELOPMENT <[email-masked]> on
> behalf of Robert Sparks <[email-masked]>
> *Date: *Tuesday, July 5, 2016 at 4:07 PM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [TOOLS-DEVELOPMENT] CSS for RFCs SOW
>
>  
>
>     > >>> - it's unclear how designing the CSS has any impact on PDF,
>     strongly support), in which case mentioning it here doesn't make
>     >>> a lot of sense >> >> The
>
>     most recent update to the CSS for RFCs SOW is much more clear >>
>     on this point.  I think the previous version was fuzzy. > > I just
>     looked and it still talks about PDF all over the place; it's >
>     The HTML and PDF need to look very similar, and if the
>     implementer(s) decide to create the PDF from the HTML using all
>     the features described in the PDF draft, then there may well be
>     implications for the CSS. I feel rather strongly that we need to
>     leave the mentions of PDF in this doc. Whoever designs the CSS
>     needs to understand how closely these things will be tied together.
>
> The CSS designer needs to be aware that we want to create PDF that
> looks very similar to the way HTML renders.
> The CSS designer should also be aware that we could choose to render
> PDF from the HTML, and not make choices that would make that hard.
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 7 Jul 2016 08:16:52 +0200

> calling it a "Look and Feel for RFCs RFP" will get the right bidders in

Please take my feedback as from somebody who has deeloped one CSS 
flavour and *two* ways to generate PDF. The current SoW really doesn't 
make any sense wrt what it says about PDFs. If the goal of the SoW is to 
make clear what the deliverable is, it really fails in a spectacular way.

Best regards, Julian

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Sun, 17 Jul 2016 15:31:42 +0200

On 7/5/16 10:07 PM, Robert Sparks wrote:
>> strongly support), in which case mentioning it here doesn't make >>>
>> a lot of sense >> >> The most recent update to the CSS for RFCs SOW
>> is much more clear >> on this point.  I think the previous version
>> was fuzzy. > > I just looked and it still talks about PDF all over
>> the place; it's > totally unclear from the SoW how CSS affects PDF.

Does this change in the Overview capture this, do you think?

This project will result in a CSS file that will reflect visually
pleasing, accessible, and responsive design. The HTML follows a semantic
design as described in
<https://datatracker.ietf.org/doc/draft-iab-html-rfc/>; all display
details must come from an embedded CSS. The PDF must also follow a
semantic design, including proper PDF tags, as described in
<https://datatracker.ietf.org/doc/draft-iab-rfc-use-of-pdf/>. The CSS
will be embedded in the HTML; the CSS designer should avoid any feature
that is not easily implemented in PDF. The CSS designer should be aware
that we may choose to render PDF from the HTML, and so should avoid
making any choices in the implementation of the CSS that would make that
creating a visually similar PDF difficult.

(last sentence added)
-Heather

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Sun, 17 Jul 2016 13:34:40 +0000

Looks good to me.

> On Jul 17, 2016, at 3:31 PM, Heather Flanagan (RFC Series Editor) <[email-masked]> wrote:
> 
>>> >>> unless we plan to produce the PDF from HTML (which I would
>>> >>> a lot of sense
>>> >> The most recent update to the CSS for RFCs SOW is much more clear
>>> >> on this point.  I think the previous version was fuzzy.
>>> > 
> This project will result in a CSS file that will reflect visually pleasing, accessible, and responsive design. The HTML follows a semantic design as described in <https://datatracker.ietf.org/doc/draft-iab-html-rfc/>; all display details must come from an embedded CSS. The PDF must also follow a semantic design, including proper PDF tags, as described in <https://datatracker.ietf.org/doc/draft-iab-rfc-use-of-pdf/>. The CSS will be embedded in the HTML; the CSS designer should avoid any feature that is not easily implemented in PDF. The CSS designer should be aware that we may choose to render PDF from the HTML, and so should avoid making any choices in the implementation of the CSS that would make that creating a visually similar PDF difficult.
> 
> 
> (last sentence added)
> -Heather 

-- 
Joe Hildebrand

---

From: Robert Sparks <[email-masked]>
Date: Sun, 17 Jul 2016 15:35:53 +0200

That wfm

On 7/17/16 3:31 PM, Heather Flanagan (RFC Series Editor) wrote:
>>> implementer(s) decide to create the PDF from the HTML using all the 
>>> features described in the PDF draft, then there may well be 
>>> leave the mentions of PDF in this doc. Whoever designs the CSS needs 
>>> to understand how closely these things will be tied together. 
>> That captures the connection between the HTML and PDF for the 
>> purposes of this document completely I think.
>
> pleasing, accessible, and responsive design. The HTML follows a 
> semantic design as described in 
> will be embedded in the HTML; the CSS designer should avoid any 
> feature that is not easily implemented in PDF. The CSS designer should 
> be aware that we may choose to render PDF from the HTML, and so should 
> avoid making any choices in the implementation of the CSS that would 
> make that creating a visually similar PDF difficult.
>
>
>
> (last sentence added)
> -Heather
>
>

---

From: Julian Reschke <[email-masked]>
Date: Sun, 17 Jul 2016 16:30:21 +0200

Hi there,

I still don't get why we're talking about PDF at all.

In particular, it's totally unclear why we have a statement like

"The PDF must also follow a semantic design, including proper PDF tags, 
as described in 
<https://datatracker.ietf.org/doc/draft-iab-rfc-use-of-pdf/>."

...in a SoW related to CSS design.

Please clarify whether people bidding for this are expected to come up 
with anything specific to PDF or not.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Jul 2016 08:08:10 +0200

> With the recent change to the CSS for RFCs SOW, I think this is ready to go out as an RFP.  Does anyone concerns?

Another thing that just occurred to me is that the text doesn't say 
anything specific about compliance to CSS specifications (and which), 
use of browser-specific extensions, and browser support in general.

This can be relevant as CSS comes in modules, and not all of them are at 
the state of standardization.

(In particular, 
<https://tools.ietf.org/html/draft-iab-rfc-css-01#section-7.16> asks for 
functionality not available in standard CSS today).

Best regards, Julian

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 18 Jul 2016 06:56:58 +0000

I'd suggest not over-specifying here.  Having CSS that's not understood (within reasonable size limits) doesn't hurt anything.  Having standardized CSS that isn't widely-implemeneted yet (such as the printing bits) may help a potential HTML->PDF conversion, and may push more browsers to implement those bits one day.  Finally, there are some places where using browser-specific CSS (like -moz-user-select) can increase the number of older browsers that are supported.

> On Jul 18, 2016, at 8:08 AM, Julian Reschke <[email-masked]> wrote:
> 
> Another thing that just occurred to me is that the text doesn't say anything specific about compliance to CSS specifications (and which), use of browser-specific extensions, and browser support in general.
> 
> This can be relevant as CSS comes in modules, and not all of them are at the state of standardization.
> 
> (In particular, <https://tools.ietf.org/html/draft-iab-rfc-css-01#section-7.16> asks for functionality not available in standard CSS today).
> 
> Best regards, Julian
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

-- 
Joe Hildebrand

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Jul 2016 09:39:49 +0200

> I'd suggest not over-specifying here.  Having CSS that's not understood (within reasonable size limits) doesn't hurt anything.  Having standardized CSS that isn't widely-implemeneted yet (such as t…

I agree with the latter parts (we *want* the CSS to use these things). 
The SoW just is unclear about what the requirements are. We certainly do 
not want something with webkit- prefixed attributes all over the place, 
right?

Best regards, Julian

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 18 Jul 2016 08:41:13 +0000

> On Jul 18, 2016, at 9:39 AM, Julian Reschke <[email-masked]> wrote:
> 
> I agree with the latter parts (we *want* the CSS to use these things). The SoW just is unclear about what the requirements are. We certainly do not want something with webkit- prefixed attributes all over the place, right?

If -webkit- attributes are needed to get a feature to work on an older version of webkit, I don't think I mind having them.  The CSS is the place where all of the visual fixups for real shipping browsers has to happen, unfortunately.

-- 
Joe Hildebrand

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Jul 2016 10:52:00 +0200

> If -webkit- attributes are needed to get a feature to work on an older version of webkit, I don't think I mind having them.  The CSS is the place where all of the visual fixups for real shipping br…

I do not disagree, but we should have a common understanding of "older 
version". IMHO, supporting current mobile versions of Microsoft and 
Firefox browsers should have a higher prio than supporting old webkit 
versions.

Best regards, Julian

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 18 Jul 2016 13:02:57 +0000

> On Jul 18, 2016, at 10:52 AM, Julian Reschke <[email-masked]> wrote:
> 
> I do not disagree, but we should have a common understanding of "older version". IMHO, supporting current mobile versions of Microsoft and Firefox browsers should have a higher prio than supporting old webkit versions.

Browser support is a separate issue.  I would be ok with language that says "prefer standards", but I'd really rather get the RFP released as soon as possible than tweak the language more.

-- 
Joe Hildebrand

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Mon, 18 Jul 2016 15:41:39 +0200

Hi Julian,

I think we're at the point where we're just going to have to agree to
disagree. I think, between the requirements stated in draft-iab-rfc-css
and the information in the SoW, we are reasonably covered. There is no
harm in making sure that a CSS developer realizes that PDFs are going to
be published as well, and that we'll have to make things look as similar
as possible. And if they have any questions about what we're talking
about with the PDF, they'll have the necessary references to do full due
diligence on their part.

I'm declaring this SoW good enough, and ask Russ to go ahead and take
this to the TMC.

Thanks,
Heather

On 7/17/16 4:30 PM, Julian Reschke wrote:
> "The PDF must also follow a semantic design, including proper PDF
> tags, as described in