#csarvenProbably bes tthat you summarise since this is AP specific
#rhiaroI think you know the summary csarven, we've discussed in the past, so this is the materialisation of the general idea of pointing to LDN from AP, and clarifying some of the AP notifications stuff
#tsyesikaindeed, i'm actually reaaally happy to see this, the LDN document which i read back when rhiaro first brought it up seemed like a good more general version of wht we're doing in AP
#tsyesikaglad we're now linking in the relevant parts, it reads well. I should go re-read LDN but i liked my first read of it
#cwebber2this will allow us to clearly distinguish between pub and sub parts but without me feeling like I will run out of time
#cwebber2and will allow us to have the generalized federation as part of another document
#cwebber2while keeping our own specific things (esp side effects)
#rhiaroI'm hopeful that AP Delivery being a specific version of LDN will also help AP systems to at minimum exchange notifications with broader LDP-based systems
#tsyesikai'm also glad we're sticking with one spec, two would have been fine but my preference is on one, i think it will make things easier to manage both for us and also be easier to understand for the reader it not being split into a bunch of documents
#csarvenExtra ++ if AP is comfortable with these based on technical clarification and dedicating resources
#cwebber2csarven, not totally clear on what that means but I think yes? :)
#annbasssounds like you guys are converging on a good plan!
#cwebber2it would simplify interop dramatically and wouldn't really lose anything IMO
#tsyesikayep, all for it, seems like no work for us for better interop
#csarvencwebber2 If it matters, the LD folks are strongly in favour of the profile approach. From the LDN's perspective, we wanted ot at least acknowledge the (dis)advantages to AS2's new mime type. It is part of the reason we thought that SWP may be best place to address that. However, if AP goes ahead with the profile approach, that'd probably be better for implementations since there is only one treatment of the content-type.
#rhiaroyeah so LDN can talk about ldp:inbox, but if AP implementers use as:inbox and that is aliased to ldp:inbox in the json-ld context, it all works out the same in the end
#rhiaroSo AP implementers don't have to care about ldp:inbox and ldp implementers don't have to care about as:inbox
#cwebber2what we could do is one of those "liberal in what you accept but conservative in what you produce" things
#cwebber2by always providing the "@context" but say "consumers SHOULD process with an implied context" in a non-normative section, giving clarity on how to accept content from people who don't quite do the right thing
#cwebber2but, producers should do the right thing.
#cwebber2that way an AP <-> LDP thing will still workl.
#csarvenAnd if you don't have context or a full URI in there, I'm not sure if that does. Unless I'm misinterpreting something here.
#melvsterthinks that creating specs on the imagined behaviour of 'dumb' participants is the road to hell ... simply put in the @context or it's a bug, same with any other omitted field ...