danielLink Mauve, what do you want council to do with this?
danieltake ownership away?
danielping peter again?
Link MauveMaybe one of these.
Link MauveIt might also be a case of it being stable enough for advancement.
danieldo we have someone who wants to become author?
danieltbh it's not fully clear to me what 371 brings to the table that 176 doesn't. it mentions TCP but that could easily be done with an additional disco feature in 176
danieland/or just do it. i mean it's pretty clear how one would send tcp candidates with 176 if one would ignore the spec (and some implementations actually did this after parsing sdp)
danielpersonally (not with my council hat on) i'd honestly be fine with just abandoning 371
danieliirc 371 is also more explicit about allowing trickle ice. but a lot of 176 already do this just fine
daniel371's goal apparently is to "avoid confusion" but i'm afraid it will actually add more. with 176 currently being in the compliance suite and on the verge of somewhat being implemented in the wild (finally)
danieland I think you don’t necessarily even need tcp for file transfer. datachannels can be reliable too
Link MauveHmm, that might be the case; I don’t think I’ve seen it implemented in the wild yet.
danielI guess we can start a last call. see if we get feedback (that PR of yours is feedback too); see if the author processes the feedback (as authors are supposed to); and if they don’t it's rightfully abandoned? and we will see if there is actually any feedback (demand) from the community to have the XEP