Agenda:
Notes:
administrative: not sure meetecho captures attendance, might dispense with that practice now we’re using meetecho.
CA: The map-like agenda item is still going on, but probably no updates for today.
CA: network-address has 2 additions since the last meeting, i.e., CDDL and addresses with prefix (useful for describing a subnet but not only). Michael, or Carsten?
CB: it does increase the complexity of the draft but I use it a lot in configuration files, I expect it to be useful.
MCR: (sharing new CDDL parts in draft): a sentence (“can be reliabliy distinguished”) accompanying an example may be simplified. (CB will update PR)
MCR: added 3 ports rather than 2
MCR: would like the WG to add Carsten as co-author
CA: reasonable to do
MCR: on file-magic, had a pull request on advice and merged it; no other feedback but would like some.
CA: can review the PR during the week
MCR: merged already and non controversial
CA: when would one go for the content-format annotation rather than for registering a tag?
MCR: Two questions. “Would you convert mime types received to a file”? Entirely appropriate, but specific to Collab or HTTP but inappropriate to SNMP, so belongs in document about that protocol, can make suggestions for some. But what I understood is that for everything we have a content format for, we already have a tag for that, so don’t need to register one (and if there’s a mime type, probably has a content number).
CB: Generally having a common/preferred way to get a tag is better. Advice should go into using tags when content-format tags when available, but [ …? ]
MCR: If there’s a CoAP content-format, no need for a new number to allocate.
MCR: Whether to translate is a wholely different discussion. When in a translation situation, [ …? ]
CB: We can add that if there’s a Media-Type but no content-format, then maybe better to register a content-format than a new tag.
MCR: We can say something on it then.
CB: Still have that experiment where all media types get a cf (easy because there are few), at some point will need to do this. Doesn’t help w/ weird params, but with most out there. But that’s CoRE work.
CB: My main question: carry content-format as separate document or merge? B/c don’t want to kill IESG by 1k little documents.
MCR: We might not even need a document. IESG can ask IANA to make it so.
CB: But we probably do. Somebody could sit there and do the regs, but would be better if automatic.
MCR: So document to update the MIME reg template?
CB: Now it says we’re doing a single registration in the Tag registry, which points to the content-format registry. Then there’s an automatism that by registering a cf you get a CBOR tag ~for free. The ct-tags doc is short.
MCR: Muddies the water for this doc, as a BCP now gets a revision to IANA process (so maybe different stream)? BL?
BL: That puzzles me, there shouldn’t be IANA stuffs in BCPs.
MCR: It’ll need to get a different type of reviews. This is just “this is a good way to do something”, doesn’t establish a standard. Other is “These are the new rules”.
CB: No new rules, just new side effect.
BL: If this formally updates the document that created the registry, that can be a sufficient pointer. Not concerned about level of review. If people might miss this, can highlight it in LC. Intro and abstract would say that. Up to WG.
MCR: I thought this was about mime types getting cf for free?
CA: No, only talking here about tag-for-cf automatism by registering 64ki tags.
CB: Registering a content-format may be an easy way? It’s not really recommended.
MCR: Maybe this should go in the CoRE document.
CB: No, it’s all about CBOR.
MCR: This document is saying “when you ask for a MIME type you get a content-format” (bormann-core-media-content-…)
CB: No.
MCR: It should all go together in a single process.
CB: What?
MCR: The connection between Media-Type, content-format and CBOR Tags, to have the registration process clear.
CB: But none of the tag-stuff is depending on the other parts.
MCR: Yes, agreed – but it’d be a single coherent though to go from mime to tag. Don’t want to spend too much time here.
CA: CB, could you suggest text to add to the PR shown before about when to use what?
CB: Yes, might do this before the deadline.
MCR: No objections to moving this in, but moves it further from being a simple doc.
BL: Can we see what it looks with merged, and decide based on that?
CB: Will do PR to add IANA and explanatory text to file-magic. Then can discuss PR. Will do separate PR on what needs to be added to advice.
BL: Makes sense to me. To you too, MCR?
MCR: Makes sense.
BL: We may revert if it won’t look right.
CA: on cbor-packed, this is related to the CoRAL design meeting we had last week.
CA: (presenting as user, not as chair) CoRAL can represent relations in a dictionary-like way. CoRAL can use cbor-packed and its semantics. The limitation is that we will need to profile this to some extent (e.g., which type of compression in which cases).
CA: We’re experimenting on where you get the dictionary from, which can be useful thinking for cbor-packed in general. Stay tuned on findings.
CA: It can be troublesome that cbor-packed can be seen in two different ways by the application, looking into a tag to expand or not. It becomes relevant if there are multiple sources of dictionaries. The parser needs to take precautions. No concrete results yet, but still a related topic.
CB: Difference between compression and cbor-packed is that you don’t do separate decompression w.r.t. using your data. I don’t see the alternatives above. In-between, version where DOM-like structure with references is implemented. DOM access functions look inside and decide whether it’s real data or just something inside. Then application can use variant of DOM access function that exposes whether it’s a reference. Allows to keep semantic significance
CA: So it would be a lstat().
CB: Yes.
CA: Sounds good to me.
CB: Good way to explain what happens in the cbor-packed decoder.
CA: Use same understanding. Symlink loops are not dangerous and can be used – only cp -L is.
CB: We already have the problem with cyclic references. MCR made a proposal, but constraining this risks to be excessive.
CA: This can evolve into implementation guidance for cbor-packed.
CB: We man end up with much less than 40 steps, an implementation has to keep the count.
CA: This is something for cbor-packed profiles.
CB: Tail recursion can be done for some.
CA: But not in CoRAL
CB: Depending on impl … but that’s for offline.
CB: Action item to discuss those limits in cbor-packed, and then use it more easily on CoRAL.
Attendance: