Internet Engineering Task Force Interim Meetings, 6 Dec 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-TOOLS-20221206-2000

Description

TOOLS meeting session at IETF
2022/12/06 2000

https://datatracker.ietf.org/meeting//proceedings/

A

Any chance of talking into sharing video Carson.

B

A

Me is there any chance of talking you into sharing video.

B

uh Unfortunately, I'm sitting at the laptop that tends to overheat, if I do that so I'd rather not do that.

A

Yeah generally, with these workshops and meetings, I try to get as many people on the screen as I can try to make. It feel like a around the table session.

B

Yeah and a good idea very much but I'm not going to get up for that.

A

We'll give it a few minutes for more people to join.

A

Greg, you should add yourself to the notes page.

A

A

All right we're going to get started very quick very soon. um If you are able to share video, please do so. We want to make this a meeting around the table.

A

We are scheduled for an hour um I'm willing to run over. We can go until Miko kicks us off um than anybody that needs to drop at the end of the hour. Can let's try to get as much of our agenda covered as we can in that hour?

A

Hopefully, everybody knows where the notes page is. If you don't um help each other out, ask in the chat. Other people can point you there. If you're not familiar with notes. Note that at the top there is the ability to edit I prefer the pain that lets. You see two columns, both the edit column and the render column.

A

uh Try that out. If you haven't tried it out already um jump in now and if you're not already, if you're here and you're not already marked as attending um mark yourself so and if you're not on the attendee list, already add yourself, please.

A

The session is being recorded and it will become available in the YouTube channels is in interim meeting of the tools group.

A

I, don't think we need a dedicated Note Taker, um given that we are being recorded um if we need to go back and pull um detailed notes out of it and do so by referring to the recording. But I would appreciate if there are particularly Salient points captured as we are talking that somebody just hammer it in as a uh an observation that we made on the on the notes page, it's easier to work with things that we capture as we go along than it is backfilling. After the fact.

A

So the setup for this is that we've had several years of discussion at this point around what we might do differently um around making our artifacts available to people on the internet at Large.

A

um Looking at it, both from the the facet of how do we promote efficient work among our community members as well as how do we make our artifacts accessible, easily accessible to the people that aren't making standards, but the people that are using them so or any of the other work um products of the ietf and its related communities.

A

So we've got several websites we've grown organically. There are different decisions made in the different properties that we have. We have had arsenic, endpoints, we've got our sinking points, um they're, not consistently engineered. We have pieces of the www tree that show these various artifacts rfcs and IDs in particular, in not obvious ways to the outside world.

A

There's um a history of the outside world, referring to tools.ietf.org. You know baking in links to tooling at places like stack Exchange.

A

um What we want to talk about today is whether or not we can do things differently. What that different might look like to try to get a more unified and more accessible View and something that's more effective for the people that are working on building our our work product, as well as making it easier for people to use our work product in the end run.

A

I think the conversation is quite likely to be dominated by discussions about how we handle internet drafts and rscs, but as we're talking, please remember that we've got a bunch of other things. We've got meeting proceedings, um you know slides from the the meetings. We've got these other kinds of documents like status, changes where we move things from um proposed standard, full standard or from proposed standard, T, obsolete or historic. That should live pretty much at the same level as rfcs.

A

um There's a list in the notes document of some of the other things that we've got um that we want to make sure that we are are considering as we're discussing I see. Some people have already started. Adding discussion points feel free to do that as you go along. Something comes up that you want to think we should talk about during this during this time, uh just jump in and edit the the document is available for anybody. That's logged in to to start talking, I got a late regret from Jay he's.

A

uh Had something come up at the very last minute. He may not make it until late in the call, if at all,.

A

So, let's bash: what is in the four discussion session? Is there any I more or less listed it in the uh um priority order that I thought we should discuss things in if you see anything further down that you think is more important to get to earlier in the discussion. Call it out now.

A

I definitely do not want to be the one talking for most of this hour. I I've got my strong opinions, I've kind of put them into the background of this document. Already um Carson sent an email shortly before the meeting already, if somebody hasn't, if anybody here hasn't seen that already I encourage you to go skim it right, quick, um it went to tools, discuss um and if anybody has opinions that they want to put down in a long form by email, later feel free to do that as well.

A

So, let's, let's go ahead and jump in. Let's start with this first bullet we've got right now things spread between different sites.

A

We've got a a I'm going to assert Legacy and maybe unfriendly to the outside world division of things that are supposed to be at the RSC editor and things that are supposed to be at the website, and things are supposed to be at the data tracker I'd like to challenge this, and this is what is in Carson's message with the for our word products for the documents that people are going to come look at.

A

