Friday, July 29, 2022< ^ >
alexamirante has set the subject to: HTTPAPI at IETF 112 -
Room Configuration
Room Occupants

[13:55:08] <zulipbot> (Erik Wilde) hello everybody!
[13:55:21] <zulipbot> (Darrel Miller) Hey Erik! Welcome.
[13:55:34] <zulipbot> (Erik Wilde) this doesn't look like philly, darrel!
[13:55:47] <zulipbot> (Darrel Miller) No Philly for me unfortunately
[13:56:20] <zulipbot> (Erik Wilde) same here... london is planned, though!
[13:56:33] <zulipbot> (Darrel Miller) Last trip I took I got covid and then gave it to my wife and daughter, so I have been grounded for a while :-)
[13:56:46] <zulipbot> (Erik Wilde) ooops. they have a point...
[13:56:46] <zulipbot> (Darrel Miller) I'm really, really hoping to make it to London.
[14:00:51] <zulipbot> (Rich Salz) but yokohama (announced as next one after london) is going to be a hard sell for many
[14:01:06] <zulipbot> (Martin Thomson) that's on the way home for me
[14:01:06] <zulipbot> (Rich Salz) we'll start at a couple minutes after the hour
[14:01:35] <zulipbot> (Martin Thomson) the real trick will be getting into the country
[14:01:48] <zulipbot> (Darrel Miller) Not a hard sell for me, just a hard sell to our accounting department.
[14:02:01] <zulipbot> (Erik Wilde) yokohama sounds tempting. never been there!
[14:02:59] <zulipbot> (Erik Wilde) darrel's audio is good, rich is barely audible for me.
[14:03:13] <zulipbot> (Mark Nottingham) same
[14:03:14] <zulipbot> (Mark Nottingham) now we can hear you
[14:03:26] <zulipbot> (Erik Wilde) slightly better but not great.
[14:03:27] <zulipbot> (Mark Nottingham) if that's better, I'm not sure
[14:04:08] <zulipbot> (Roberto Polli) Hi folks!
[14:04:22] <zulipbot> (Erik Wilde) hey roberto, welcome!
[14:04:35] <zulipbot> (Martin Thomson) @**Roberto Polli** hi!
[14:04:36] <zulipbot> (Darrel Miller) Hey Roberto!
[14:04:48] <zulipbot> (Mark Nottingham) Hello!
[14:06:58] <zulipbot> (Rich Salz) hey mark
[14:08:00] <zulipbot> (Martin Thomson) I see that I'm on the agenda here, but I don't remember asking for time.
[14:08:40] <zulipbot> (Rich Salz) @Martin we figured you would want to say something. if not, that's fine
[14:08:41] <zulipbot> (Darrel Miller) You're only on there because there was an open issue at the end of IETF 113 as to where DateHeader might land
[14:08:55] <zulipbot> (Martin Thomson) I can give a brief update, sure.
[14:09:08] <zulipbot> (Martin Thomson) Time permitting of course
[14:09:21] <zulipbot> (Rich Salz) "unaccustomed as i am to public speaking ... "
[14:09:49] <zulipbot> (Rich Salz) funny, dret's "london is planned" message is pinned to the bottom of my chat.
[14:11:06] <zulipbot> (Mark Nottingham) It needs to be a WG decision, not just an editors' decision.
[14:12:36] <zulipbot> (Darrel Miller) "implementers found it confusing" doesn't sound like an honest objection.
[14:13:02] <zulipbot> (Martin Thomson) @**Mark Nottingham** are you suggesting that we need to have a discussion here?
[14:13:18] <zulipbot> (Mark Nottingham) More to the point, these are second hand impressions, not arguments being made *in* the WG
[14:13:33] <zulipbot> (Martin Thomson) yeah, I don't like that at all
[14:14:25] <zulipbot> (Rich Salz) @Mark -- after this slide or after the whole preso?
[14:14:38] <zulipbot> (Mark Nottingham) now
[14:14:38] <zulipbot> (Rich Salz) k
[14:15:23] <zulipbot> (Martin Thomson) FLOATING HEAD IS HERE!
[14:16:05] <zulipbot> (Julian Reschke) +1
[14:19:22] <zulipbot> (Julian Reschke) it would be nice to see what type of support in httpd is required, and whether there is a ticket related to that yet?
[14:19:35] <zulipbot> (Mark Nottingham) Indeed
[14:21:36] <zulipbot> (Mark Nottingham) Could the chairs ask for a hum on this?
[14:22:08] <zulipbot> (Rich Salz) ok, we will do a hum.
[14:22:51] <zulipbot> (Roberto Polli) sorry my net went down
[14:22:52] <zulipbot> (Mark Nottingham) More to the point, why is it necessary to parse these response header fields in a server?
[14:23:07] <zulipbot> (Darrel Miller) Yeah, I lost audio too.
[14:23:07] <zulipbot> (Martin Thomson) `RateLimit: l=10, r=5, t=60` would be better.
[14:24:45] <zulipbot> (Erik Wilde) ;-)
[14:24:45] <zulipbot> (Martin Thomson) Or maybe even `RateLimit: 5; l=10; r=60`
[14:31:43] <zulipbot> (Mark Nottingham) We're back to the religious paving of cowpaths again
[14:32:42] <zulipbot> (Rich Salz) well, one of the points of this WG is to bring involvement of API practitioners, so cowpath discussions seem okay.
[14:32:55] <zulipbot> (Darrel Miller) The existence of standard SF parsing now changes the landscape regarding how clients can parse these fields.
[14:33:08] <zulipbot> (Mark Nottingham) The problem is that the implementers aren't engaging _here_
[14:33:08] <zulipbot> (Julian Reschke) so why doesn't the implementer community show up here?
[14:33:51] <zulipbot> (Rich Salz) Reach out to them?  We started with 50% of the WG never been to an IETF.  maybe people just left.
[14:34:08] <zulipbot> (Mark Nottingham) cowpaths are great for patterns, but not for details like syntax.
[14:34:21] <zulipbot> (Martin Thomson) maybe they get as tired as I do of these arguments
[14:34:21] <zulipbot> (Mark Nottingham) indeed
[14:34:34] <zulipbot> (Lucas Pardue) so a dumb question - what is an implementer in this scenario? is the consumer of the field the same as the organization producing it
[14:35:01] <zulipbot> (Mark Nottingham) Lucas - not usually
[14:35:01] <zulipbot> (Martin Thomson) @**Darrel Miller** I think that you can use just remaining, in some way
[14:35:14] <zulipbot> (Mark Nottingham) Producer and consumer is probably better
[14:35:14] <zulipbot> (Martin Thomson) That's what I've done in the past
[14:35:27] <zulipbot> (Mark Nottingham) When Roberto is talking about implementer, he means producer mostly
[14:35:27] <zulipbot> (Lucas Pardue) so why do we care what the producers find easy?
[14:35:54] <zulipbot> (Martin Thomson) Isn't this sprintf() or f-strings or whatever?
[14:36:07] <zulipbot> (Darrel Miller) Lucas: +1
[14:36:23] <zulipbot> (Mark Nottingham) @martin - certainly could be
[14:37:12] <zulipbot> (Darrel Miller) It would be very interesting to know what the feedback would be from consumers.  I think the challenge is finding the consumers.
[14:37:25] <zulipbot> (Martin Thomson) @**Mark Nottingham** I've rarely seen anything other than simple string building for producing fields.
[14:40:40] <zulipbot> (Rich Salz) okay, each side gather your forces for PR and/or mailing list comments.  And WG (particularly long-time IETFers) let's remember that we're trying to engage people that haven't traditionally participated here, so complaints that they're not here don't sit very well with at least one of your chairs.
[14:42:18] <zulipbot> (Alexey Melnikov) +yaml suffix is not registered with IANA yet
[14:42:44] <zulipbot> (Alexey Melnikov) Sorry, I havenโ€™t read the document yet. But will do.
[14:44:05] <zulipbot> (Rich Salz) "don't sit very well" is perhaps too strong, sorry.
[14:44:18] <zulipbot> (Alexey Melnikov) The default fragment logic should be the same, but specific XXX+yaml can register different fragment identifier types
[14:45:06] <zulipbot> (Alexey Melnikov) So yes, specific types can define fragment extensions
[14:49:28] <zulipbot> (Julian Reschke) Rich: I think it's worth differentiating between "have not traditionally participated" from "are not participating". Just my 2c
[14:50:17] <zulipbot> (Rich Salz) @julian, agree thanks.
[14:54:37] <zulipbot> (Mark Nottingham) Usually, the application/foo fragid format is the _default_ for application/whatever+foo, but it can opt out / nominate another.
[14:54:50] <zulipbot> (Julian Reschke) is one a superset of the other? in which case I see optential interop problems
[14:55:03] <zulipbot> (Julian Reschke) *potential*
[14:55:35] <zulipbot> (Darrel Miller) No they are not supersets.  JSON Pointer fragIds start with / the native SSS one does not.
[14:55:50] <zulipbot> (Roberto Polli) SSS is +yaml
[14:56:03] <zulipbot> (Roberto Polli) structured syntax suffix
[14:56:42] <zulipbot> (Darrel Miller) @mark  I think requiring opt-out is reasonable.
[14:56:43] <zulipbot> (Martin Thomson) +1 to what mnot said there, one of the things you want is to be able to treat the +x types in a similar way to the application/x type
[14:56:55] <zulipbot> (Rich Salz) thanks for the input alexey; safe travels
[14:57:54] <zulipbot> (Martin Thomson) Defining a conversion would be a massive scope increase.  Don't do it.
[14:58:33] <zulipbot> (Lucas Pardue) +1 MT. Sounds like a huge ball and chain for the future
[14:59:24] <zulipbot> (Roberto Polli) I think ok for interoperability consideration is enough
[15:00:08] <zulipbot> (Roberto Polli) Ok, I agree it's out of scope defining algos
[15:01:31] <zulipbot> (Rich Salz) @Martin, might be worth putting a link to the zulip chat because there is useful info there
[15:02:09] <zulipbot> (Erik Wilde) as it is it's not ready to merge.
[15:02:22] <zulipbot> (Martin Thomson) Ugh, JSON-LD
[15:02:22] <zulipbot> (Erik Wilde) sorry: referring to that final issue here.
[15:05:43] <zulipbot> (Martin Thomson) I was going to get up to +1 mnot
[15:05:43] <zulipbot> (Martin Thomson) Someone else can write a document.
[15:06:50] <zulipbot> (Mark Nottingham) erik firast
[15:06:50] <zulipbot> (Mark Nottingham) first
[15:07:13] <zulipbot> (Rich Salz) @martin, you mean "document author is-someone-else" IIRC RDF
[15:12:39] <zulipbot> (Darrel Miller) +1 to what @mnot says about lifecycle
[15:13:15] <zulipbot> (Martin Thomson) `lifecycle` sounds good to me too
[15:13:41] <zulipbot> (Erik Wilde) a "lifecycle" draft would probably involve setting up a registry, having an extension model and so forth. i am not so sure this is just a small edit.
[15:14:26] <zulipbot> (Erik Wilde) that "datetype" type would be great! for sure for "lifecycle", or for "deprecation" if we're sticking with that one but decide on breaking compatibility with "sunset".
[15:15:05] <zulipbot> (Julian Reschke) we could just start with sunset + deprecation variants and wait with extensibility until later
[15:16:15] <zulipbot> (Mark Nottingham) Concretely, something like `Date: @1659107755`
[15:16:41] <zulipbot> (Julian Reschke) do we have data on existing consumers of Sunset and their parsers?
[15:16:55] <zulipbot> (Martin Thomson) @**Julian Reschke** I assume that you mean sunset + deprecation + extensibility and then deal with extra semantics later.
[15:17:29] <zulipbot> (Julian Reschke) si
[15:18:38] <zulipbot> (Julian Reschke) +1 to what Mark just said
[15:19:06] <zulipbot> (Martin Thomson) I don't know that Mark's idea is the best. a registry seems perfectly easy too
[15:20:31] <zulipbot> (Julian Reschke) *unix* epoch
[15:20:32] <zulipbot> (Martin Thomson) @**Darrel Miller** epochs are not that hard
[15:20:44] <zulipbot> (Martin Thomson) unix epoch or GPS epoch or whatever date you prefer
[15:20:45] <zulipbot> (Julian Reschke) the other q is sub-second res
[15:20:57] <zulipbot> (Martin Thomson) a date that is after the last ever leap second would be awesome
[15:21:10] <zulipbot> (Mark Nottingham) People sometimes ask for that, but I still think it's a footgun
[15:21:23] <zulipbot> (Martin Thomson) I know.  I don't think that it matters so much
[15:22:03] <zulipbot> (Mark Nottingham) these questions are in the wrong order
[15:22:29] <zulipbot> (Martin Thomson) I'm not answering this poll.
[15:22:29] <zulipbot> (Mark Nottingham) neither am I
[15:22:42] <zulipbot> (Mark Nottingham) it's a malformed question
[15:24:58] <zulipbot> (Mark Nottingham) hums only give a sense of the room, not consensus
[15:25:58] <zulipbot> (Darrel Miller) We use the sunset and deprecation headers for the Microsoft Graph API.
[15:26:14] <zulipbot> (Roberto Polli) I think this point from Erik is relevant.
[15:27:28] <zulipbot> (Julian Reschke) so the field value currently is just an HTTP-date? In which case I retract my question :-)
[15:28:01] <zulipbot> (Mark Nottingham) Happy to help you, Erik :)
[15:28:30] <zulipbot> (Julian Reschke) but Sunset uses HTTP-date, right?
[15:29:40] <zulipbot> (Julian Reschke)
[15:30:13] <zulipbot> (Julian Reschke)
[15:30:28] <zulipbot> (Julian Reschke) both use HTTP-date. not ISO
[15:31:58] <zulipbot> (Erik Wilde) yes, we keep the "Sunset" syntax.
[15:32:26] <zulipbot> (Erik Wilde) for now. unless mark's issue takes over.
[15:32:39] <zulipbot> (Martin Thomson) HTTP-date is abominable, but Julian is right
[15:33:33] <zulipbot> (Erik Wilde) i think we should also mention "linkset" and i hope IETF has some cheesy fireworks for the first RFC that this working group published! hooray!
[15:35:25] <zulipbot> (Roberto Polli) ๐Ÿ‘
[15:35:38] <zulipbot> (Roberto Polli) ๐ŸŽ‰
[15:35:38] <zulipbot> (Julian Reschke) cheers
[15:35:51] <zulipbot> (Erik Wilde) thanks to everybody for contributing!
[15:36:17] <zulipbot> (Erik Wilde) thanks chairs and everybody!
[15:36:30] <zulipbot> (Mark Nottingham) Bed.
[15:36:43] <zulipbot> (Roberto Polli) Bye folks!
[15:37:12] <zulipbot> (Benson Muite) Bye
[15:37:12] <zulipbot> (Darrel Miller) Thank you everyone.