OMA continues to be fairly heavily engaged with IETF, primarily in the areas of SIP and XCAP as used by OMA’s Push to Talk Over Cellular (POC) and Presence and Availability (PAG) working groups.

We have approximately monthly conference calls attended by liaisons, key working chairs, area directors, and technical representatives. The last call was on Friday, January 20 and the next call is proposed for February 24 at 0900 US-PST.

OMA’s dependencies on IETF are tracked in a dependency list maintained by Ileana Leuca (OMA’s liaison to IETF) at :

http://www.openmobilealliance.com/collaborating/ietf.html

Each periodic meeting reviews this list, after which it is updated and re-posted. Discussion during the most recent meeting identified a need to track the target dates for the OMA Release Enabler that will reference the IETF material in question. OMA really needs an RFC- number reference for their formal acceptance and publication of an Enabler (specification) document, and the long delays in our RFC process before an RFC# is available to serve as that reference trouble them. They would much prefer to have the RFC# available once a document has been approved by the IESG, rather than having to wait 6 to 24 months after that date for the RFC Editor to assign and publish a number.

The OMA messaging working group submitted a liaison statement to the IETF LEMONADE working group on December 19, in response to an earlier LS from LEMONADE to to OMA.

This LS is visible at:

https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=190

I’d like to note that something went wrong with the process in the handling of this LS. My records show that I uploaded it in December using the upload tool. However, the LS apparently didn’t actually make it into the IETF system. I corrected this situation today by re- uploading and verifying the successful posting of the LS on the IETF site. I am unable to attribute the error with 100% surety, but suspect it was user error in handling the upload using the IETF tool. I probably THOUGHT I had it uploaded, and didn’t. succeed. I would have continued thinking it had succeeded had the LEMONADE chair not questioned me about it.

This points out the need for a couple of things.

1) People uploading LS using the tool absolutely MUST go to the IETF liaisons page and verify that the material is there after they think they’re done.

2) Persons processing LS should email copy the affected parties immediately rather than relying on the tool to do it. This provides an opportunity for the affected parties to double-check that everything is going right. Had I done this, Glenn would have probably noticed the failure much sooner.

3) While it appears simple, to use, there are a couple of “gotchas” in the current upload tool. It actually took me several tries to get the LS uploaded correctly today. Foremost among these is the lack of incremental saving — until one has completed the process completely including the final verification submission button, the material isn’t actually posted onto the IETF site, and any error in that flow causes one to have to start over. I ended up restarting five or six times today, then revising for format three times.

Other assorted nits include:

a) Lack of targeting information inside the IETF. There should be a way to select a target working group from the menu. Several of my restarts were due to accidental browser closures while going back and forth in different browser and email windows to hunt down and copy- paste the names and email addresses of parties to the LS.

b) It appears that I can’t send an LS notification to any working group mailing list with a subscriber-moderation policy when I’m not subscribed to that list. Or that I can send them, but they go to the moderator for review. And despite our best efforts the moderation window can be very large — I frequently see a queue of many hundreds to several thousands of moderator requests backed up for the SIP and SIPPING lists. It would be better to send the LS notifications from an administrative identity that is allowed to post to all IETF lists.

c) The content entry text-box in the upload tool is tiny and of fixed size. Trying to reformat a many-page Word document (the source format for OMA LS) after copy-pasting the text into that little text box and guessing where the crlfs need to be inserted to manage line wrap is tedious. I’ve found it workable to copy the Word text into EMACS, reformat it there, then copy-paste the formatted text into the entry form in the IETF tool. That might be fine for a nerd like me, but we’re asking hourly secretarial personnel at correspondent organizations like OMA to do these uploads, and that isn’t going to work for them.

Dean Willis
IETF liaison to OMA