Why do we not just put them at one place and make that place the thing that we train all the search engines to go to? You know that we run up to the highest point on the SEO um and that we encourage places like stack, exchange and other external organizations that are linking programmatically to link to um what? What is the downside of pursuing a path like that? Whether it's name is docs.ietf.org or what you know, I think is a separate conversation.

A

But what what's the downside of of pushing things to being a single pile, I'm really expecting Alexis? And you know, Alice to jump in here.

A

And I don't think, there's so many people here that we really need to use the Q mechanism just on mute and start talking. Please.

C

I, don't think, there's much of a downside to consolidating that doesn't strike me as bad. um But uh what does strike me as bad is changing the archival URLs of rfcs.

C

um If we've spent 53 years saying this is the URL for an RFC. Please use this uh you're a like. You know: well not 53 years I understand, but a very long period of time um telling people that that's the archival URL and we change the archival url. That didn't seem like a good plan.

C

I don't have a theoretical issue with them all being in the same place. um I just want to call out that particular issue.

C

A

Continue to exist, but redirect to this commonplace that we're trying to that we're talking with that we're discussing.

A

And it would be an easy redirect pattern to set up.

D

uh We showed that the redirect works for any case.

A

Say more good I.

D

Mean I think you need a real browser to further redirect. Maybe some other tools will not follow the redirect, don't compliant tools right, but just to give you an example right. So I was using a subscript in a generating PDF and they changed somehow the URL for the image inside a PDF changed and the PDF generator was unable to generate the image anymore.

D

So it's a corner case right, but if we do redirect, we need to be sure. For instance, we are serving the same mime types as well.

A

E

Sorry, there's a lot of latency. It makes it hard to just jump in um the only case I can think of well, we might worry about having a single um sort of URL of the main problem as if we want to Brand the different streams differently.

E

You know, for example, if you want to put the irtf ones on an irtf domain or the independent stream ones, and that's the different domain to the ITF stream.

A

All right would that be something that you think we should do to the irts Stream.

D

I mean if we need to say to the end user right, the consumer of our artifacts. Oh, this is RTF. You need to go there. Oh, this is ietf. You need to go there. Oh it's ice. We need to go there. We are losing right.

E

Yeah we're losing um equally um if we're trying to um brand the irtf for somewhere where research happens and we keep pointing to the ietf that distinction between this is a research thing, and this is a standards thing that gets ever harder to uh claim. So I I'm, not sure what the right answer is here, but that's you know if, if it's RFC editor.org, that problem goes away. If it's an ietf.org domain, then then that that has branding issues.

A

Yeah well so drafts I think are used by both of those streams. All of those streams and those wouldn't live at RFC editor.org.

E

I mean probably the answer: is we just use an itf.org domain for it all right so yeah? If, if you're asking me to think of potential problems, that's that's what I can think of.

A

And that's exactly exactly the kind of things that I would like to pull out in. In this conversation,.

C

Just to call it, you just said: internet drafts wouldn't live at rsditor.org. Why.

A

So main working property.

A

Okay, I'll answer that directly. There is already a very difficult problem that we have with signaling to the people that aren't working on standards, whether something is a standards track document or not right. So if something has been approved, even has consensus to be published as an RFC and if we suddenly have internet drafts, which anybody can throw anything at all up as an internet graph showing up at RFC editor.org, then we're going to um disaster make that confusion quite a bit.

A

So the if we move to a single site I, don't think that single site should be labeled, RFC editor.org, because it does then imply that this is the place where um approved. Things live as opposed to. This is the set of all resources.

C

So I would say that the reverse is also true, then um meaning putting the rfcs the these are approved and published onto something like data tracker ietf.org implies the opposite right that everything is provisional, um so I think what you said argues for keeping things separate.

A

As opposed to having a docs.itf.org, which the name implies, nothing all right, the data tracker would then talk about metadata and point to docs when people want to consume something.

C

Because they are like, if proceedings and meeting minutes and things that we don't consider to be, maybe on the same level as a published, RSE um I'll live at doc.ietf or docs.itf.

C

um Don't we have the same problem with people's perception.

A

Carson you have thoughts on that.

B

Well, I wrote in in my little piece that I don't let me check whether I can fix the audio one. Second.

A

B

You're coming through yeah but I'm having a problem with this agency anyway, um so I wrote that I didn't really think about that very much I'm, really mostly interested in in getting our working documents, um easy to peruse um it's quite usual, to find an RFC number or a draft name somewhere, and it needs to be easy to build uh UI out of that menu or semi manually.

B

So that's really important to me um whether the other documents uh uh uh as easy to access from from the the browser address line is less important to me, but in any case, I would uh prefer a situation where uh everything that is under this. This common access point.

B

