Internet Engineering Task Force Interim Meetings, 29 Sep 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: IETF-RSWG-20230929-1300

Description

RSWG interim meeting session
2023/09/29 1300

https://datatracker.ietf.org/group/rswg/meetings/

A

Waiting for uh some plane to take off for land.

B

Well, it's a minute! After so why don't we go ahead and get started Pete? uh Do you have a slide for no well.

A

I can find one if we need one.

B

All right, well, we'll just remind everyone, since everybody on the list is an Old Timer um that the note well applies and uh please uh treat each other with uh respect as we go through this process.

B

A

So I posted a quick summary of points that were raised yesterday, um as I mentioned at the end of the session. This is more or less a continuation. We want to make sure that folks, who weren't at yesterday's session, um get a little up to speed on where we got to make sure that we haven't missed anything and that uh people are on oh and the uh uh the recording got posted.

B

Three hours ago, while I was still in.

A

Bed, well, that's good! um Hopefully those of you in Europe who are awake for such posting might have gotten the chance to watch the uh the video, but we, as you saw, I, went and posted uh before the session.

A

Yesterday the sort of list of questions we honed in on a couple of uh points that I think people were in relative agreement about and what I'd like to do is go over a couple of those see if anybody has strong different opinions or thought that I got the uh the points wrong in some way that I didn't summarize correctly and then to continue on and maybe get to the question of um what, if any, uh XML Source changes are acceptable and how those will work.

A

So what I think we came down to was that um the general policy questions of which presentation formats exist, how they should be managed should not be significantly limited by rswg policy per an RPC function to decide.

A

um However, the rswg does want to say, as a matter of policy, that presentation format should remain stable, even when tooling or XML Source changes and the particular level of stability. We want to get an idea of, and if there is a change in tooling or XML Source, we should do the re-rendering, but those don't necessarily need to be distributed.

A

We want to do the re-rendering As a matter of testing, but we could continue to distribute the original versions of the presentation formats and we didn't get too far into the what XML Source changes are acceptable um or how they need to be marked or versioned or distributed so Paul. Why don't you start us off.

C

So greetings um I. Think I started you off about 10 minutes ago uh with a message to the list um reiterating what both Martin's had said.

C

um If we want to go down the path that you just said, Pete, which is a change to the XML that doesn't affect the reader, much or you know, would only visually affect the reader wouldn't do it um doesn't cause a re-rendering. Then we have to change 7995 to remove the fact that the PDF says it.

C

Having said that, um I want to since I wasn't here yesterday, I want to um suggest that the first part of what you said, which was that the group said we probably you know, don't want to overly restrict the the RPC. That sounds fine to me, but I also think we can help the RPC by giving them guidance on anything that we think about re-rendering.

C

As long as it is just guidance where we end up trusting them and I'm a bit concerned that what you said makes it sound like there is no intention to add guidance.

C

um I I would like I would like this group as a policy to suggest guidance. Thank you.

A

And that seems reasonable and when um you dropped off before I could ask a question, but um I I did want to get a sense from you of.

A

um Does that distinction about re-rendering, re-rendering and testing versus re-rendering and distributing um I just wanted to find out? Oh.

C

It has to be distributed right. That is.

A

I just make sure I understood what you referring.

C

Yeah, so so, if it according to 7995, um as my reading of it, I mean Jay May disagree. But um if that, if, if I get the XML and I get the PDF, the XML, that is embedded in the PDF, if it doesn't match the XML that I just got off of the of off of the RFC editor's website. I would consider that an error.

A

Interesting; okay, thanks that helps um Jay or up to bat.

D

So yeah yeah I do agree with Paul on that last part. The the bit that uh I'll send this in a message to rswg. We can actually take an existing PDF file and replace the XML that is embedded in it without regenerating the visual representation part of it. Okay, um the bit that I'm concerned about is how we verify a mass regeneration or visual representations, and that's the bit that I'm trying to you know reduce to where we have to do it.

A

John go ahead.

A

I mean while you're joining I will mention that um Robert reminded us yesterday that uh using the local mute button, if you plan to speak multiple times, the one in the lower right corner is much faster than uh turning on and turning off the The Big View button.

E

I I would suggest a slightly stronger Criterion than the one implied I think by Jay's comments, which is that if that PDF starts to change it even bit wise in the ways which are invisible, we then start having problems with what's the authoritative copy, because people are going to want to verify that the copy that he used to have is or is not the same as as the one which they just got to like get, and the only way to do that ultimately or the only straightforward way to do that.

