[{"author": "Harald Alvestrand", "text": "checking that chat works
", "time": "2022-03-23T12:05:54Z"}, {"author": "Francesca Palombini", "text": "ack
", "time": "2022-03-23T12:06:02Z"}, {"author": "Murray Kucherawy", "text": "I think I agree with Standards Track.
", "time": "2022-03-23T12:13:02Z"}, {"author": "Murray Kucherawy", "text": "and this seems like a good list as well
", "time": "2022-03-23T12:13:28Z"}, {"author": "Phillip Hallam-Baker", "text": "I believe we should apply the principle of permissionless innovation to registration. That is, nobody should ever have to ask permission to deploy an Internet application.
So the question to as is whether registration of a toplevel type is necessary to deploy an application. The answer is no.
Toplevel types are an issue of organization of the registry and not access. So standards track is appropriate.
", "time": "2022-03-23T12:16:27Z"}, {"author": "Pete Resnick", "text": "Standards Track gets Expert Review too doesn't it?
", "time": "2022-03-23T12:19:35Z"}, {"author": "Darrel Miller", "text": "Having a document to register new Top-Level types would provide an opportunity for further description of the top level type. For example, \"example/*\" says \"The example media type is used for examples\". This feels like an opportunity for further elaboration.
", "time": "2022-03-23T12:20:59Z"}, {"author": "Francesca Palombini", "text": "don't think so Pete
", "time": "2022-03-23T12:22:02Z"}, {"author": "Francesca Palombini", "text": "there is not even experts assigned for Standard Action policy (ex: https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-1)
", "time": "2022-03-23T12:22:35Z"}, {"author": "Francesca Palombini", "text": "specification required requires DE review
", "time": "2022-03-23T12:23:37Z"}, {"author": "Darrel Miller", "text": "A better example is \"model/*\". It has no description of its purpose. How would I discover what it means to register within that top-level?
", "time": "2022-03-23T12:25:16Z"}, {"author": "Phillip Hallam-Baker", "text": "@jfk just made me think of something that might be dispositive here: The expert assignments might well be different for different toplevel types. That is an administration function IESG/AD needs to have control over.
", "time": "2022-03-23T12:26:07Z"}, {"author": "Pete Resnick", "text": "Ah, \"specification required\" not \"standards track\". Right. Thanks FP.
", "time": "2022-03-23T12:26:16Z"}, {"author": "Murray Kucherawy", "text": "@Pete: We could certainly say this is Standards Track, and the IESG is strongly encouraged to ensure media type reviewer input.
", "time": "2022-03-23T12:26:17Z"}, {"author": "Pete Resnick", "text": "@Murray: :thumbsup:
", "time": "2022-03-23T12:28:08Z"}, {"author": "Harald Alvestrand", "text": "note - we're running approx 10 min behind schedule. keep brief.
", "time": "2022-03-23T12:29:09Z"}, {"author": "Murray Kucherawy", "text": "The draft registering \"haptics\" as a top-level type can be done in parallel with the one describing top-level types in general. We could take them both together, the former being a first example of the latter.
", "time": "2022-03-23T12:30:34Z"}, {"author": "Murray Kucherawy", "text": "(just a suggestion)
", "time": "2022-03-23T12:30:49Z"}, {"author": "Harald Alvestrand", "text": "yes, that's what we are doing.
", "time": "2022-03-23T12:31:41Z"}, {"author": "Murray Kucherawy", "text": "(y)
", "time": "2022-03-23T12:31:50Z"}, {"author": "Harald Alvestrand", "text": "haptics can't go *before* toplevel, but I hope we can send them to IESG together.
", "time": "2022-03-23T12:31:57Z"}, {"author": "John C Klensin", "text": "@Murray: That is sort of what I'm feeling for, but I've been thinking about it as closer to \"Specification Required but with IETF Last Call as input to the Expert Reviews\" For this purpose, they should consider themselves a team and reach a conclusion jointly and only after input from Last Call\".
", "time": "2022-03-23T12:32:12Z"}, {"author": "Murray Kucherawy", "text": ":thumbsup:
", "time": "2022-03-23T12:32:13Z"}, {"author": "John C Klensin", "text": "Actually, the controversy around \"haptics\" that drove this WG is a perfect example of the problem ... and the need for what was described as \"wanting cover\".
", "time": "2022-03-23T12:32:59Z"}, {"author": "Murray Kucherawy", "text": "@John: Can we issue a last call on something that isn't a document? Never tried that.
", "time": "2022-03-23T12:32:59Z"}, {"author": "Murray Kucherawy", "text": "I guess it would be a generic IESG Action?
", "time": "2022-03-23T12:33:09Z"}, {"author": "Francesca Palombini", "text": "on a less important note, I think that whatever the WG decides on as for what the correct process is for registration, that should be described not only in the document but also summarized in an IANA Note under \"Registration Procedures\" because otherwise it could be missed.
", "time": "2022-03-23T12:35:29Z"}, {"author": "Murray Kucherawy", "text": "\"Specification Required but with IETF Last Call\" to me is almost indistinguishable from Standards Track. If the specification is external but still needs a Last Call, an AD may as well sponsor it as an I-D.
", "time": "2022-03-23T12:35:57Z"}, {"author": "John C Klensin", "text": "\"Specification required\" does require a document, so not too precedent-setting. In some ways, the only difference from Standards Track is that the final decision would be made by the type reviewer team. And, if we wanted to make as little apparent change as possible, almost exactly the same thing would occur if we stuck with Standards Track but required not only Expert Team input to the IESG but that the IESG pay attention to it.
", "time": "2022-03-23T12:37:14Z"}, {"author": "Murray Kucherawy", "text": "I think the latter is easier to describe, yes.
", "time": "2022-03-23T12:37:37Z"}, {"author": "Darrel Miller", "text": "Doesn't the Content-Encoding header handle gzip?
", "time": "2022-03-23T12:46:25Z"}, {"author": "John C Klensin", "text": "@Darrel: Yep. And that ... well, I guess I need to get in the queue when the speaker stops.
", "time": "2022-03-23T12:47:54Z"}, {"author": "Murray Kucherawy", "text": "I agree that trying to get Ned to review and comment would be quite valuable.
", "time": "2022-03-23T12:49:45Z"}, {"author": "Murray Kucherawy", "text": "If you're worried about the security aspects in particular, the chair can request an early SECDIR review.
", "time": "2022-03-23T12:50:22Z"}, {"author": "Manu Sporny", "text": "Ok, I can add a specific example for gzip bomb
", "time": "2022-03-23T12:53:30Z"}, {"author": "Murray Kucherawy", "text": "@Manu: Happy to help review whatever. I have to review whatever you do anyway. :)
", "time": "2022-03-23T12:55:24Z"}, {"author": "Manu Sporny", "text": "Yes, the \"combination of suffixes\" has already come up... +json vs. +ld+json (which one can you pick) -- the spec says something about this... but perhaps we should be more clear there.
", "time": "2022-03-23T12:56:07Z"}, {"author": "Manu Sporny", "text": "re: reviews-- thanks Murray, will definitely take you up on the offer! :)
", "time": "2022-03-23T12:56:34Z"}, {"author": "Darrel Miller", "text": "@manu is the primary goal to allow user agents to process the response as the more primitive media type, or is to allow distinguishing between two different base formats for the same media type semantics?
", "time": "2022-03-23T12:56:36Z"}, {"author": "Manu Sporny", "text": "@Darrel - at least that first one... the second one, I don't quite understand?
", "time": "2022-03-23T12:57:19Z"}, {"author": "John C Klensin", "text": "@Manu: Yes, if the spec can dig us even partly out of the mess, it would be A Good Thing.
", "time": "2022-03-23T12:57:38Z"}, {"author": "Darrel Miller", "text": "e.g. application/did+ld+json and application/did+ld+yaml
", "time": "2022-03-23T12:57:49Z"}, {"author": "Manu Sporny", "text": "Yes, excellent question... text/plain+gzip --> is that validated after this draft (I think, probably not? but great question)
", "time": "2022-03-23T12:58:00Z"}, {"author": "John C Klensin", "text": "@Harald, how about text/plain+UTF16, which is another part of this path, unless carefully excluded.
", "time": "2022-03-23T12:58:12Z"}, {"author": "Manu Sporny", "text": "@John -- good to know, would appreciate guidance if you feel the current spec is digging a bigger hole (which we don't want)
", "time": "2022-03-23T12:58:35Z"}, {"author": "Murray Kucherawy", "text": "I agree, Martin's document updates 6838.
", "time": "2022-03-23T12:59:13Z"}, {"author": "Manu Sporny", "text": "@Darrel -- re: application/did+ld+json and application/did+ld+yaml -- yes, we do want to be able to distinguish between two different base formats for the same media type semantics (if I truly understand your question at depth)
", "time": "2022-03-23T13:00:17Z"}, {"author": "Darrel Miller", "text": "I have been largely supportive of suffixes in the past, but the use of +gzip is very concerning. How that interops with Content-Encoding: gzip seems like a source of future pain.
", "time": "2022-03-23T13:00:29Z"}, {"author": "Murray Kucherawy", "text": "We could also amend the form to just say \"If you don't know what this is, leave it blank.\"
", "time": "2022-03-23T13:00:54Z"}, {"author": "Manu Sporny", "text": "@Darrel -- yes, agree, there is a non-trivial possibility of creating a problem here.
", "time": "2022-03-23T13:01:00Z"}, {"author": "John C Klensin", "text": "As that other co-author of 6838 (and nothing that Tony isn't here either), \"gone shortly after OS10\" is consistent with what I know, but Ned should definitely be involved in any further discussons of this.
", "time": "2022-03-23T13:01:17Z"}]