um Is uh clearly labeled, so we are not putting out raw text files uh or even HTML files, where you have to know really a lot about the process to understand whether these are drafts are completed. Documents I would like to have that information in a top bar in the document every time.

B

So that's why I wrote there needs to be a working page form which is probably similar to how we have been doing htmlis, uh except that maybe we do the status information even more in your face than we do it with uh htmlised, um so I think we can.

B

We can even have different colors for for different screens and things like that uh I'm not proposing this right now, but but that's certainly something that this approach would allow us to do um so. The the um I don't have a strong opinion on on all these other uh things that that we need to look at mainly care about the the actual documents IDs and Pharisees.

A

So you've segued a bit into the next discussion point, which is what that looked. What we should point to whether or not we have things that point to a landing page or things that point to the document content. I'll summarize, your opinion is yes, the page that we should land that we land on should do both of those things. There should be content forward, but clearly labeled with the metadata.

B

A

So the to to be very clear, the idea of a landing page that doesn't show the document content is something you'd like to get away from. Yes,.

C

I would agree with that. I mean the the SEO implications of not having the content. There is one of the reasons why RSC editor doesn't show up when you search for RCs in Google right. So if we've disadvantaged, RFC editor.org our archival place for showing these rfcs by not putting the content there.

E

Yeah I I would also agree with that. Although I would like a a canonical sort of obvious URL for getting the raw content so machine, so machine based tools can process it. Yeah.

B

The landing page that can be linked off the landing page so um I think it's really important to to have unadulterated uh archive Raw uh content somewhere, and we need this for two wheels. We need this to to assign them, um even if the the content of the landing page might might change all the time because of different status and so on.

B

um But if we can keep these two universes separate from each other, we simplify things for people a lot.

E

Sure yeah absolutely.

A

So you know I will toss out docs hyphen raw.ietf.org just to see if anybody says no, no, no, that's not what I meant.

A

E

They don't care about your thoughts like from roar or just a regular URL unbox tonight.

E

The default should be the landing page with the metadata.

A

I just note that large services that have to deal with the distributed content um are opting more often if we're using different domain names, because it allows you to scale the service underneath what's happening differently, so maybe even choose radically different Technologies. But since we're talking about serving the raw con, you know the actual document content in the the page. That also has the metadata that separation may not um have is it may not be as strong of it as of a design requirement to consider.

A

A

I'll go ahead and start taking through some of the other discussion points feel free to run back to these other two. If we discover a thought that we we should come back to you as we move forward there is this notion of having a um a pronoun. If you would, that always gets to the current version of a food right, current version of a draft current version of some minutes, whatever um I'm, not I, haven't been seeing a lot of pushback against providing this service.

A

Should that service exist at the same place as docs.ietf.org.

A

If we, if we consolidate on a single place, is it important that the service that lets you find current live at exactly that same place?.

B

But what what does current mean? So if I go for RFC 2246. uh should I get the current version of TLS should I get the the internet draft that that has the newest Miss. For that, um so I think we have to be a bit careful about this current thing. So on one hand, we we would like to guide people who are looking for old versions of a document that have been obsoleted by newer ones. We would like to guide them to look at the newer ones.

B

That's that's one thing, but of course we don't want to go too far and and offer this document that isn't even agreed uh on at the same time, so I think we we will have to do some of that using links and not not using automatic redirects.

B

uh Something uh like that, on the other hand, having a pointer in an uh in a document that points to the most recent version of an Internet draft is definitely a function that we need to provide.

B

So I think we need to do both, but with maybe with different semantics.

E

Yeah, but have a latest on some things that are only exist in one version and don't have this option.

A

So I think I'm hearing that we would have metadata on um Pages, where there are relationships like replaces Obsolete and whatever that we would point out that the that these relationships exist and you might and maybe even point out more than one depth. If you know a was obsolete by B, which was obsolete by C. We want to definitely you know, make sure that you see C early on and not just be pointing only to B.

A

But then there is the the question about things that already just have sequence: numbers like drafts internet drafts like that um being able to refer to those things by a pronoun so that you don't have to know the version you just get the latest.

A

Let me know when I come back, I don't feel like I got, I think that what Carson brought up is important, that we pay attention to these as separate things, but just returning to the the the just this. How do I get to the end of a sequence?

A

um Does that service? Is that something that should the URLs for that live at the same place? Is the place that you're serving the docs? Is that important, or can it be somewhere else.

A

I think Carson would argue that it's important that we're training people's fingers to type things and there should just be you- know, brains only get programmed one one way instead of two ways.

B