E

Ultimately, and that gets back to both Jason Paul's point is to a bit wise comparison of the two files and if we start saying well, the visual representation hasn't changed or the visual representation hasn't changed very much, uh but the XML has changed. Then the bitwise Compares don't work and the problem which Ryan carpenter has raised multiple times about making certain everything we do, which is different in any way, is properly documented or dated start centering. The problem.

A

Yeah and I think that does lead us to that bigger question of um how to Mark version um the presentation formats as they go out so that people know what they're getting.

E

And how to Mark the action? Oh when it's modified, however, it is modified so that people know what the micro version of that is regards to whether it affects presentation, changes or not.

E

My my problem with the following along is that I find a pretty hard to separate the set of issues into nice categories and and therefore discuss them separately and that and at the same time, I recognize the problem you have, which is, if we don't break them out in separate categories and try to analyze them separately, we will make no progress at all, so I think there's a contrasting dilemma. There.

A

Yeah and I think, as came up on the call uh yesterday, um you know my my purpose in putting out the thought. Experiment and the you know, uh setting the the ridiculous ends of the discussion um was to sort of spark the discussion and get us to hone in on what we really intend.

A

um Elliot you're up.

B

F

Morning, good afternoon uh to people good evening to anybody who is uh Wellies to me, um I was I just want to say two things. First, um I think the uh identification of new versions was actually solved, um I want to say the 1800s, but maybe in the 1700s with uh printing numbers, and it's something that we could use I. Don't think this is a challenge that is beyond our grasp.

F

um Let's make it clear where the line is between a repo intended Edition. Let's make sure that there's you know, no, uh you know and I think that long is pretty clear to everybody on this call by the way. Well, not too concerned about that uh I think we had a good discussion yesterday and I think Jay you, you really summarize things very well uh even today, um in terms of uh you know when when we need to do represents, I did not know that you could substitute in the actual an existing document.

F

That's that's that's very interesting. The second point I wanted to make- um and this is I just want to lay down a marker, which is we're spending a lot of time worrying about the existing uh document.

F

Series right I would like us to spend a little bit more time on the future um in terms of what we where we want, not not just changing the existing documents, but we want the future documents to look like if, if we were to separate those out and then there's two different problems right, it could be that they unite and combine nicely later.

F

But I feel like we're, holding ourselves back by worrying about the the existing by worrying about changes to the existing series and and not focusing as well as we could be on, say what the future series looks like now. I realize that's a very big statement, uh a very open statement, um but it's a caution right. We can we we this group people who are on this call uh like to flip ourselves up um in in terms of process, so we might be able to untrip ourselves up a little bit.

F

I think there's a lot of stuff. I love the discussion about Marathon since I. Think it's a complete thing that we should be thinking about. uh Incorporation of uh other other data forms in the source form. What it looks like in the rendered form what it means in the intermediate form like these are all important points and I don't want them to be lost sight of, as we try and think about the existing Series. So thanks very much everyone.

A

Yeah I'll, say Elliot that you know um part of the reason I wrote up my thought, experiments. The way I did and sent out that message was my sense of the discussion was those future looking things are interesting but relatively easy compared with the backward looking stuff um that we seem to be hung up on them and I sort of wanted to clear them off uh clear those issues.

A

First, um because I think the whether to use mathml, I I think it's going to be a controversial and interesting discussion, but I don't think it's going to be hard. The way this one has been.

F

Yeah yeah and just to follow up right. um Sometimes let me restate what you just said in in more succinct terms: let's go for the low-hanging fruit where we can I think be nice to notch. Some wins.

A

Yeah appreciated.

A

So I'm not hearing screams of a Pete. You got the whole summary of yesterday wrong or B um uh I wasn't here yesterday and you people were idiots uh Paul. Do you want to uh make.

C

That claim yeah well I I thought you had more to say. You only did the first bullet point, so I thought you were going to go through them all and then I was going to bring stuff up no.

A

Jump in any time you like on any of those okay.

C

um Then consider me jumped here: um I wasn't on the call yesterday, so I didn't hear the flow of things, but I've been following the list fairly carefully um I'm having some cognitive dissonance with the idea that we should be keeping the um we should not be republishing. The derived formats very often like Jay, just suggested, even if we've regenerated, even if we've changed the XML, maybe we just jammed the new XM XML into the old re-rendering.

C

Going back to what I said earlier, I think it would be good if we could help the RPC decide and I think the rule would be. We have a zillion different kinds of readers of rfcs, but here are the ones we care about the most I'm. Sorry and those readers will have different desires for do you regenerate or not? Clearly there are you know. One set of readers is people who said well, you never used to regenerate. You know when it was text.

C

Only therefore I want that old world and then there's another set of readers who say when I go to to the RFC editor site and I. Look at something I would like it to be maximally useful to me, regardless of what the history is.

C

um I. Think personally, from my recent experience, the two most important set of readers of rfcs are implementers and people who are writing rfc's that are related to the RFC that they're reading in both of those cases, I would believe that they could care less if the HTML looked slightly different than it did a week ago.

C

As long as the text had not changed and to me that says, regeneration is just fine as long as it is consistent as long as when I go to the RFC editor's site and I get whichever format I care about that. If I'd gotten a different one, it would have been consistent.

C

um Both of those groups will care somewhat about the history of the rendering, but only a little bit. So if that information is there, you know and is retrievable by them, and maybe they even want to retrieve an old version like if they look at the version, information and say: oh wait, I think I was reading this six months ago and it says that that somehow it's been re-rendered in the last six months.

C

um They may want to go back and look and probably the only reason they would want to do. That is look at a diff, um but those people and again I I, truly don't care about Librarians here, I, truly, don't care about lawyers and such like that they're all valid readers. But but if we focus on them we are not serving the readers we care about the most.

C

So my view is tell the RPC do what you want and if they want to in order to keep things consistent, re-render that you know that's just fine again. This is all preceding any actual change in the text that would affect the reader.

A

Cool Rich, your.

A

And Rich, you are not making noises.

G

Oh so now I have two mute buttons. I have.

A

To like there, you.

G

Go um yeah, so this is clarifying for Paul I. Think I heard him say we care about. You know two communities use two Community abusers, those writing rfcs and those writing and I wasn't sure what he said. If he meant you know if he meant derived Works modification works or implementations implementation.

G

Okay, so you didn't you weren't intending to refer to just the people within the IHF community. No.

C

No, no! No! No! No! No, okay, absolutely not that that was and I put those first by the way they.

D

Are actually even.

C

More important than us, because we know our rules and they don't correct.

G

Okay, thank you very much. I agree with that.

A

E

I'm gonna make a case for uh for librarians and uh and more important for product managers and marketing people and their lawyer, friends, uh uh which is that for both of those groups.

E

Ability and predictable is important uh being able to understand exactly what uh changes have been made, and why is important uh and uh and having things change out from under them in ways which could in somebody's perception, even a extremely creative and hostile leader of the rfcs uh pull the ground out from under them when they are shipping products, making promises about products making promises about conformance and a variety of other things are really important, and while we don't see it on a day-to-day basis in the iepf, It ultimately affects contributions.

E

It ultimately affects our liabilities of lawsuits uh and it, and it affects the indirect liability of companies promoting products based on our standards, to continue to do that, all of which are probably important uh can I rank those above or below the ones that Paul cited, um I, don't know, but I don't know it's useful at first.

A

C

On to respond to John No, it's not useful. We have to have a priority and to me the priority is the two groups that I said above those are people who would want to see something that matches what they thought was what the ietf decided again. We are only talking at this point about possible visual changes such as line re-wrapping, page breaks, and so on. Once we start talking about actual changes to the text such as indications that this RFC has been updated later by that one or that this RFC has Errata in it.

C

That has been agreed to those those will very much affect the groups you're talking about and therefore we need to consider them, but those affect the readers themselves as well and I would still prioritize those. If we prioritize at all the groups you just talked about John, then we should have never even gone to XML. We should have stuck with the old tax format when we went to the XML. We purposely said.

C

We know that the people who want absolute stability are going to be hurt by this, but we believe that the ietf community and the developer Community will be helped.

E

Paul we're we're in we're in 90 agreement about that and what's the other 10 is questions about whether based on retrospect and experience and thinking about things that XML this season was the right one or the wrong one, and uh and that's uh and and that's where again, I will defer to some of Brian's comments uh and uh if.

C

This group wants to make a policy to stop doing XML. We have the ability to do that.

E

And and I would agree with you 100 about what you said about those priorities. The moment we decide. We are not on standards business, but merely in the implementation specification. Business for people are interested in understanding our specifications and following them.

A

Go ahead, Drake.

D

Thanks Pete um as I understand it, nobody has argued against us having a very robust and very transparent um uh record of all of the changes that are made as part of any form of um regeneration, republication process um and I. Wonder if it's possible for us to sort of um put a um stake in the ground for that one and say that we're all agreed that that has to be there that to prerequisite, and if we did do that, how much that might address any concerns that um John has just expressed.

A

You broke up at the end of that sentence. Could you try again.

D

Sorry I was just saying that if we could all look if we could agree that we had a that, there must be a robust and very transparent um change um uh change system here that everyone can see, then, would that address many of the concerns that John has there got it, but yeah.

A

C

I fully agree with with what Jay just said: I think that that would alleviate the concerns. um I. Think again, we can do this, not as policy of how things are done, but recommendations to the RPC um saying that these are our our most important users of the RFC series.

C

They will have some things that they want and I believe what Jay just said, while not being foremost in their mind as much as it would be for like when we bring up oh lawyers and stuff, but it is something that a developer would want, because many of them like, for example, if I'm developing a DNS tool and I, need to look up something about TCP, again God, damn it I will look it up and then I will look it up again. Six months later, it would be nice if I could see that.

C

Oh well, since I looked at this last did anything happen. So I think that that is a perfectly reasonable thing for that user to say there should be a way for them to do that.

A

A

Yeah John go ahead.

E

Yeah, let me try to draw distinction which I have been sort of circling around um if we are in the.

E

Specification business for implementers one people are interested in a particular thing and how to do it and sharing that with other people might be interested in implementing it yeah.

E

We have a different set of constraints and objectives, and maybe most important audiences, although and questionable how you can find that we do if we claim we're in a standards business as soon as we're in the standards business we start talking about performance or the lack thereof and buying points of intellectual property rights is distinct from broader issues having to do with who can Implement what uh we're in a slightly different business, and it's changed the discussions and I'm at the stage with the IDF where to decide that the decisions go into standards business.

E

How many years ago was probably a mistake and we should be back at the implementation specification and discussion. Business I would lose very little sleep over that, but it's not a decision. The community has made. We continue to talk about our social status body. We continue to stand up in various places and say standards body.

E

And as soon as you do that you bring in all of these other issues again um for fine details, the implementer is a primary.

B

E

I agree with Paul uh for involving those implementation specifications. Authors are a prime audience, I agree with Paul, but to dismiss the others or claim their secondary doesn't work for me as long as we claim to be in standards, business.

A

A

Trying to get my head around how we as a community might move that needle um Paul go ahead.

C

As much as I hate to tell the working group chairs what they should do, um I believe what John just said is wholly outside of our Charter.

C

If later the ietf charter changes in some way, then great, then we can come back and revisit, but our Charter is to deal with what we've got in front of us um for rfcs, for readers of rfcs, for mechanisms for making rfcs and um I believe that the last six weeks worth of discussion on the mailing list shows absolutely that different types of readers have different desires for stability of different things.

C

Stability of the XML stability of the rendered XML and such like that I mean that's been super super clear on the mailing list now mind you much of the mailing list was saying I'm talking about what other people want. Not me, we don't have a whole bunch of developers on the mailing list.

C

You know people who are implementers saying this is exactly what I want, but it wouldn't even matter if we did, because that small number of people who happen to be on our mailing was absolutely will not be represented, and we don't know in which way.

C

So we have to make a guess, but I would say we should make a guess within our Charter and our Charter is not about deciding. Is the ietf standards body and what that means. Our Charter is to take the current world and try to reflect it as best as we can in the RFC series, foreign.

E

With Paul about the scope problem but I think until an unless the ietf in some fashion, uh chooses to uh change its scope and decide, we are or not they decide. We are not our standards, business rather be in standards. Business then we are stuck in. This working group is stuck with the backyard IDF from the standards business and indeed, uh making decisions which are incompatible with being the standards.

E

Business are taking us out of scope and contradicting what is generally considered to be the iatf consensus and as well as that, scope problem and again, we need to be reminded that this working group is neither of the audience for rfcs nor representative, the ITF. It's the people who have decided that it's a good use of their time to spend time worrying about these set.

E

These sets of details and policies in the RFC series, but we can't say that, as a consequence of that, either our Charter or the composition of the working group that the rest of the world goes away and that's the reason why the standard issue is important.

E

Now not as a chance, we could make the change, but as a constraint.

A

uh I'll say from a you know from the perspective of me um as chair.

A

There is an expectation in this working group and I I presume that, uh even though he's not on the present call and uh Lars or his predecessor will eventually pipe up, um there's an expectation that the stream heads and assorted others from each stream will participate and express the needs desires of each of the streams. So.

A

I would expect if we made some sort of statement along the lines of. We think that the order of priority for who we are going to serve is x, y and z, that the ietf stream head might come back and say whoa, not quite or might come back and say sounds like a good plan to me.

A

So I agree with you. We cannot change the status of what the ietf wants out of us, but we can certainly listen to responses if we think as a matter of policy, we think this is the best way to lean um prioritized readers over um assorted, other folks, John go ahead and then I.

E

Think that's right, uh except that we need to keep in mind um for uh For, Better or Worse, that the IHF share does not represent iatf consensus without some actions that the ISD speaking as a group does not represent ITF consensus without some actions. The other streams are each different in other ways, but uh but again we need to be careful there and we need to be responsible to those communities. Even if making changes foreign.

A

Yep agreed um I, you know, I do think the ietf chair and the iasg can say we believe this is the consensus of um the ietf4 has been um expressed. That, and um you know the the community can always say you got that wrong. But yes, in general, I agree with what you say: Elliott Europe.

F

Write it so um I'll just comment: I'm.

E

Here the primary.

F

Reason I'm here is because I hold the position of the independent submissions editor and the way.

B

F

The the the enabling document I really have to be here.

F

um So uh that's why I'm here um and I hope everybody agrees that I'm participating, perhaps even a bit too much so uh but I with the and by the way I I want to comment that I'm not passing judgment on uh the IAB or the ietf uh chair on this. They all have their own priorities and while they and they may read the document differently, as they may want to see uh fixed proposals before they pass judgment um and that may just be the the most efficient use of their time.

F

So I'm not I'm, not passing judgment on them, I'm just saying how I read things and and how I'm, using my time.

A

And for the record.

D

Myrias on holiday.

A

This week- and let us know ahead of time that there.

D

A

To be a good day that she could make it in this week or next.

A

I'm, looking at the list have we settled in people comfortable, Where, We, Are Paul go ahead.

C

Have so proposed next step is Pete that you write up what you've heard today, send it to the list and that Martin uh Thompson revises his draft and that the working group figures out, whether that's right and, if so, either adopts it melds it into mind, mind melds into his or whatever, and um then I would say.

C

A next step is for, at least for me to propose some wording for whatever the document is of what we want to say to the RPC about priorities, so that you know so that they can make choices on on the rendering and re-rendering themselves so take what Martin has add some to it add something to it after the next version of um uh suggestions to the RPC and then figure out how to turn that into a working group document or not. However, that goes that's my proposal.

A

D

B

D

um I still don't think we're operating at high enough level in terms of our um understanding of the requirements here. I think we're getting better because we started talking about the end users of things, um but we're still a way off. I think um where we should be. um We, the the RFC Series, has a um a brand, a reputation. It has a um uh a usage.

D

It has a um you know, an impact and I think that those are the that's the level at which we ought to be considering the guidance that we provide around this, um and we ought to particularly be focusing on the risk from things.

D

um If, for example, we were to um inadvertently re-render 3000 PDFs, so that they were black text on a black background and we weren't to spot that or something you know um these, that's the position. I think we ought to be starting from we're. We're still I think looking at the mechanical level of guidance, rather than that big picture about the the series The.

D

The reason I say this is because the decision to make a mute immutable- you know that was made some time ago has in you know, has created a particular brand has created a particular um set of um high-level um understandings about it, and we can't ignore that. We need to think from that same level as about the changes that we're going to make thanks.

A

A

D

A

Be muted, John.

E

Too many buttons I'm finding myself in complete agreement with Jay's comment and uh and I, don't know, unlike Paul's comment, how much further we can get with the documents without opening up the can of worms about what substance changes are not permitted where something that is Loosely defined as changes.

E

What the rendered output looks like, whether in the direction of Jay's extreme example about black text on black backgrounds or whether changes in direction of what some people might consider grammatical errors that other people consider substantive or changes which we might believe are corrections to substantive errors in the original event that need to be fixed, and there is probably some sort of spectrum there or maybe there are orthogonal, but until we open address that can of worms, I, don't know, I don't see how to make significantly more progress forward. Although new drafts might certainly help.

A

Yeah I'm I've been trying to understand Jay's point a little deeper.

A

Because well go ahead! Michael.

H

I I guess I, don't really understand John's issue, um but maybe I can re-explain it. He can say yes or no. um Is he asking? What is the division line between um um uh uh uh approval-less uh edits and errata.

E

uh No I don't think so.

H

Okay, so for all the things that you talked about grammar and this and what might be a grammar change and whatnot those all fall into Errata today, if you want, if you come up with a grammar, Miss typo, then you file an editorial lorata right. Well,.

E

uh Yes, but the first problem is that I have deep concerns about the Errata system and.

H

Okay, but that's not our.

E

H

E

If you assume you yeah I have two concerns about the erotic system in its classification model, so this one. So so this actually the case that one person's grammatical error could turn out to be somebody else's substantive change and I'm worried about the subsidic changes, but.

H

Those are all lorata. Do you agree? Those are all Errata. Just you just have.

E

A problem which category it is I believe they are all filed as a router, but to the extent to which one of the changes we make to the rendered rfcs is to reflect those irana and the decisions about them. Then, regardless of whether they started out as a Rada or they started out somewhere else, they are changes to the rendered.

E

Rfcs and I haven't been talking about Arana on this call, precisely because I've been talking about the issue of changes or not to deliver rfcs, which is slightly different from changes to which is, is a super separate, perhaps of changes to rendered rfcs.

A

Okay, so let me do a chair interrupt here, because everything on my sort of thought, experiment, questions list I believe- was either changes to the rendering engine which might produce different output or changes to the XML source which might produce different output, um and things like Errata I agree with both of you are a very separate category of changes to the presentation that we have to deal with at some point um and we may decide to punt it by way of dealing with it or insist that the Errata system gets changed in some significant way to deal with it.

A

But those issues about presentation, changes, I, think, I, agree with you, John they're, a much bigger can of worms um and I'm inclined to leave that can closed until we sort the rest of this.

A

C

It will go further than your gentle decline. I would say we cannot look at that until we have looked at this and therefore I disagree with John's proposal that we talk about it more before looking at drafts, I think that this group is not a good Discussion Group without text in front of it that we end up wandering much further into solution.

C

Space, um I and I would love it if every time someone says Errata or you know, was updated by that the chairs just slam it down for now, because we know we're going to deal with that in the future.

C

It's not a question of if it is definitely a question of when, but the when should be in the future after we have done something here and have given ourselves a few months of seeing published rfcs under whatever we just changed, then we will have a feeling for how did that thing that we just did change the RFC series, the perception of the RFC series and such like that, so that we can make a more informed decision about anything that changes the content.

C

um We have a set of possible changes to the XML that we've been sitting on for almost a year now or we've been sitting on for more than a year. Now um those will change some rendering, whether it's rendered in the current. You know we re-render or it'll change, the rendering of of other RCS. We sh, you know we're not in a rush on any of this.

C

We should take steps and and Pete I'm serious I really would like y'all, you and Russ to say we are not going to to open the can of worms period. We will not until we have experience with um the the outcome of what we're discussing now.

A

John go ahead and.

E

And and I would consider that completely reasonable and agree with it, except for.

E

At least my interpretation of the problem and saying emotions, which is that in the process of experimenting with this and try to do a series of incremental changes rather than making changes only when we understand where we're going we're running some risk of messing up that brand and part of that brand is also associated with my issues about standards versus implementation, specifications and all the rest. But that's the that's. The problem would I prefer to see us figure out a way to proceed. Incrementally on this.

E

Absolutely yes for reasons which probably match pause that certainly match General good sense for making progress. But this is a complicated system and I. Don't understand how we say: okay, we're going to ignore all the rest of the system and go to deal with these things and hope that that doesn't have no effects which causes electron later or causes external difficulties, including that brand protection problem.

D

A

Russ you're locally unmuted, because I'm hearing clicky foreign.

A

B

D

Thanks Pete, you said you didn't. You were still thinking through what my point so I'm going to give you a couple of examples from um uh from my draft, there did not say the rest of the draft is in any way applicable, just pulling out a couple of bits. Okay, so one of them is about the frequency of change, um even if we had very good reason to change something frequently.

D

Would we want to change something frequently um say, for example the PDF okay, um because how would that drive a different Behavior or expectation amongst the people that um consume it?

