MMUSIC Minutes from the Chicago IETF Reported by Eve Schooler, Mark Handley, and Joerg Ott Colin Perkins - made a brief presentation on changes to the SAP security specification made as a result of comments on the mailing list. Mark Handley - will merge the security spec with the base spec and submit this to the IESG to become an experimental standard before the next IETF. An issue was raised whether these changes to the SAP specification required the version number to change; the previous version of the draft had inadvertantly changed the version number. Mark Handley - pointed out that implementations of the previous SAP security did not exist so that the existing version number could be re-used. - summarized the status of SIP: we have completed WG last call and submitted the spec to the ADs. The ADs felt that performing IETF last call over the IETF was a bad idea so delayed that until after the IETF. In the meantime a couple of errors had shown up in the SIP spec. Besides pure editorial errors such as the consistent use of IETF standards terminology and the need for some explanatory clarifications, a couple of functional errors were discovered. Henning Schulzrinne described these errors and the proposed solutions including the following: - A new error code was added to allow distinction between a busy signal from one (out of many) call legs from a (final) busy signal (on the single or all legs) of a call. - An expiration field was added to the "Location" header to allow reporting independent reporting of different expiration times for each location. Finally, an open issue was reported with respect to the "Location" syntax: in SIP, a "Location" header may be following by several URIs each which associated parameters -- the separator between them being commas and semicola, respectively. In case a URI contains either of the separating character (which is unlikely but possible), this will result in misinterpretation of the "Location" header. Proposed solutions include quoting each URI, allowing only a single URI per "Location" header, and using '<' and '>' as delimiters for the URI similar to the mail address format, and changing the name of the header. The rough consensus was to change the name of Location to Contact and to allow '<' and '>' as delimiters. A new ID will be submitted as soon as the ID editor is accepting Ids again, and we will ask the ADs to do IETF last call on this revised spec instead. The consensus in the room was that the changes were small enough that we didn't need to repeat WG last call. Colin Perkins - presented a proposal for a local message bus for local area conference coordination, similar to the - LBL conference bus, CCCP and PMM. Such a proposal was first made in MMUSIC at the 1994 Seattle IETF and has been discussed occasionally since. There seemed to be a lot of interest in this proposal now. It is not clear that this should be an MMUSIC work item though, as it has the potential to be used for more general purpose local coordination. The rough consenus was that work on this should continue, and that we should consider holding a BOF at the Orlando IETF to see if the interest is general enough to form a new WG. The authors of the Mbus documents agreed to consider the implications of a broadened scope of the Mbus with respect to their design decisions as well as the potential overlap with other WGs (or BOFs) in the IETF before deciding on requesting a BOF for the 43rd IETF. Philip Hoschka - presented a proposal for a syntactic mapping of SDP into SMIL (W3C's Synchronised Multimedia - Integration Language). The rough consensus was that this was the wrong approach -- SDP is quite limited and there is no reason why these limitations should be perpetuated in SMIL. Instead, a description language much more powerful than SDP would be desirable in many cases. It was also pointed out that providing SMIL definitions that follow what is in SDP faces the problem of a SDP being a moving target: this would lead to this part of SMIL always being slightly out-of-sync with SDP and may even result in diverging specifications. Inclusion or referencing SDP as is was conceived a more suitable alternative. However, we want to ensure that the IANA registry used for SDP can also be used for SMIL so the two should share some common syntax. Francois Menard - presented some ideas for using XML in the context of SIP for conveying more general information such as settlements. This wasn't a specific proposal -- more a heads up for people to think about this possibility. Kenji Fujikawa - presented a proposal for SIP URLs. Mark Handley - presented the reasons why he thinks this is a bad idea. Much discussion ensued which was curtailed because we ran out of time, but the consensus appears to be that is this a bad idea and should not be persued. If you absolutely need this information in a URL, use the data URL instead. But preferably don't do it at all.