So let me give an example where, where the the distinction is not so clear, so many documents start as individual documents and uh version zero, one two three four and then they become working group documents and start being zero, zero one, two three four five and so on, and we already have endless problems with people referring to uh Dash or fall of of the full document, and you don't know whether they actually are calling about talking about the individual and and the working group document.

B

So this can be very confusing for people and and people tend to to use some some browser cache stuff. That then turns out to be a very old version of the individual document, and so on. So uh having an automatic progression uh from an individual document to a working group document can be a very useful thing.

B

On the other hand, you do, of course do want to be able to to access individual versions of the document when it still was in individual stage, so yeah I think we really have to look at the the use cases and the kinds of confusion that that we actually uh see today. So I I actually would argue that working group documents should number from the last number that the individual document- and so you never have that confusion.

B

But that's a separate issue, um don't have to discuss this right now, but that's an example where you actually want to to jump through a transition uh as seamlessly as possible.

F

um Just tossing out these seamlessly as possible I was thinking it might be nice to have a pop-up that says: hey. Would you like to see the latest version of this document? You know we see that you were looking at an older version.

F

um Would you like to be taken to um the RFC, or even perhaps the this um but I, because I would like to be told when I'm looking at an RFC that there's new work on updating it?

F

um I know this would be perhaps confusing to people new to um the system. But um if there's like, if it's draft involved, it's like and I'm, not sure RFC editor.org should be pointing to that.

F

But perhaps data tracker the whole where's, the archive where's where's, the work being done, um but I think the the seamless transition, I I, think the user should it should be put up in the user space the reader's face with hey there's something new: do you want to go look at it or maybe they do want to look at the O version, I'm I'm here, because I want to be here.

B

I would hope that we can keep the the booking Pages as I call them free of of required interaction uh like like a pop-up, because there are still too many uh things that actually operate on these pages in in other ways than than having a human sit in front of a browser.

B

um But I do think that having something in the metadata bar that is very visible and uh says, hey, you are looking at an old version of this document. You really intend to do that. um That would be very helpful.

A

So Carson, let me let me poke a bit at your your reticence against the pop-ups. um If we are particularly for green Fielding, if we, if we do a docs.iitf.org-like thing and we create a raw.ietf.org like thing, um why should we worry about the constraint that I mean we could just make the assumption that docs.itf.org is consume? My browser is full stop and that other things should be looking in the other place.

A

Is that is that wrong-headed.

B

B

Consumed by browsers is a pretty wide spectrum, um so I'm I'm not sure it's really as simple, so essentially that that's the old tension between making something useful for novices and and making something useful for experience uh user. So an experienced user would get very annoyed by these pop-ups very quickly um for for a new user, that's uh very useful and we could of course uh make preferences. So you can.

B

Can you put in a cookie that says no I, don't want that pop-up or yes, I do want this pop-up, which creates more complexity again, so I'm not sure I'm a big fan of that either.

B

um So if, if there is a point where where we do have information that is in your face, that tells you this is not the current version. You're looking at without going through a pop-up even protected by a preference, uh I would be happy, but I agree that other other Solutions are possible.

D

And we need to take care about the Google spider web spider running right.

A

Yeah and I'm also I'm, also thinking of apis I mean just there.

A

There was a piece of this that was in Carson's mail that um that that rubs up against this with the you know um easy way to get to the either the individual document or the working group document or whatever, by um providing fragments of the slug that we use to refer to internet drafts in particular right and I I doubt it will be in much traction with this, but I should call it into question whether or not maybe we should change the way we build. Our slugs going forward.

A

I mean still have to deal with the way we build our slugs for all the Slugs that we have for a ridiculous amount of history, but instead of trying to encode State into this into the into the slug like draft IET off versus draft some person, we just moved to slugs that don't have that metadata and that the Slugs resolve to something where you can get to the metadata.

A

But as I said, that's probably a step too far.

A

Okay, so we are 37 minutes in to our hour. Let me ask the next thing that I wanted to poke at.

A

We have, for reasons of History, a bunch of things that we serve with the same content, type that have different document models behind them.

A

um I will point to HTML coming out of XML to our cv3 versus htmlized, coming out of either the IDT RSC stuff picking text and turning it into HTML or the well taking the V3 HTML and and doing CSS um rendering modifications to it um to get something that looks like what id T HTML produced. In the first place, we have external organizations pointing into slash HTML that the HTML tree it goes after what had until we had B3 HTML only been the htmli stuff. Now they get a mix of htmli stuff.

A

Well, they always get the htmli stuff, but we also have the V3 HTML output somewhere else.

A

If we went to this docs thing and when doc says I want, if it's going to be serving the somebody's going to be reading this something by default, when you look at it, um Carson had the proposal that it always serves HTML it's available and it serves htmlis if the HTML isn't available.

A