D

um My own view, by the way, is that this is perhaps driving us more and more to the HTML being the um the expected, authoritative, Red version of things, because changes to that are are not noticeable in the same way as they are for a PDF. If you know, if we've got like version 764 of a PDF, you know out there, um it doesn't happen in the same way to that.

D

um The next thing is, you know the the reasoning as to why we make the change now. We've I agree with Paul. Let's put aside the idea of um content changes, you know aside okay, but we do have the things that you described. um You know the the change of the tools we have things like.

D

You know, white lines, we have metadata, you know the markup layout and those type of things um we I think we need to set a principle about how often something changes for those or or what a threshold basically, rather than perhaps a timing around those as well.

D

um You know um if somebody, if we all agree that um you know that they're all going to do what we I think we all think is a perfectly rational thing of have two spaces after a period instead of one space after a period, are we going to go around and make any changes for that? You know, um for example, that's the type of thing we need to do, and then the um final thing here I think I've got in my list is you know.

D

Is this question about um publishing something when there is nothing changes as well? um When we have, uh you know either bit for bit identical change or you have no change to the visual content at all. um Are we just going to confuse people by suggesting that we've changed something there and false papers? Look for it or you know so, so those are the type of questions. I think we just need to answer from from that user perspective and try to put those in they're.

D

Just you know, I mean it's not meant to to stop it and I, don't think it's particularly hard, but it just changes that direction of thought to how how people consume, rather than how we produce.

A

Yeah and and I think- and you know, Russ and I have to go and write up the discussion from yesterday and today, but I think I'm hearing General agreement on the answers to those questions being yes, the changes should be at a slow pace, not at a fast pace um but yeah I I. Okay. That does help me um that that I agree. We have to come up with those principles.

A

We are five minutes from the top of the hour.

A

We are obviously not getting to the um what XML Source changes are reasonable, how they should be implemented, how they should be put into old rfcs, and such anybody have final thoughts on the rest.

A

B

John, what question Pete um do we want to tackle that XML changes topic at the next ITF, or do we want to do an interim, say uh three, four five weeks from now to that, that's that's! I would like to spend the few minutes. We have left deciding whether we want to do that.

E

Pete now you're muted.

A

Damn it um yes, either of the two of you John or Paul, on on the topic of. Do we want to dive into XML changes on the next uh on on a um at the next ietf meeting, or should we have an interim in between.

E

I think an interim would be worthwhile um uh and and I also wanted to add something else that Jay mentioned, which we are not addressing either, which is the question of whether we are changing the normative form or the even the normative presentation form from uh from uh looking at the PDF to working at HTML. That's another whole can of worms which we haven't addressed and I'm not taking a position on it. Only pointing out that uh it's something which we need to put in the queue somewhere.

E

Near it again, Pete.

A

I can't keep my state um so Robert points out. The next ietf meeting is in one two, three four, that's longer than four weeks: five, six weeks from now yeah, so um yeah we would have to have an interim right soon. If we're going to do it.

A

C

um I will strongly disagree with John that we should have another interim on that topic. I believe that we need to nail down a consensus view of how we want to deal with re-rendering and such before. We actually go into what will happen that might cause a re-rendering. We know conceptually, but there are some issues on that: I, don't think we need to rush it and I would like us to stop discussing and actually writing stuff into drafts. I'm. Sorry, if I'm being repetitive here and I, think.

D

C

That isn't a good idea.

A

So I will say: Paul, given yesterday's discussion um and Russ and I have to write it up. I I, the reason that I think it's actually plausible to do an interim on the XML topic is because I think it's plausible beforehand on the list to get the consensus you're talking about and starting to get things into drafts right.

C

If so, but then again from a meeting.

A

Yeah yeah, yeah, yeah, I I think it's plausible that we start honing in on that on the list in the next couple of weeks and that getting a stake in the ground on the XML thing in an interim might be plausibly useful.

C

Or just do it on the list.

A

Yeah I think if we can start it on the list, I suspect. um As with the topics we've been discussing, the presentation format, topics that um uh you know it's going to take a little voice to get that going, but I'm certainly willing to give it.

B

B

If not go ahead,.

B

Okay looks like we lost Pete mine is showing he's offline.

B

So uh John you get the last word if, uh if that's a new hand, otherwise Pete and I have some homework all right, we will send out some notes and uh follow up on the list, we're going to end right on time. Thank you all.

B