Editor slides:
https://datatracker.ietf.org/meeting/interim-2025-moq-26/materials/slides-interim-2025-moq-26-sessa-moqt-prs-for-910-01
(Slide 2,3)
Priority Not Present complexity worth saving a byte per group?
Use a bit for Object ID=0?
Summary: 1 b and "no" on 2
No objections voiced
(Note: this PR is about consolidation, not every error-code issue)
Alan offers to make at least one, mayb two PRs in the next week or so:
- add this
- reordering
Questions (slide 8):
1) Should relative Filter Types be allowed in PUBLISH_OK or
SUBSCRIBE_UPDATE (no way to get Largest back)?
2) You can’t change End without changing specifying Start; Is that
a problem?
3) Omitting Group Order is slightly funky
4) Do we feel good about leaving Forward “inline”?
5) Other candidates: Expires and Largest Location
Discussion (40ish minute mark)
...
Conclusions:
- please look at PR and leave comments, it closes a ton of issues
Mike to make slides for Toronto with alternative proposal, otherwise PR
seems close
The following notes were taken by Ye-Kui Wang.
All Times UTC
Administrivia (1600-1605)
Alan presented slides (10 pages) for this topic.
1) Priorty Not Present
2) Use a bit for Object ID = 0
Martin, Will, Victor made comments.
Will: We should use the remaining bits.
Victor: Datagrams and FETCH situations are different herein.
Ye-Kui: 1.b is more efficient. Alan confirmed.
Suhas: No action on item 2.
Agreed to go with 1.b (previous Object in this Subgroup (if any),
otherwise previous Object).
No actio on item 2.
*_ERROR => REQUEST_ERROR
Note that this does not change the semantics of any existing error code.
Ye-Kui: Sounds like a very good clean up to me.
Suhas: Agree in principal. Need to review it.
Will asked a question.
Ye-Kui and Martin expressed supports. Ye-Kui said that this is somehow
similar to the previous one on consolidating error message types.
Suhas asked details of the design with the proposed changes and
suggested a specific way to make the changes. Alan explained.
Reorder the fields and put the parameters first?
Alan said he could make two PRs, one with the reording and the other
without the reordering.
Suhas: SUBSCRIBER default Group Order should be Ascending rather than
don't care.
Ye-Kui: On item 3. I feel that it is OK to have different default values
for Group order for different messages. For SUBSCRIBER, agree with
Suhas.
Tim: There is a way for the subscriber to know the publisher's
preference.
Suhas/Alan: Discussed whether there should be an error in reaction to
Group Order information missing or not correct etc. It seems this
information should not result in an error situation.
Alan asked for more reviews of the PR.
Tim and Alan discussed handling of multiple requests. Alan said that the
OP just needs to be able to handle multiple requests, including those
that did not want.
Suhas: Support the changes in general. Lot of comments...
Alan asked about acknowledgement.
Mike: Prefer not to add requirements on Relays.