um If the object is people reading these things, maybe that's okay, programs going off and reading things raw somewhere else. Can you know we can have distinctions in the Raw between these things? That would let them know what kind of document model they're going to be getting, or at least an alert that they're going to be getting a different document model across different parts of time.

A

um Is it okay for, like this reported docs.itf.org service that you just get different good depending on what level in the historic strategy you happen to be looking at.

E

uh I mean my feeling is: yes, you should get whatever the the best uh human readable film. It's that's available for that document. If you want a specific format, then well, we have links to specific raw formats and you can construct the appropriate URL. But by default you go to the best human readable, nice user-friendly page.

B

Yeah I definitely agree with that. um Personally. I have met people who actually prefer the htmlis versions over the modern HTML version, and part of that is probably something we can address by fixing the CSS at some point. But um generally we will have a small part of the constituency that that has that preference, and this might actually be a place where having a preference stored in a cookie or something or in the data tracker, might be useful.

A

Fundamental observation that I think just went by what served at these Pages at this purported service can change over time. Yes,.

E

Sorry, just to be clear, can change or cannot change.

A

From what I just heard.

B

Yeah, so people actually uh used to submit text files as Internet drafts and that at some point they see the light and and uh submit XML. So I finally get a look at an HTML version and then the next version is actually submitted by someone who hasn't heard about XML yet and who submits the the text version again.

B

um So the the same URI for the most uh recent version of of a draft may switch back and forth between htmlized and HTML. All the time.

A

So I think that the answer to the question that was originally written, how do we explain the various formats of documents as it? We just have links to them in places where people are reading, where the links explain what are needed and as if we build machine, readable endpoints, um we encode things into either mime types or.

A

Segments and URLs something in the tokens, something in the Json with the widget is explained. The differences are explained in these in those places.

C

uh One of the things that is kind of standard when you have a an environment where you are taking an original document and or media file or whatever and creating iterations of it right, like I'm, taking a WAV file and I'm, making an MP3 and I'm, making an OG and I'm making it. You know whatever, um but same thing applies here, is to in your metadata note how you are creating the derivative files um like which format of your software you use for it or whatever.

C

That tends to be something that you would store in metadata, rather than just uh you know, as a the machine readable way of knowing what is what happened to different files formats uh in an item, and that would be probably a lot easier to keep track of over time than just putting links onto things. In my opinion,.

G

Can you hear me.

A

G

I was gonna say on this idea of um providing different files that in some places, there's a hierarchy like if you decide that HTML is what you'd like the user to be reading, then we also provide these non-normative formats list of other formats where it and another approach is this flat organization, where you provide a bunch of formats so that the user choose, don't don't imply a hierarchy um or give them a hierarchy, I um kind of building off what Colin was saying, I'd like to see the best format, be the one that's presented to the user and then a second level where there's other formats.

A

All right in interest of at least touching on all of our points. Let's talk for a moment about um how we should prioritize SEO, optimization against the other things.

B

One one point before we do that um uh if we have multiple uis pointing to to multiple Renditions that represent different preferences, we have a problem because we have all those documents that have references in them.

B

um So we have to make sure that there is one reference we can put into all of our documents. At least the working page representations of that documents that you can click on and that that will show a fall of the document that that the person who clicks the link is not going to be repulsed by.

A

So anticipate that we should then have all of the references in published rfcs past the point that we make this pointing to this reading place the the that's going to automatically pull up the most readable copy.

B

Yes, but I I provided an escape Clause by saying that the archival version of the RFC might have a different Link in it than the version that you actually show on the working page on the per user page for the RFC.

A

So something to consider is what actually got published. The the published document would have two links in it in the reference.

B

No, it would only have one Link in it, which is the archival version and the rendering process for that. Rfc replaces that link by a pointer to the working page.

A

Pointer or redirect.

B

Pointer, so when you look at the doc's ITF org RFC 9000, the links in there will point to Doc's IDF org. You will not point to the RFC editor side. That's what I'm proposing.

A

So we are taking and published rsds that even going forward that the the references to rfcs would point to the RC editor site.

B

In the archival version, yes, but in the version that you actually look at and docs org, they would point to Dark Side here.

B

So that's why I want to split these universes uh really hard.

A

I think that's going to give everybody something that you want.

F

And Kirsten you had used an ex in your example, a published RFC. Are you talking about modifying the URLs and published rfcs or just.

B

So I'm I'm already talking about putting a top bar into that RFC. So we are already talking about modifying the published RFC and fixing the links to point to to a friendlier version. uh Just measures in with that very well.

A

Let me re, let me rephrase what I think you're saying Carson and you can correct me if I'm wrong, that we wouldn't be actually modifying the RCR table bits we would be presenting the RFC so by mutating it on its way to being presented.

A

C

That feels like a recipe for disaster to me, um just uh showing a human being, something that is not true, like a URL that isn't the real URL that the actual archival thing has in it doesn't seem like a good idea, I'm having trouble like figuring out in my head exactly why I think that I'm sorry I'm not presenting a more cogent argument for it or against it. But if feels like you're going to create yourself a problem.

D

It should at least be very visible that has been exchanged URL pretty much like we do the Errata right, the online Errata, it's visible as something has changed.

B

B

I, don't disagree with that, but I I do think that presenting the rfcs in something else, but the archival form is the right thing to do so. They can be easy to use.

E

Incomprehensible to everybody.

A

Yeah yeah and don't know how long we're going to stick with that decision.

A

B

Yeah I think the the cards will prefer to look at the design text files or something like that, so that, for me, that's part of the archival a form, and we want to optimize this, this for a good Lifetime and that's different from what we present at Doc IDF org, which is uh we present this for best usability and as long as we have the this conflict of objectives. I think the results need to be different.

A

So there are several questions that are left here: um I'd like to at least get a uh a light reaction from people on relative importance, and you know high level answers on on all of them right, um SEO, optimization versus um the uh making things easy for our community that are working with to do their work. I mean how far up the change should SEO optimization be in in our design, trade-off. Thinking.

H

I

Can I do I, just have a uh maybe a question in in a observation, um so I just want to make sure I understand here. The proposal is to put all document all documents into a single domain. At the moment this is the this is one.

A

Of the things that we're discussing, but whether we do that or not I think this question still stands.

I

Okay, uh the reason that I and then the observation I wanted to make because I think it relates to SEO- is that right now, one of the things that we observe is that people point to a ietf.org domain for things that are individual contributions and not actually ITF working documents. Yet, and so um this um uh you know, the docs.itf.org I think um has the potential to make that those lines even blurrier, so that people would be pointing to things on docs.itf.org and say: hey. The IDF has just published a new document.

I

Go take a look at docs.ipf.org.

A

Makeup that right now this is www.ietf.org for the archive I mean this docs thing isn't going to change that at all. So if you're, really wanting to change that I think I'm hearing you propose that we have an internet graphs.org.

A

I

Yeah I'm not proposing a solution to it. I just want to observe that that's an issue and that we could take steps and even make it worse or better. At this, this might be worth considering or not.

A

Is there any appetite for trying to handle signaling to the outside world that internet graphs are not anything by putting them somewhere other than intf.org.

B

Well, it should be visible in in the document that it's not it doesn't have status in the IDF in the status bar, not.

F

I

To be visible in the UI.

B

I

Yeah and and that that right, Carson, that's that's kind of what I think we're talking about different wrappers for different kinds of documents. Then maybe this is another kind of rapper that could be applied.

H

And uh Robert, would you see internet drafts moving to somewhere under iitf.org if they became adopted, or they actually had some official status? Then.

I

um I haven't thought about that at all um I, just I I just uh observe that this is an issue we have and that we might have an opportunity to improve it in some ways and it wouldn't necessarily meet me moving um domain names for it to be.

A

Improved yeah- and you know it's just the counter pressure to what Carson's original push was, for. You know, training people to look at one place right so.

B

That's somewhat random at what point in the development something becomes working production and then different working groups have different thresholds for that happening. So so.

A

Process, yeah that that I think is the biggie for me trying to to reflect the process too much in domain names is actually probably going to bite that hard.

H

Yeah domain names are notoriously bad for SEO, um so many people just ignore them entirely um in SEO, so I wouldn't trust those for anything. But the the SEO thing that I've always thought was important is the rally because canonical header um in or whatever way to comment how it works inside um all at any RFC or any that's not published on the IRS editor site. That then points to the canonical URL being on the RS editor site.

H

If we'd had that some years ago, tools.ihf.org would never have got to be the top one, um because um we're making a very um clear statement as to where they can be found and I think if we do it, and that also means that other people who publish their own copies of things will also begin to do it over a period of time as well, and that just drives people more to the IRSC, editor site and um I. My camera is not working. Sorry, so you just have to disembodied voice.

A

So I encourage you when you can Jay too um listen to the recording of the first part of the call just to see if there's anything in that conversation, that.

A

Would affect what you just said when your sentence contained the words RFC editor site, so.

A

All right we're essentially at the at the end of our hour, um I'm sure other people have scheduled meetings, I'm willing to leave this bridge up, and we can continue our conversations.

A

But if there's anybody that has to leave is there anything that you want to want to get in before you have to go.

A

