Alan Johnston presented Line Sharing (Shared Appearances) ID.
Open Item: Replace and Join: Proposal to make both must was accepted.
Open Item: Appearance Limit: Unless there are reasons against, we will keep it as it is.
Open Item: Notify: Some clarifications are needed. According to Adam Roach, the usage of NOTIFY instead of PUBLISH could be problematic. It feels like, there could be race conditions, but he has to sort it out.

Open Item: Seize Terminology: Doubts were raised by John Elwell (remote), if seize is a proper term for this. Alan Johnston will provide an updated text.

Open Item: Registration Authentication
Proposal: Support these two modes:
REGISTER
To: <sip:HelpDesk@example.com>
From: <sip:HelpDesk@example.com>
REGISTER
To: <sip:HelpDesk@example.com>
From: <sip:HelpDesk@example.com>
Robert Sparks: RFC3261 was driven by use cases. It is not as clear as it could be.
Cullen Jennings: 3rd party registration is mentioned 2 in RFC3261 cause this trouble. Perhaps we have a bug in RFC3261.
An ambiguity is what goes in From and To.
Alan Johnston: We want to explicitly mention this in the ID to avoid interop problems.
Francois: I believe its legal to do both, but we should chose, which is the best one? And there is a 3rd possibility to do this.

Examples show 202 sending back instead of 200. Should we change?
Francois want to change to 200. For 202 we would have a real reason for.
And we should reference the bis draft.
Robert Sparks: Event header parameter should not be an option tag. See WG charter (Defining ways using existing mechanism for solving problems). We have to careful think about the solution. This can be changed during WGLC.

Next steps:

Close open issues on the list
Consensus to start WGLC on the revised version.

Dan presented the new version of the call completion ID. He explained the changes and presented some Open Items. Clarification is planned until IETF76.

Keith Drage: What was the involvement of the WG for making the mentioned changes. There was nothing on the list, since last meeting.

Dan: Many of the things was discussed at the LEST list.
Keith Drage: Make sure, that you have consensus of the WG for these changes.

Theo Zourzouvillys said a few words, related to the work on REST. Up to now, there is pretty much no update, but he want to start work on this issue again next week. He wants to remove everything, which makes it complicated.

Shida Schubert mentioned, that ACH (automatic call handling) ID is dependent from this. We will try to adopt this as WG item on the list.

Francois: What about the other REST describing drafts? Which to take.?
Shida Schubert: This was the result of the design team.
Adam Roach: Setting up a mailing list on the HTTP Subscribe stuff.
Theo Zourzouvillys: This draft is completely independent from this.

Laua Lies presented the Alert Info URI draft. It proposes a semantic indication via URN usage in the ALERT-INFO header field.

Francois: Dependency on 3gpp document on this – we discovered recently. Structure of the header is changing, we have to look in more detail. 3GPP have to know the changes.

Hannu Flinck: There is an existing 3GPP dependency on this ID and we are aware of it.
Cullen Jennings: Not sure, if we should do this. Assumption: Allert-Info header is nearly useless. Consider carefully, if we want to define semantics for this parameter.

Christer Homberg: It is just proposing a way to use this. It is still semantic free.
Cullen Jennings: No this defines a semantic for this header field.
Francois: People are doing strange tricks to do the things, this ID propose. We should do it in a standardized way.
Robert Sparks: Again there are problems with the current BLISS WG charter.
Christer Homberg: We are not changing the protocol, we are only saying, how to use this.
Robert Sparks: You are defining the semantics of the header.
Christer Homberg: But we are not changing the syntax of the protocol.
G.Halstrom: Interesting topic, but you should widen the scope. E.g. alerting with light or shaking of device.
Laura: That’s already within the draft. That’s UA task, how to alert the user.
Christer Homberg: Assumption is tone is implemented in UAs. Could you additional download a certain file from somewhere.

Laura Lies: You can do both. It is in the draft.

* Agenda bash and general status (chairs)

http://www.ietf.org/proceedings/75/slides/bliss-0.ppt

 

Shida went through the status. Charter update is underway. It will reflect the new structure of RAI area and

have updated milestones. Discussion is ongoing with the AD on adding a milestone for the HTTP-API (REST) work item.

 

Call park draft needs reviewers before WGLC. Volunteers were requested.

 

ACH draft is waiting for Adam's HTTP event package and Theo's HTTP-API draft as it makes use of them. Adam told

he is setting up a separate mailing list for the event package draft discussion.

 

 

* Shared appearance of a SIP AOR (Alan Johnston, draft-ietf-bliss-shared-appearances)

http://www.ietf.org/proceedings/75/slides/bliss-1.ppt

 

Alan presented the status of the draft and the open issues.

 

This was about 7th presentation in an IETF meeting, the draft is getting done. People should stop using the

word "line" in the title when talking about this. Detailed review has been done by a bunch of people.

Appendix has been removed. draft-alexeitsev-bliss-alert-info-urns has been reved by Laura Liess and is now

referenced.

 

Open issues discussion (see the slides for details)

- 482 response

- Proposal: simplify by saying if the request fails or loops, give up.

- No objection.

- Replaces and Join

- Proposal: Make Replaces and Join MUST instead of SHOULD

- Q: Is there going to be an interop problem if we have SHOULD?

- A: More a bad user experience issue.

- Francois: Supports changing to MUST.

- Conclusion: As proposed, i.e. change to MUST.

- Jon Elwell made an alternative proposal over Jabber, Alan will look on the mailing list and respond.

- Appearance limit

- Proposal: Do not specify this in the document.

- NOTIFY

- Proposal: Use NOTIFY instead of PUBLISH when the Appearance Agent subscribes.

- Francois: Support this.

- Adam: Question. Probably OK, could be some race conditions, have to think.

- Seize terminology

- Proposal: Use definitions proposed by Francois

- Sohel Khan: Question. OK.

- John Elwell: What does seize mean?

- A: Seized means reserved.

- (John sent text on the mailing list already during the meeting.)

- Registration authentication

- Some errors in the example URIs were spotted. It was discovered that this is a case of third party

registration. 3261 is confusing wrt. 3rd party registration. Conclusion: support both 1st and 3rd party

modes for registration.

- Robert: Agree that 3261 text should be clarified.

- Discussion on what 3261 actually tries to say.

- Cullen: 3261 is messy, but the semantics in this draft are clear.

- Proposal: support two modes (in the slide)

- Robert: This is not yet implemented yet, but OK for the future.

- Francois: Support these.

- Conclusion: As proposed.

 

Next steps

- Close open issues list

- WCLC? (On the updated version.)

- Robert: Look at event header parameter. Should it be an option tag instead? BLISS charter as written would

not allow it. But that should not be a problem. SIP change process rev will allow WGs to extend SIP, but

BLISS was carefully chartered not to define new mechanisms but use existing ones.

 

 

* Call completion (Roland Jesske, draft-ietf-bliss-call-completion)

http://www.ietf.org/proceedings/75/slides/bliss-2.ppt

 

Roland presented the status.

 

Changes since last meeting

- Major restructuring. Confident that the structure is now final.

- Minor ABNF changes.

- Introduction of CCLN: Call Completion on Not Logged-in

- NOTIFY rate-limiting

- Various other changes, see the slides for details

To be done

- Finalize description of "retain" option

- clarification of CC subscribe forking

- Final version expected by IETF 76

 

Keith: How was the working group involved in agreeing in the recent changes? I have not seen anything on the

list since the last meeting. Go back to the archives and see that there has been a concensus on all major

changes.

- Shida: Will call for reviewers on the list.

 

* HTTP-API (Theo Zourzouvillys, draft-zourzouvillys-bliss-ach-http-api)

[No slides on the IETF materials page, Theo showed one.]

 

Theo presented the status.

 

Not much updates since the last meeting, will continue after the meeting. Try to keep everything simple.

ACH draft is depending on this. Should adopt this as WG item.

 

- Francois: How about the other drafts? Jonathan's one (about REST). Adam's HTTP event package.

- A: Jonathan's draft was REST tutorial. HTTP event package is not a dependency for HTTP-API, but both the event

package and the HTTP-API are required by the ACH draft for a complete solution.

- Adam: Will setup a mailing list for hte HTTP package.

 

 

* Alert-info URNs (Laura Liess, draft-alexeitsev-bliss-alert-info-urns)

http://www.ietf.org/proceedings/75/slides/bliss-3.ppt

 

Laura presented the status. See the slides for history of the draft and the exact interop problem statement.

 

- Alert-info interop problem is in short: RFC 3261 allows setting the Alert-info header but there may not be

a common understanding on the referred content

- Proposal: Signal the intent and allow the recipient to decide how to treat. Define URNs istead of URLs.

- Changes since -01

- New syntax for URNs

- Definitions for PBX tones

- Definitions for service tones

- Next steps

- Interest? A good starting point?

- Christer: This is interesting. Good work for BLISS.

- Francois: Is there some 3GPP dependency on this? Did any of the changes affect that?

- Hannu (the official 3GPP rep): There is a 3GPP dependency. Need to align the 3GPP spec with any changes.

- Cullen: Current Alert-Info has no semantics. Did try to do something about a few years ago. But

there was a decision against it.

- Jason: Need to document existing interop problems. If they exist, BLISS is the place to solve them.

- Francois: The draft already has some. There are some more in the field. People are doing tricks trying

to do what the draft would allow.

- BLISS vs. DISPATCH?

- Christer: This is exactly the type of problem BLISS should be solving.

- Gunnar Hellstr: Need to extend this beyond audio, e.g. vibration, flash, ...

- A: This is already possible. The protocol does not carry the effect, just the semantic.

- Christer: Are the tones local or do they need to be fetched somewhere?

- A: Both are possible. URN can be resolved in different ways.

(Did not record any conclusions of the discussion.)