Attached find the notes of a conference call of the informal group working on identity.
If any members of the SIP WG want to participate in this issue, then please send me an email and I will send the details. If you have any comments on the draft identified in the notes, then please send them to the list and John Elwell. We are planning on an agenda item on this in San Francisco and are working on this identifying the problem. regards Keith ---------------------------- A conference call was held Tuesday 27th January 2009 amongst interested parties. Present: Keith Drage Dean Willis Hadriel Kaplan Cullen Jennings John Elwell Kai Fischer Hannes Tschofenig Eric Rescorla Dan York Dan Wing [and anyone else who joined after the roll call] Keith identified the purpose of the call was to bring up to speed some of the people who had not been on the previous call. Cullen questioned the use of the term "design team" which he had seen floating round. Keith identified that the group had no status beyond being that of a group of interested parties who were trying to capture in a document the problem that needed to be solved with identity, with the aim that this document would be presented in a WG meeting and hopefully result in some form of work being chartered to go forward. Keith believed that the term "design team" encompassed that but Cullen did not. In any case, the key think here is that this is currently informal work and what will be going as input to the WG from the group will only be the document we are currently working on. The draft will not mention the term "design team". John gave a presentation of draft-elwell-sip-e2e-important-02 for the benefit of the new participants. Cullen requested some sort of summary table at the end of section 7. John proposed that more detail needed to be added to the conclusion, and proposed to split this into two parts. One part would cover e2e identity with non-e164 identities and the other would cover it with e164 identities. EKR stated that when one builds a security system, one needs to look at what damange is allowed. Cullen wanted to know what are the middle boxes allowed to break. Keith indicated that it is not the function of this discussion to define SBC functions; there is a SIPPING document that does exactly that. Rather we need to take that document and identify what impact the functions defined in that document have on identity. If anything is missed in that process, that should possibly be a correction to the SIPPING document. Part of the discussion averred that Call-ID and CSeq could be allowed to break; CSeq currently not covered by the document. There was discussion around whose needs were being supported by the intervening SBC boxes, the service being provided to the calling user or the called user, or whether the changes were being made on behalf of some other entity. There was agreement that we should analyse in more detail specific header fields and body types, and the impact of SBCs on the identity characteristics of those elements. This will need to go into detail on the contents, for example, rather than a blanket change of a URI to a different URI, what is the impact of changing a URI to say an alias of that URI, or adding a "+" where one currently does not exist. Hadriel generally called these changes "protocol repair". Dan indicated that all current solutions break in some way, and we need to find a way round that. Agreed that we need to identity changes that can be considered "legitimate" changes where we expect the solution to work, versus "illegitimate" changes, where any solution will not be expected to work. Ihe call came up with some areas where the document should be revised and John would attempt to capture those suggestions in a revised version of the document. Target date for new version of the document was 10th February so it could be discussed on our next call on 17th February. John made a plea for input to the draft in the form of words targetted at the draft. ------------------------------------------ _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