Not seeing anybody jump to the mic, so, let's see um is there anybody here? That would be troubled by going for, for the at least some subset of us continuing to go for another 15-20 minutes. Okay! Well, let's just do this, then all.

E

Right, let's drop that in a minute or two but I'm happy for everyone else to continue.

A

Oh, thank you for the time that you've, given us.

A

um I'm gonna reorder a little bit of what's left because I think we might be able to get to some conclusion on it. Jay had a question at the end about supporting programmatic document retrieval.

A

um Do we want to focus our efforts on using the same kinds of URI structures and using HTTP itself as the interface or do we want to push these things more to a more modern, Json API that can run over HTTP or whatever Carson I think he started to answer this? One.

B

Well, for me, there is no difference between the two bullet points, so I'm not sure what the question is.

A

So I think that the real question comes back to some of what we were trying to tease that a moment ago. Is it? Do we expect programs to consume the things that we are also expecting programs to consume, and do we constrain what we do with the pages that we're putting in front of people to carefully consider the um that automaton may be consuming them?

A

So we we, we kind of, went through this once already a little bit earlier in the call. But this.

H

A

A more concrete mechanism way of of asking the question.

A

So let me flip it. Let me flip it around this way.

A

A

That the things that docs.itf.org in the proposal, or at least the places that we put the human readable content, um make the assumption that this is for humans and wetware can deal with any changes that happen along the way here, and the software and the need for the the kinds of consistency that software needs to see would be served by something else.

E

Hey having having an API and being consistent in the vpa is the right way for software to access it and people should use websites.

H

So the reason why I put this in there is because um I'm wondering if um we constrain ourselves, if we think we have to have a strict URL naming syntax that supports automated retrieval.

H

um uh So, for example, I can imagine us having a um a single page application that shows then RFC in different formats without the URL.

H

Changing, because that's the way the you know just the way that it works and um losing the ability to then construct a URL that say Returns the txt file or something like that, because we don't have that in there, so that that's what I'm I'm wondering I'm, not suggesting that we should do that, but that perhaps we are making our life a bit difficult by assuming that people programmatically or that that we need to maintain compatibility for programmatic a tree.

B

Well, I was going to say that that I expect something like the RFC 9000.json fire to feature more prominently in in these apis, so that actually should contain all the information that that is needed to do the retrievers that you want to make and we might want to to generate similar files for the internet drafts as well, and that may be about all the the API we we need here.

B

um Yeah single page application certainly makes sense. I would expect them to actually encode their the application state in the fragment identifier, so they would still still have different Uris for showing different things, but that's maybe a detail.

B

um So we we could consider the the landing page to be a single page application.

A

Well, so let me point at bib XML the build XML service here with having the you know: bib XML, IDs versus bibex and l. I Triple E versus whatever in the past right and the the having its own unique solution for current versus, not um I. Think that it's a worked example of where we have rather severely constrained what we could do, um making the assumption that this is for machines and not for people, and it really is more for machines right.

A

This is this is something that software goes and grabs Snippets from and the when we proposed with the bib XML service that people just change their software to to make some Json queries and get some API, we got back Ralph. You know it's always worked this other way. Why can't? We just continue to do it? This other way, yeah.

B

The problem is that we have those uis encoded in the actual Source codes of the documents that people have been working on for a decade. So that's a really hard change to make. But of course we don't want to create new instances of this problem.

E

I I do think we should be clear when we publish new things, whether we expect these to be consistent for machines to pass or whether we're saying that this is expected to be human, readable and the format may have may change over time machine. You can go over here. Instead,.

A

And does this or do we expect that this link will exist forever and is it okay if the content of this link changes? So we touched on this a couple of times earlier in the call so.

A

I don't know if we called out the link exists forever earlier. As you know, if someone get docs.itf.org exists once is it been there for all of time? I think we've we've spoken to that directly in this call. Yet.

A

And I'm thinking that people's brains are now fried, which is why I did not make this afraid.

E

That I would say be clear when, when we put new URLs of what we think the status is and whether we, whether we they're temporary things which may change or whether we are committing to them and yes, people will Grouch whatever we do, but we can at least point to the announcement that says. Well, we told you it was going to change. You lose.

C

For my own edification, as far as I'm aware, the only URLs we have that are supposed to be archival and never change are the URLs for rfcs, correct.

B

C

Is that specification.

A

B

The problem is that we have all these Dusty decks out there. People work on on documents for a long long time, and all these Dusty legs have Uris encoded in them or parts of your eyes, encoded in them, and, of course, we we are not prohibited from damaging these documents, but I think we want to keep the damage under control.

C

That's fair, it sounds like you have three classes of documents. You have archival Uris, you have. Please try not to change these Uris and you have totally up for grabs Uris. Yes,.

A

