IETF-90 DISPATCH minutes ======================== Tuesday, July 22, 2014, 16:40-18:40 (Ballroom) Chairs: Mary Barnes, Cullen Jennings Notetakers: Andrew Hutton and Michael Proctor Jabber Scribe: Jonathan Lennox Meetecho Recording: http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF90_DISPATCH&chapter=chapter_0 Summary: --------- WebPUSH: there was unanimous support for this work being pursued in the RAI area (since a major use case is incoming voice call notification). Half the room indicated they were willing to do work. IOTL: to be progressed as AD sponsored (as usual an expert/RAI directorate review is required). ========================= Notes by Andrew Hutton: ========================= WG MANAGEMENT IN THE RAI AREA (AD's) -------------------------------------- R.Sparks - We have been talking about closing these down for years what is different these times. J.Peterson - Problem is they are not causing eneough pain to worry about closing these down. A.Allen - Insipid has quite a bit of work to do to finish. Cullen - We need to make space (Editors, Chairs, Etc.) K.Drage - Insipid is not finished..... J.Peterson - Urge you to consider what is causing is work. Alissa - These are not been forced to close they are approach a natural end. Mary - There are some wg's languishing but will not name names ...... Charles - XRBLOCK might be longer lived. Alissa - There are options for xrblock..... J.Peterson - I will need xrblock sometime in the future what is the problem with keeping it going in a dormant state is it really causing pain? WEB PUSH -------- Ted - Goals Slides - Should be "Define App Server <-> Push Server Protocol" not "Define App<-> Push Server Protocol". A.Allen - Some previous standardization activity in OMA what is the issue with these why have they not been deployed. Speaker - M.Thomson - The people who initiated the work in W3C where part of the OMA initiative and looked at this but is not suitable. Dan D - Very happy to see this work...... Ted - Why is this in RAI Speaker - The time is small. Cullen - This is probably in a grey area could be in multiple places there are some real-time aspects. Drage - Some apps using this might be in the RAI area but need to have a discussion as to why this is in RAI area. ..... Alissa - There is obviously some interest here and boundaries between areas are not set in stone. Mark Nottingham - .... Learn from websockets issues??????? Dan Druta - There is a lot of synergie with real-time apps..... Ted - Privacy question, Currently queries are distinct and go to separate services agregating them causes some privacy issues. Could be beneficial due to have some control over different services. -----missed some stuff---- Ekr - One of major apps for this is incoming call notification why it is in RAI. ?? Definitately an interesting topic and thinks it is justified to be in RAI..... J.Peterson - People want it and it is useful and not so far from what RAI does. J.Lennox - Do we think the expertise in RAI the right type compared to people in other areas. M.Thomson - Convinced that the RAI is the area to right place we have expertise in going down previous rat holes. J. Peterson - Would be astonished if there is more expertise in other areas. HUMM - Who thinks we should be doing this work in the IETF. ***** Strong consensus in favor did not hear any humms against. Who is willing to show up in the WG and do work. Lots of hands. IOTL - Inter Operator Traffic Leg. ==== J.Peterson - We killed P-Header fields so cannot use a new P-Header. Discussion on what backwards compatibility means in this context....... Question: Should it be generic or 3GPP Specific? Question: WG delivery or AD Sponsor? Ted: If there was a mechanism for 3GPP to request this be a private use URI parameter that is what should happen. K.Drage: If this is 3GPP specific fine but still needs to be IANA registered. M.Dolly: 3GPP Specific and AD Sponsored please J.Peterson: A very low bar to review. Cullen: Does not seem to be the energy for a WG Cullen: Anyone object to getting a SIP Directorate review and AD Sponsor - No objections and Alissa was ok with this. ========================= Notes by Michael Proctor ========================= Brief note concerning Francois' passing. Always be closing - ADs ----------------------- Richard presented his slides. RjS: Some WGs have been hanging around for many years. How can we actually mean to shut them down this time. JonPeterson: Not much effort to leave WGs in a quiescent state. AndrewAllen: insipid still has lots of work, doesn't it? BenCambell: Protest! dart is probably the newest wg in rai! Cullen: (floor) Everyone has a favourite wg, but we need to clear out old groups to make way for new wgs and chairs and document authors etc. Need to trim the dead leaves, need to replace fluffy. KeithDrage: If it has open milestones with drafts in progress, will they be able to complete? Richard: Yes ekr: I approve this message. Richard: Like vipr, moved to AD-sponsored to keep the tempo up. JonPeterson: Too many groups, but don't fret about it too much. Alyssa: No unnatural endings - just urge to complete work KeithDrage: Add dispatch to this list? What about ecrit? Mary: (floor) keep languid groups separate from recent quick groups Charles?: xrblock: might be long-lived. What's the plan? Alyssa: couple of options - keep it open but dormant, or roll into one of the avt* groups. Will work it out nearer the time. JonPeterson: vipr draft delayed - is this a problem? RichardShockey: the problem with vipr is it is a bad idea Mary: Would like to get the vipr draft off the table WebPush - Doug Turner --------------------- Doug presented his slides. TedHardie: Clarify App should be App Server on "Goals" slide AndrewAllen: Previously standardisation before (mobile alliance?) Why hasn't this worked before? Why these standards aren't adopted? Doug: Driving force is wanting push notifications on the web, not just for native apps. Need to define app server--push server protocol but accept device link will probably be proprietary for a while MartinThomson: Previous standard attempts had large amounts of push-back for various reasons, such as authentication and others. Dan@at&t: Pleased to see it coming to fruition - more modular approach allowing delivery mechanism to be separate. Still need developer to engage with multiple delivery platforms. TedHardie: On "Broadcast" slide, is this delivery is basically pub-sub? Doug: Yes - the api between app-server and push-server may be optimised. TedHardie: "Store and Forward" slide, why are we in rai? Doug: Time is very small, 15s-1min. Able to prioritise less urgent msgs to reduce battery usage. TedHardie: Still, why rai? Not real-time. Cullen: We might conclude "this is totally routing", but the storing part is to meet a real-time requirement to not do head-of-line blocking for more urgent messages. dispatch is probably a good place to start. KeithDrage: Applications of this could be in rai, but why this should be in rai rather than in the area with http? Doug: We asked for use-cases, and people said to bring it here first. Alyssa: Think we can close this part of this subject. Obviously there is interest here, so here is a good place to start. MarkNottingham: Interesting topic. Reminds me of websockets. But at previous job, we couldn't scale that out across the platform. Be careful and ensure it is baked in from the start. Dan?: Push service is a complex entity. Synergy with real-time applications. TedHardie: privacy question: device creates distinct queries for different information. Now aggregating in a push service. Could have different push-services to control aggregation in new and different ways. But leaving message encryption to app layer? Just app server->push server? Doug: Pushback from web devs and privacy: there are already libraries that do this. Should do end-to-end encryption. TedHardie: Offering too many choices for web dev. Have a worked example at least. ekr: I agree with Ted. Major usecase is for incoming call notification/sms which are clearly real-time, which is why it should be in rai. Even email notification is expected to be fast now. Xavier?: Interesting topic. Lots of interest in rai to help real-time comms. JonPeterson: This doesn't seem too far from pub-sub stuff. JonathanLennox: Not so much speed as defining reason. Are people with e.g. SIP experience more likely to deliver rather than other areas? MartinThomson: Convinced this is the right place. We have done it wrong before, so we have the wisdom to identify ratholes. JonPeterson: How many times to we need to coordinate with apps? We have skinned this cat in so many ways, we must have the experience by now. Mary: hum on doing work in IETF now. Fluffy: pretty strong consensus - basically unanimous Fluffy: Who is willing to work on this? Show of hands Fluffy: lots of people prepared to actively work on this Fluffy: Will discuss more on the list IOTL - Christer Holmberg ------------------------ Mass exodus from room, before Christer mentions "IMS" Christer presented his slides. AndrewAllen: Loopback slide: This slide only shows signalling? Christer: Yes. JonPeterson: Do we still do P- headers? Christer: Not suggesting using a p-header. AndrewAllen: Not developing new p-headers. RichardBarnes: briefly elaborate what you mean by backwardly compatible? Christer: need to make sure legacy devices strip this indication Mary: (floor) not defined behaviour to strip unknown headers Christer: you strip topmost route header KeithDrage: probably overstrict. You only need to ensure it doesn't cause problems further down the line TedHardie: equivalent to a bgp community with a shared understanding You want to define something only for use within a private community which shouldn't leak out. Maybe register the private-use token and not define it in IETF KeithDrage: Link to use-cases sent on the list. You should have read it if you are interested. Private-use is fine, but still needs to be IANA-registered. MartinDolly: 3gpp-specific and AD-sponsored AndrewAllen: What are the rules for uri-parameters? Fluffy: You need an RFC Fluffy: If we had a document describing this, who should read it? Who is going to read it? 5 people! JonPeterson: The only review needed to ensure it doesn't change the behaviour of SIP. Fluffy: OK to get SIP directorate to review it then AD sponsored? OK - no SIP directorate! Fluffy: Anyone wanting to propose mini-WG? Not seeing the energy in the room. Alyssa: I think what you suggest is fine. Fluffy: Thank you very much!