PWG Weekly Telco -- 24 Jun 2019

<dauwhe> github-bot, help

<github-bot> dauwhe, The commands I understand are:

<github-bot> help - Send this message.

<github-bot> intro - Send a message describing what I do.

<github-bot> status - Send a message with current bot status.

<github-bot> bye - Leave the channel. (You can /invite me back.)

<github-bot> end topic - End the current topic without starting a new one.

<github-bot> reboot - Make me leave the server and exit. If properly configured, I will then update myself and return.

<scribe> scribe: bigbluehat

tzviya: lots of folks in Paris because of the EDRLab meeting

<tzviya> https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2019/2019-06-17-pwg

tzviya: let's take a look at last week's meeting notes
... any comments?

scribe+ dauwhe

scribe: k...minutes approved
... josh and franco are you both here?

franco: yep

josh: indeed

tzviya: then you can take us through the finalizing steps for the UCR document

FInalizing UCR for Publication

josh: I nominate franco to go first

<tzviya> https://w3c.github.io/dpub-pwp-ucr/

franco: so josh and I would like some feedback on a couple more issues
... first one is issue #213

<tzviya> https://github.com/w3c/dpub-pwp-ucr/issues

franco: josh suggests it seems to recommend that the document be using DRM
... rather than possibly using it

<tzviya> github: https://github.com/w3c/dpub-pwp-ucr/issues

franco: so, we suggest a change to mention the possibility
... but not make it sound like a requirement

<franco> A Web Publication must not prevent any other system from expressing access control and write protections of the publication.

<dauwhe> github: https://github.com/w3c/dpub-pwp-ucr/issues/213

josh: I just agreed with the TAG reviewer

<tzviya> github: https://github.com/w3c/dpub-pwp-ucr/issues/213

josh: I think it is a little problematic

franco: I just pasted in the recommended rephrasing--reading it now
... "A Web Publication must not prevent any other system from expressing access control and rights protections of the publication."

dauwhe: do we need to make a statement around this at all?

josh: dauwhe are you suggesting we leave it as is?
... despite the TAG feedback?

dauwhe: no, I'm more thinking about dropping the use case

josh: ah. quite right. that's been my go to rememdy
... it had been my position to take it out (in general)
... and we took a lot out, so I've been concerned we'd taken too much out
... so I wanted to check with the group on this one

tzviya: this should probably point to 16 not 17
... I think the reason this is in here is not the "classic"/traditional content protection use case
... but rather than library use case for content protection
... so I'm a little hesitant to pull it completely
... the other case is making sure folks with disability can access it--despite the DRM

franco: I'm in agreement that it should remain and be rephrased
... like the WP may be subject to this, rather than it containing those protections in itself

tzviya: "A Web Publication must not prevent any other system from expressing access control and write protections of the publication."

duga: I prefer the original text
... the revision is not quite right
... a WP must not do something
... if I want to make a WP that cannot be DRM'd, I should be allowed to do that
... I think it's more that WP's not prevent using DRM
... this rephrasing makes it sound like WP's should always be compatible with DRM
... and I don't think we should make that a requirement

tzviya: the goal seems to be that it should be compatible with DRM, but not require it

dauwhe: I sort of agree with duga
... we keep saying DRM, but are we talking about encrypting content and stuff
... or are we saying something more like logging into a bank account?
... for which you need a login to use at all
... like with the NY Times, I have to be a subscriber to access the content
... that seems pretty implicit to the design of the Web
... we are not creating use cases that say every publication must be accessible to anyone with that URL
... so perhaps there's a way to express this more compatibly with the rest of the Web

josh: I didn't choose the "write", but I think it's correct
... these aren't "right" as in access permissions--these are protecting from writing
... I hadn't thought of the earlier mention of preventing DRM
... not sure why someone would do that

<tzviya> current wording is "A Web Publication should be able to express the access control and write protections of the publication."

<Bill_Kasdorf> I think we should explicitly be agnostic on the issue.

josh: in light of that, I'm back to wondering why say anything about it

tzviya: franco and josh could you remind us about the TAG comment on this one?
... and why we're discussing it

<franco> UC 121: Alice acquires a Packaged Web Publication through a subscription service and downloads it. When, later on, she decides to unsubscribe from the service, this Web Publication becomes unavailable to her.

franco: the comment said, this seems problematic for this particular use case

tzviya: this probably just needs explanation

dauwhe: the other interesting this is that as phrased right now it seems like a question of metadata
... are we proposing that we need an access control vocabulary
... it sort of comes down to the question of who are we talking about here
... if I'm putting a journal online
... I can setup whatever registration access control that I want
... again we seem to have an implicit assumption that we're talking about a file format or something
... that could include a permissions expression or access control vocabulary
... all of that strikes me as odd

franco: I think what dauwhe is describing here, is that there would be something in the WP that would express the right/write protection
... I'm not versed in DRM at all
... but I still think this just needs rephrasing
... since we have subscription and library scenarios, I'd think we should keep it
... the current way it's being stated seems to dictate something we're not wanting to dictate
... the rephrasing suggestion currently may not work, but I can propose something else

josh: agreed. In my comment on the issue, I was noting that it seemed like the WP was somehow including this metadata
... we don't want to suggest that the WP includes a method of access control or DRM

duga: so, I think I agree with all of that
... if we're rewriting that, just make it clear that the access control is something external to a WP
... and that the WP shouldn't break such a mechanism

tzviya: so I think we should change UCR 16 to allowing for this
... it should just be a minor tweak
... franco and josh please work on this one, and send it around--unless you have wording right now

josh: I think it's fine to go offline
... I'd only ask if we resolve this online, and finalize it next week
... and then agree to it on github

tzviya: exactly

garth: I just wanted to comment, whatever the agreed language, we should focus more on ‘not disable’ rather than ‘should enable’

<George> I like it too.

<Bill_Kasdorf> +1

tzviya: it needs to function, not just not function

<josh> A Web Publication must not prevent any other system from expressing access control and write protections of the publication.

tzviya: duga feel free to disagree with that. :)
... unless duga you've come around

duga: I don't know. It seems like we're forcing all these to have access control applied to them
... there may be places where you want the opposite
... and I'm concerned about making "must not prevent" being a use case

tzviya: agreed. I think we've come full circle
... and I'm leaning on josh and franco to tweak the wording
... the other issues is #215

<tzviya> https://github.com/w3c/dpub-pwp-ucr/issues/215

josh: I hope everyone's reading these, but this one has to do with CSS counters
... and in this case, across resources
... if I had a 15 chapter legal document that had paragraph numbering
... a lot of times, you'd use a CSS counter to number all of those
... but that doesn't work across documents
... there was a requirement that WP's somehow support something that I don't know how to do in CSS
... you can hard code the numbering of course
... I put a comment in there, and got some feedback
... one of them said, I thought this was about page numbering
... and I don't think it is
... so my first question, is this about CSS numbering across documents?
... and having CSS seed the starting number from a previous document

<Bill_Kasdorf> typically publishers would want to control the numbering via hard coding anyway--especially legal

josh: and if so, how do deal that in a world that doesn't work that way

dauwhe: the use case is a little weird
... the user is requesting a specific technology to achieve a larger goal
... we sort of assume having multiple HTML documents is the ultimate goal
... and that CSS is the only way to achieve that goal
... which I think sets us up for failure
... because I think this will always be impossible in CSS

<Bill_Kasdorf> not always, just "typically"

dauwhe: going up to the requirement...I don't see this as a requirement
... is this something a web content creator thinks about
... is there concern about documents being layered on top of each other?

<duga> +1K

dauwhe: I think this on is not very well expressed

<franco> +1

dauwhe: I'd be happy to take this one out

<garth> +1

<Bill_Kasdorf> +1

dauwhe: and it's associated use cases

<George> +1 to what Dave said.

tzviya: I do think we were originally talking about page numbering
... it was a very long time ago
... in some sort of idealized world, perhaps this included figure numbering
... and this needs to be customizable
... you can't create a rule about these things
... because it's going to vary
... things like section numbering will vary from publication to publication
... like josh is explaining, unless you use variables and share them across resources...
... this one needs to come out

garth: my recollection was that this was originally about OL's across documents
... but I also agree that we shouldn't legislate the impossible

josh: I'm reading it right now, and it does talk about section numbering
... maybe it was about page numbering initially
... but it now includes section numbering

George: if anyone's going to reference paragraph numbers in a legal document, you don't want that auto generated anyway

<duga> +1

<Bill_Kasdorf> +1

<franco> +1

<tzviya> +1

<josh> +100

<garth> +1

<geoffjukes> +1

<dkaplan3> +1

<dauwhe> Kill! Kill! Kill!

<George> +1

tzviya: very good. then josh and franco please remove that section
... and tweak requirement 16
... about access control
... and you'll send that around to the group for review
... and then hopefully declare this publishable

josh: yeah. we've got a few more things to clean up, but yeah, we should be able to meet the end of June deadline

tzviya: then you can work with ivan on the details of publishing this document
... I'm sure he's on email during the summit
... so. that's it for our agenda
... anything else?
... ok. class dismissed!

<tzviya> rrsagent make minutes

- DRAFT -

PWG Weekly Telco

24 Jun 2019

Attendees

Contents

FInalizing UCR for Publication

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output