So um I think I'm going to suggest that we take the findability question search navigation to another call, because I I think that could fill another half hour. At least um the one of the services that people have asked for so far is the ability to keep their own copy of everything and keep their copy of everything in sync so we're we had been providing this with FTP we're currently providing with HTTP and with our sync over http.

A

um Do we need to change it? Is there? Is there um a? Is this something we continue to continue to do? I think the answer is: yes, I think that there's enough of the community that would get really upset if they couldn't keep their mirror and have their mirror easy to build, um but should we like just check everything into GitHub and let people get these things back yet, in addition to not necessarily instead of right.

A

um Or some other mechanism for Distributing these things, you know shove them out into the AWS and put a very skinny page on top of it inside AWS for retrieval.

A

Anybody have any thoughts at all or is what we're doing now.

A

I'm kind of starting to get keen on the check everything in to get and put a copy of it up at GitHub. We could put another copy that up somewhere else right and- and this might be my solution for how I tear the data tracker apart from the the web server, is that the data tracker instances work, but whenever it has a new thing that it needs to store it just checks it in to get and other instances of the data tracker can, can you know refresh their their get massive git repository?

A

So I have you know all kinds of scaling and then, when we want to build an rsync service that just it just checks out and refreshes repository on a schedule and just puts our sync over the result. You know an RC server on top of the result.

B

So I think the the the thing we can get from gutier is to manage the evolution of all these other small things like Charters and and so on.

B

um That's currently very pedestrian what's going on there and we want to move these to a git as soon as possible, whether we use git to do the revision, control of the actual documents, internal drafts and rfcs. Now, that's maybe a different question.

A

Yeah, you know at least my initial thinking of this is that you know a a file gets put in there and then it's never changed right. It's just these are the artifacts like we create artifacts right now and they're static. So it's just a monotonically growing, no element changes, abuse of something like that. So.

A

If you have any other thoughts about what we are doing in this space,.

A

C

Don't have any I, don't have any opinions about how this is technically accomplished, but making it as easy as possible for people to make backups of any documents that you care about is one of the best ways of making sure your documents survive for the long term. So I would definitely recommend keeping the service and and having it, be as easy as possible for people to use it.

H

Yeah I, don't particularly get the get thing, because the revision control isn't as important as um searchability and access and things. um But.

A

Like I mean on top of something else, think of getting this particular case as a database yeah.

H

But take something like elasticsearch: that's you know it's it's a thing that you shove stuff into and it's built around the search ability and that kind of stuff around it. You know it's doesn't matter what's underneath it and that perhaps is a and if you um as we all know, if you put stuff in that and inadvertently expose it on the internet, you have a thousand hackers to copy it for you.

H

So that's our backup problem solved, but um no I mean that might be a just, a different approach to look at a a thing that is designed for sharing, rather than a thing that is designed for um uh correctness.

A

Yeah, well, the correctness is going to be important for the solving the problem that I've got it's splitting the data tracker from the website and for allowing multiple instances of the data tracker on different machines to run at the same time right these these these files. These things are currently files in a file system. They got to be somewhere else and elasticsearch isn't where they're going to be elasticsearch may run overall, but.

A

And you can tell me if I'm wrong, if you know it's good, if we can have a big elastic search engine in the cloud and I can go pick versions of draft out of it that put things in and pull things out of it. That way, then, maybe that something I should be looking at, but I the research I've gone so far. That's not not the the right tool.

A

All right, one bullet on here that we haven't touched on yet um signing things so we're signing rfcs we're currently signing internet drafts. We've got a rickety mechanism that we're signing internet drafts with that we need to revise. So let's ask the question: do we continue signing them.

A

H

Is up here, you would.

A

Say? Yes, yes,.

A

So I'm hearing you yes from Carson is there anybody? That's arguing that it's not worth the effort to to to continue this as a service. Well,.

B

The the important thing is not so much the signing, but the time stamping. um So we have to run the timestamping service on these documents. If we want to be usable as uh evidence of prior art in in court cases, and that that's of course, extremely important for the idea.

B

I mean there are other Technologies to to get that, but signing is definitely the cheapest way of doing this. Yep.

A

All right well we're 15 minutes over.

A

Anybody have any anything else that they want to make sure that we talk about today.

A

I think we covered a lot of ground and we we had some some new ideas come out because of the conversation, so I'm very happy that everybody took a chunk out of their day to come together and talk about this so I'll put together. Some notes: I'll go through the recording, make sure that things are covered. We can add to them and if you go off and have thoughts after the after the Call's over that you know you wish you'd brought up. While we were talking, please um send them to the tools list.

A

A

Awesome, thank you and I think we'll close.

B

Thank you all thank.

H