Notes by Renee Cohen
NEW SPEAKER: It's now '83 one. The blue sheets are available. This is the
smallest SIP crowd we've had in a long time. I take it that evening sessions are
not the most desirable time frame. We'll put that in our note to our scheduling
exercise next time. In the meantime, those of you in the back can move forward
and certainly make it look better. Nobody will get grouchy.
NEW SPEAKER: Now, repeat the previous plea, can I have another volunteer from
the audience to take notes. You just type up stuff as it happens. And send me
e-mail and I'll take it from there. Please, a volunteer. We'll pick on somebody,
we really will.
NEW SPEAKER: Well, we'll just finish the call for this document again.
NEW SPEAKER: On oh, there's a volunteer. Right there. Okay.
NEW SPEAKER: The first session, note well, note well.
Okay. In your registration packets, there was a yellow sheet, note it well.
Any questions on that topic before we proceed?
Thank you. Okay. This is the proposed agenda for the first session. We also have
another session Wednesday evening. With this proposed agenda.
Any comment, discussion or suggestions for changes to a agenda? Boy, you people
are such a happy crowd after dinner.
NEW SPEAKER: You should always have evening sessions.
NEW SPEAKER: All evening sessions from here on out. Okay.
NEW SPEAKER: She's saying something I can't hear.
NEW SPEAKER: Good point. Okay. That being the case, no objections to a agenda,
NEW SPEAKER: We want to finish by 9.
NEW SPEAKER: That would be nice. We will proceed. The agenda does say 2 2
hundred, but we can talk fast.
NEW SPEAKER: First thing on the agenda is the quick review on the working plan.
This isn't by any means exhaustive. But, one really cheer re point, we actually
have revised the proposed standard version of the SIP specification, it went to
the I S G after IETF last call and we have a big thumbs up, yeah.
Robert and Allen and all of the other guys that worked on the SIP editing team,
deserve probably a whole lot more applause than we just gave them. It was a
heroic job. The other thing that we have gotten done, is SIP something
specification, and thank you, Adam and server features and server location,
reliability, all those things.
Session title has come back to haunt us very slightly. It was sitting in the I E
S G queue and got leaped frogd by BIS, but it needs to have a slight update to
be BIS compatible, but nobody was screaming for it.
This is our charter as we currently have it, along with these items down here,
none of which are done yet. And so, where does that leave us? Okay. I have a
suggestion for status on things. Such and timer guess back to the authors for
BIS update. Caller something the ought they are is expecting to do a BIS update,
we probably need to move it to something like may on the Milestone list. The
mine knee folks and update pre extensions are in working group last call. And we
have half a dozen to the I S G by April. That appears to be roughly on track.
We'll hear some updates on some of those topics later, either tonight or
Wednesday session.
Same deal for the privacy specification and DCS, and the meeting authorization,
which is just an information prep, DCS is now with E GP. And the SIP MIB, the
current position on the list seems to be rather than completing the MIB
specification for RF 2543, we should do the work and update it and get that
finished off.
NEW SPEAKER: Do the MIB authors believe this is a reasonable schedule, getting
it out by may? Does anybody here --
NEW SPEAKER: I think it's ambitious. But --
NEW SPEAKER: I agree, but it would be nice to get it done. Somebody else, who is
involved in the MIB? Kevin?
NEW SPEAKER: I don't see anybody.
NEW SPEAKER: All right. We might take this to the list, but I'd like to meet
this --
NEW SPEAKER: Kevin mumbled something to me about that sort of time zone. He may
be overly optimistic, but he was thinking that type of time.
NEW SPEAKER: Okay. I'd like to get that to happen.
NEW SPEAKER: Okay. And we'll hear some updates on the refer method and related
things this week. There's some open issues there that need to be taken care of.
And there's a high priority, to I S G in the spring time frame, with may as a
target date. Any complaints about that idea. Robert?
NEW SPEAKER: No complaints.
NEW SPEAKER: Good. What else is happening out here?
NEW SPEAKER: That one might even be more important, because there's a whole
bunch of implementations of it already.
NEW SPEAKER: Okay. The message method, I believe that's ready for working
group last call, we just haven't done it.
The path header is an ongoing debate item. We have some consensus to do
something that meets the three GP requirements but we're still arguing with the
details there. And we actually have a draft to provision that in process right
now that should be out immediately after the, black out period closes. It's in
limited discussion right now.
Nat awareness, I think Jonathan said he was going to give an update on. Yes? Is
that you.
NEW SPEAKER: Well, it's a SIPPING thing right now.
NEW SPEAKER: Well, there was the one other header thing we had to have.
NEW SPEAKER: The SIP nat
NEW SPEAKER: Something else.
NEW SPEAKER: Take it to the list.
NEW SPEAKER: We'll move on.
NEW SPEAKER: You already had SIP map up there. Is there another one?
NEW SPEAKER: I think he's hallucinating.
NEW SPEAKER: That happens a lot.
NEW SPEAKER: Do we need more map documents?
NEW SPEAKER: Yes.
NEW SPEAKER: No.
NEW SPEAKER: A couple things it said in the charter, I don't know exactly what
we're doing about --
NEW SPEAKER: Before you get too much further, if you could go up on your list,
NEW SPEAKER: I'll try.
NEW SPEAKER: Message something two, we talked in Salt Lake City about moving
that up. There was no opposition to it. As somebody is going to mention later,
it is ready to working group last call and I'll let him talk to the one thing he
wants to talk about.
I would hope it would be very reasonable to go ahead and push that thing through
in a very near time frame.
NEW SPEAKER: And if, you know, if there was an update that's needed, before we
can actually do official working group last call, we can do it as soon as that
comes out or we can start right away.
NEW SPEAKER: We'll talk about that at the end of the session.
NEW SPEAKER: Okay. No reason to wait.
Yes.
NEW SPEAKER: Okay. SIP privacy and security requirements to I S G. There doesn't
seem to be a strong consensus that the SIP privacy header extension from DCS
also being used by three GP P, also represents a strong general solution for SIP
privacy issues. We have the Milestone for developing privacy and security
requirements requirements, this is an old Milestone. We beef advancing it along
as we started the group. We'd like to think about proposals for either achieving
that Milestone or figuring out something that's achieve able.
NEW SPEAKER: I'd be happy to look at that and try and put something together
that would be an achieve able Milestone for that. I'm sure we could at least get
one or two revisions of such a document out, considering we evern't done
anything today, I think we would be overly optimistic to get it out by may. But
I do feel there are additional privacy and security requirements, especially on
the privacy space in terms of user provided privacy versus network provided
privacy. Because DCS is just network, that we need to capture and explore for
that.
NEW SPEAKER: It would seem it would make most sense, in terms of if we were then
to have a notion of what we want to do with it. I'm having, having learned by
too many privacy security, particularly the latter, box and permutations, it is
not clear that just another requirements document is in and of itself, never
gets more documents.
( I'm never against more documents but -- )
NEW SPEAKER: I think there's some people here who probably would have some
notion that this is, this gets us anywhere besides a philosophical discussion
that we could have of privacy related working groups.
NEW SPEAKER: Fair enough. I think we need to go beyond requirements, whatever we
do.
NEW SPEAKER: Okay.
NEW SPEAKER: Well, question from me is, does the security requirements, they're
meant to be representative of the bits that we're still putting through SIPPING
on the three G requirements or is it something else?
NEW SPEAKER: I was going to say, the requirements have to go through SIPPING and
they certainly relate to the three G requirements. I think this is just the fall
out from the discussions on the privacy draft. It's not being adequate.
NEW SPEAKER: Back up on that. The SIP privacy and security requirements predate
the formation of SIPPING. And at the time we formed SIPPING, we talked about
putting it over into a deliverable of the but the I S G at the time felt this
was such a critical piece SIP should stay in the SIP working group.
NEW SPEAKER: Let's get it out before we argue about where it goes.
NEW SPEAKER: I think having something to concrete to discuss with, is a very
good thing. But concrete was the important word there.
NEW SPEAKER: Well, we do have a couple of documents calling themselves privacy
requirements, that are posted in the past. Just weren't privacy design team. Is
any of that a base line?
NEW SPEAKER: I have this problem with the word concrete this those documents.
NEW SPEAKER: Well, it's very hard.
Okay. So that's the open issue that we need to deal with. And I would encourage
anyone who has ideas to think about it and get back with us on the list, or in
private as appropriate.
Also, we have a July goal for SIP over SCTP, that Jonathan had done some work on
that --
NEW SPEAKER: Gonzala.
NEW SPEAKER: You were just explaining it to me then. Gonzala. There he is.
NEW SPEAKER: It can be closer, we are basically ready for our last call, so
whenever you want. If it's before you like, that's fine with me.
( Before July. )
NEW SPEAKER: Okay. Any --
NEW SPEAKER: Just curious,
( He said something in Spanish I think. )
NEW SPEAKER: No.
NEW SPEAKER: You're in the wrong meeting. You chair that group too, but that's
not this one.
( I didn't even understand what he said at all. )
NEW SPEAKER:
NEW SPEAKER: Okay. We also have a head of us, somewhere in the July time frame,
having to do the working group review, or we're ready to terminate, we haven't
achieved our No. 1 goal of achieving a SIP standard so clearly we won't be able
to terminate in July. My guess is that the draft of standard version of SIP
would be something like July of 2003. At the earliest.
NEW SPEAKER: We have 16 months.
NEW SPEAKER: 16 months. If we want --
NEW SPEAKER: That's pretty much July.
NEW SPEAKER: Something about 2543.
NEW SPEAKER: The original SIP specification is 2543. There's a romantic urge to
get the draft version out to claim the RF C3 5 4 three number. So current
estimates of draft publication and, that gives us about 16 months. So July O
three is actually a pretty good target. We should probably aim for may.
NEW SPEAKER: Maybe November.
NEW SPEAKER: Okay. One of the semi open issues that has been floating around,
that's a hot priority, we have a charter item for pushing certain elements of in
point state or server state into the SIP signaling paths; so the original idea
that was put forward in the DCS state draft, and then Brian and I ground out the
H T T P cookie specification translated to SIP as the cookies draft, probably
can be used for much the same thing with an easier to deal with syntax. I don't
know if we came to a consensus on which way to go forward. Any comments?
NEW SPEAKER: I think that the cookies draft is, is perfectly adequate for
accomplishing the things that you could do in the state draft and it also I
think has slightly broader applicability. I definitely support doing something
with cook keys, and further, certainly a more general comment, the, some other,
other industry and standards groups have been looking at, you know, that sort of
general problem space and looking for a solution there. And particularly the,
what is it? The BIS --
NEW SPEAKER: CMS S, thank you.
Just a system for signaling between like pairs of things that would like to be
able to take advantage of a standard. And I think it would be nice to move along
in that direction, since I think the work is mostly done, we just have to pick
one or the other.
NEW SPEAKER: Is anyone aware of implementations of either one of those yet?
I know I threatened cookies but I don't think we've done them.
NEW SPEAKER: Unless you're willing to pay the price, no.
NEW SPEAKER: So, who would --
NEW SPEAKER: I have to be radical, I'm sorry.
NEW SPEAKER: We have to have a radical proposal from Jonathan. This could be
fun.
NEW SPEAKER: Okay. The reason nobody has implemented this draft is probably
because everybody is doing the same thing, which is, they're using record route
and contact to, in the user parts, particularly where it contains cookie
information. A process which is vastly simplified and improved by the BIS spec.
So it is not entirely clear to me that this is even needed. Not unless the scope
of the problem is defined to be broader than the dialogue. That would be my
challenge, actually.
I mean, why is it that nobody is clamoring for it? We had this conversation
before, but my point is the new BIS loose routing makes it far less stupid and
ugly than it was before. I think.
NEW SPEAKER: You just answered the question as to Y why is there a core route
that requires the proxy to be on the path for every single method and the idea
that was put forward at least in the state draft, you wouldn't have
requirements. It would only be for messengers that traverse those proxies, that
you you you wouldn't require something. That's the difference.
NEW SPEAKER: What.
NEW SPEAKER: I don't get it.
NEW SPEAKER: Well, so that's the good question. In DCS at least, you use no.
Not a good answer.
NEW SPEAKER: I think some people might not be clamoring for it because it seems
like such an obvious thing to do in SIP for so long, we just assumed it would
happen sooner or later.
NEW SPEAKER: No, because people are using record route for the function. That's
what I'm saying.
NEW SPEAKER: And I'm really having a draw on some old conversations, but I can
remember some discussions where we looked at the record route issue, and it
seemed like we were going to have some trouble, but it's been so long, you know,
this issue has been a by, and we assumed that either the state and cookies could
do what we wanted, as long as we get one or the other, fine. But if we throw
that away, I have to have some more discussion with the same engineers and go
back through the reasons why they felt the photograph wasn't sufficient.
NEW SPEAKER: Record route wasn't sufficient because there was no way to put in a
primary and get it back. Where we rip the destination out, you have the user
part, really to represent that information. So maybe that's, you know, maybe
that's changed.
NEW SPEAKER: Am I being dense, with record route, you can establish that state
and push state exactly once in a dialogue.
NEW SPEAKER: Right.
NEW SPEAKER: You can't change state as the dial up --
NEW SPEAKER: So I asked for something simple, which is, what is it doing that
you can't do with record route that would warrant that? If that's the
requirement, okay. But I actually did remember, or didn't even realize that that
was in cookie. Maybe there's other things too, but I'm just saying that, if the
requirement is just to push the state for the purpose of the dialogue, we have a
good mechanism to do that.
NEW SPEAKER: We need a requirements draft?
NEW SPEAKER: No.
NEW SPEAKER: Okay. The draft delineates what problems what problems aren't
already solved.
NEW SPEAKER: The draft?
NEW SPEAKER: I don't mind rewriting the draft. I guess I'm kind of lost but I
don't want to show my ignorance in front of all these people so I'll talk to you
later. I think it's useful but I probably don't understand what you're doing. So
we'll work on it.
NEW SPEAKER: I mean, I certainly don't mind working more on the draft, and we
need, but if it's useless, it's useless and we shouldn't do it. Take it to you.
NEW SPEAKER: More general question is, we used to have a reasonably good
schedule in terms of like last call, type of schedule. We have lots of drafts
which all have last calls which we just had, at some point, in the near future,
and are you still going to try to schedule them basically non overlapping,
consecutive, overlapping for small drafts? Is there any type, I mean, have you
thought at all about just scheduling us, because a number of these things are
probably, I mean, the only question is can you get people long enough to
remember what the issue was, as opposed to actually --
NEW SPEAKER: Yes. I think we'll give some thought to how many simultaneous last
calls we've got going. And I think it will be influenced by the size and
complexity of the drafts involved.
Our goal is to get a lot of stuff out that's been hanging around for a long
time. So you will see some overlap, but we're not going to have 12 last calls
running simultaneously. That's crazy.
I think we'll maybe, be leaning on some of our volunteer help to help us put,
you know, revise the schedule. I mean, there used to be this nice schedule. And
we'll probably revive that a little bit.
NEW SPEAKER: The other issue, there may be a number of small stuff, for
example, recess priority, pipe H type drafts, which are not on your current one.
Do they have to wait until re chartering?
NEW SPEAKER: No. But I certainly have been worried a lot about, I mean, we're
not -- there are some things that have been hanging a wrong for a long time. As
long as we don't have any problem with A Ds for scope and charter and all that
other stuff, the module of this issue of how many things we're doing
simultaneously, we will try and work them in rather than put them in the back.
If they're short and there there's no objection, it's a good thing.
NEW SPEAKER: I think if we plan to really have a schedule out, gradually,
NEW SPEAKER: Yes, we need priorities too.
NEW SPEAKER: Exactly. We need a priority list. Some sort of a no TRIP
accommodation of basically wage times effort, bank for the buck like
( B.A. N G. )
So my comment was, I think it's useful to learn from lessons of successes. And I
actually think that bundle one delivered to 3-D was a very good success story
about delivering on time. Which at some point, it wasn't on time, once we pushed
the schedule far enough forward. But we had predicted that date, something like
one and a half to two months ahead and we hit it on the, right, you know, exact
dead on. That was largely due to all night terse and other horrible things we
had to do.
But part of the, sort of the psychology that I think went into it, was that with
the current mechanism, we were just sort of randomly last calling drafts one at
a time, here and there. But discussion already happened because it was other
stuff that people were interested in. One of the things the bundle did, since
there was more than one thing to be focused on at a time, it was a big enough
set that people could focus their energies on that. There was enough in there to
keep peoples interest, so instead of doing one little one at a time, where the
discussion covers everything, we say, this is what we're doing now, these four
drafts and don't talk about anything else, this is it, maybe that's an approach.
NEW SPEAKER: We can consider that. The advantage on the one half is that, the
drafts related to one another.
NEW SPEAKER: And they're all
(Several people talking.)
NEW SPEAKER: And a lot of these things don't have that characteristic. But I
think it's a good suggestions and we should consider it.
NEW SPEAKER: We need to wrap that up. On state {ter} cookies, the authors will
revise that the cookie draft, put it out and we'll make the call. So, what do we
do with the category?
NEW SPEAKER: Actually, the guidelines offers specific extensions, it's not a
charter item and I can't spell it. But Jonathan?
NEW SPEAKER: So, this has just been sitting around as a draft, and hasn't gotten
any comment. The only change, the stuff we had in BIS, which we had was
normative and we thought it was guidelines, I think I did issue a rev for this
meeting, it's circling. There's nothing that, you know, done as far as I know. I
welcome -- I guess it needs, I need to finish the BIS update, but beyond that,
it's done.
NEW SPEAKER: Oddly enough, when we re chartered, that somehow fell off.
NEW SPEAKER: Nobody seems to pay attention to that.
NEW SPEAKER: I'd like to see the SIP change get, be C P and then do that, just
in case.
NEW SPEAKER: Okay. Actually doing them together would be nicer.
NEW SPEAKER: And they're related.
NEW SPEAKER: They are indeed related.
NEW SPEAKER: Good. And you were starting to talk about what we do with the
conferenceing stuff, there was a discussion of that in SIPPING this morning.
NEW SPEAKER: I think the three P cc stuff, is clearly, is now a very pure usage
draft, it describes a usage of, you know, base line SIP, base line BIS 9 and
author answer, and I think it's really important, and I think we should do it at
SIP A pronto. We should just get it done.
With respect to the other stuff, I think that, you know, we need to figure out
what the right number of drafts is to have there. But again, that stuff is usage
or framework or that kind of stuff and we should probably try to get done in
SIPPING. If we need extra agenda time, we need to discuss it somewhere else.
NEW SPEAKER: In other words, defer on the other stuff until somebody screams for
it?
NEW SPEAKER: No, I didn't mean that at all. I mean we need a concrete proposal
for, you know, structure of related drafts. And what we do, and then we should
go and ask everybody --
NEW SPEAKER: This is more bundles. You're basically in support of what Jonathan
said. Put them into groups and deal with the groups together.
NEW SPEAKER: Sure. I was just thinking, you know, we need a home for that and we
need to decide how many documents and how are they related.
NEW SPEAKER: Okay. Well, on that note of change, let's talk about the SIP
change process. Alison, you requested this time slot, you're up.
NEW SPEAKER: Okay.
NEW SPEAKER: We are here one minute early.
NEW SPEAKER: You put the draft name on the agenda? No. Do people know, how many
people read the SIP change draft? How many people have studied it closely?
Okay. It's not a SIP draft. It's a, it will be an individual. The transport
area. Oh, good, you can read it now while I talk from my index here.
People have said, there's no real reason to control SIP extension, because all
SIP extension is really about informational stuff, like headers and stuff. And I
wanted you to envision if the replaces header was actually not done by the
working group and was done in a completely free form manner , just registering
at the I M L and there you go. It has amazing properties of changing the nature
of the call. We felt we think we convinced the chairs, all of them who signed on
to be authors, that you should exert a working group discipline over extensions
of SIP. And we're trying to do that.
The RFC, what is the RFC number of 2543 BIS.
NEW SPEAKER: 3261.
NEW SPEAKER: Yes. I just
NEW SPEAKER: But we don't know that.
NEW SPEAKER: Okay. I'll make that comment. You don't know that, but actually,
it's almost going to pop out. R C 4 three six one has an IANA consideration
which was very different from what you had before, which says things like you
need an RFC when you make an extension. And then that would have made the SIP
change document which says that you need a standard RFC for headers, for
methods, I'll get back to headers in a second. For response codes, for warning
codes. That's in the BIS but not the SIP change. And the one place you don't
have to deal with that, s when you need an RFC, but it's somewhat more the
discretion of the working groups who developed them. In consequence, also, the
way that people set up option support and require, is that things which are not
standard and I'll get back to that again, do not get to have architects and
don't get to go required. You may have note noticed that servers at the IETF
took for every, because they didn't like the idea that either end of the
conversation could say you need this extension. I'm a vendor, I have this
extension. It's not vendors, but I'll not going to talk to you unless you do it.
So the way it's written in the RF C3 two six one, is a reasonable approach to
not having expansion, but there's a lot of eloquence, in my opinion, of why
that's not a good idea for security and stability reasons and so on.
Our plan for SIP change is to last call it for four weeks, as an IETF last call
as a P C P and then consider it binding. Yes, Henning?
NEW SPEAKER: I don't want to interrupt you.
NEW SPEAKER: Don't interrupt me then.
So, the two exceptions are bin packages, which we give more discretion to the
working groups who need to use them, but we have no more groups about management
in both SIP event and SIP change. And then a kind of header called P headers.
Not X headers because they have been abused and of course having a letter change
is going to change this all. But P headers are more con trained than constrained
than X headers. But you don't have to go through the process of getting SIPPING,
getting SIP to a change. You can publish them through the other channels in the
RFC that's possible to provide.
Other channels in, which seem to emerge that are experimental. They're not
working group. And P stands for preliminary. Sometimes they will be something
that will actually go somewhere later. And in reference to that, reserve the
string, no matter what kind of P header, they are, reserve the string that they
have chosen as a name, in case they have a future life without their P.
Preliminary private, and then there will be the applicability statement that
says it really is private, we'll use it except in my network.
And then, what was the other one? I forgot.
NEW SPEAKER: Proprietary.
NEW SPEAKER: Okay. Are you done with that aspect? Because I'm going to comment
on that point.
NEW SPEAKER: Go ahead, while I think.
NEW SPEAKER: I mean, while I, I agree with the notion of naming characteristic,
of having the same headers that X headers have, they have the same backwards
compatibility issues that X headers have introduced, if you change them around.
So I strongly disagree with that particular choice. I find it unnecessary, it
doesn't --
NEW SPEAKER: Which one.
NEW SPEAKER: The naming choice.
NEW SPEAKER: The ability to reserve the string.
NEW SPEAKER: I have no objection to reserving a string. I have an objection to
basically attaching a meaning to P dash.
NEW SPEAKER: But the meaning is it will never have an option tag it it may not
have an option tag so it cannot be used in the same manner as option tag and
there are a bunch of other conditions in SIP change that apply to P headers,
such as they have to have applicability statements.
NEW SPEAKER: There's two, I think, separate issues. There's a naming issue.
NEW SPEAKER: Yes.
NEW SPEAKER: Where I disagree. And a process and applicability issue, which I
agree with. Okay. I don't see that coupling the two helps in any substantive
manner. The reason is, let's say, if you were to take an alternate suggestions,
which I made to you, which you now never got a response on,
NEW SPEAKER: Maybe I couldn't pars it. But.
NEW SPEAKER: That happens. If you had ahead err name, which was registered, call
it no naming restrictions, foo, whatever. That header has exactly the properties
which, as long as it is in this nonstandard C status, that you describe, it just
looks exactly the same as a normal header, so if it should progress to a full
standard strike status at some point, it retains its name.
NEW SPEAKER: So you just like P for the preliminary ones because you will have
to do something to make them non preliminary later?
NEW SPEAKER: No. I don't have, I don't dislike -- I don't --
NEW SPEAKER: I think it's --
( They're talking without the Mikes and I can't hear. )
NEW SPEAKER: You like to have them have their real name. But somehow not,
because they don't have options. I think it would be easier to enforce if they
--
NEW SPEAKER: The practical problem is the same as the X problem, in the sense
that --
NEW SPEAKER: Well, it's not X headers can be registered freely at will.
NEW SPEAKER: Yes.
NEW SPEAKER: There's a lot of differences between. They're completely free form.
You don't even have to register them.
NEW SPEAKER: Exactly. What I'm saying is, if you were to allow registration of
headers, using the same process you have currently.
NEW SPEAKER: No. With R C and everything.
NEW SPEAKER: With the P process, if you call it that.
NEW SPEAKER: Yes.
NEW SPEAKER: Call it the P process. Yes. Preliminary proprietary registration
process. By not a standard RFC. That's the summary of the P process.
NEW SPEAKER: Yes. It requires an RFC.
NEW SPEAKER: But not a standard strike out of information, experimental or
whatever.
NEW SPEAKER: And it has a number of restrictions on it.
NEW SPEAKER: And it has these do not arm restrictions on it. Effectively.
NEW SPEAKER: Yes.
NEW SPEAKER: And the sense is, if you don't know them, nothing bad will happen
to you.
NEW SPEAKER: And also, given that it may do harm, it doesn't require you to use
supportive headers. It doesn't allow you to do the processing, which copies
require.
NEW SPEAKER: Yes. And all of these are, we're in full agreement on that.
NEW SPEAKER: Yes.
NEW SPEAKER: So the process is fine.
I see no advantage to labeling these headers, I only see the disincentive to
actually go forward, let's say, I've taken somebody standardizees -- I'm sorry.
Somebody, informational, a header which turns out to be useful. Call it P BOP
for a bio header. And this bio header becomes a P BOP header becomes popular and
gets implemented in a large product of a large company.
Now, they decide, maybe we should want to make this a standard strike header.
Now you have a problem. You have a problem you have is, since you now have to re
name this header --
NEW SPEAKER: But they wanted the ad option. They wanted to do things to make it
more fully deployed than it was.
NEW SPEAKER:
(Several people talking.)
NEW SPEAKER: That's not all headers which are standard strike are actually
(Several people talking.)
NEW SPEAKER: What's the harm to staying with a P header if you're massively
useful and everybody uses you and you don't cause these requirement conditions
on everybody? What's the harm of staying with the P?
NEW SPEAKER: Because that's not a standard strike.
NEW SPEAKER: So the question is, can you turn a P header and make it the same as
standard.
NEW SPEAKER: Could you make a P header standard strike? I don't know why you
couldn't.
NEW SPEAKER: It certainly implied by reserving that name.
NEW SPEAKER: Yes.
NEW SPEAKER: The process document indicates that the P dash version of the
header work, and continue to be usable. That's an open question --
NEW SPEAKER: I don't want to discourage, I don't want to suggest changes,
because even things that should be standard, get the review of the standard
strike, discourage people from doing it because it means they're breaking
existing implementations.
NEW SPEAKER: It doesn't though, because I keep using the P dash anyway. If we
didn't say that right, it's --
NEW SPEAKER: If it does have the effect of making one's pars tables something.
That's a question or issue too.
NEW SPEAKER: I just wanted to bring something up. I personally, I don't have a
problem with registering things, with registering nonstandard extensions that
don't have a P in front of them. But I don't have any problem with having a P in
front of them. And the reason is that, I think that, you know, '95, 99, 99 point
9 percent of the extensions that have a P in front of them are never going to be
standardized because they're basically a relief valve. And for the one percent
or whatever percent of these drafts to become proposed standards that we can
write, you know, we can damn well add an option tag so if you really want to be
able to use the, you know, the non P version of this header, that's so important
to you, that you don't put the P dash in your, you know, in your message, that
you have a standards based way to do that.
NEW SPEAKER: Make it a final P, like for psychology. Or --
NEW SPEAKER: I'm just trying to make sure I understand the issue here.
It seems to me like you were saying, if you have, some header that's a P header
and it be becomes popular and you decide you want it to make it informational,
do you write a standard and not change the name. Are you saying you have to
remove the P?
NEW SPEAKER: I think we're hearing a preference to leave the P there. And I was
up in the air on implementing it, whether it would be easier to deal with the
idea that things only have option tags without Ps. I think it's probably a
question of what makes sense for actual real in the field stuff.
NEW SPEAKER: Right.
NEW SPEAKER: I don't have an inherent requirement that it be that way. And the
expression I was using, if you want to take me up on this, a pressure valve
inside an enclosure, for me, P provides a well understood enclosure. For
example, it's anti press release. In some case.
NEW SPEAKER: Yes. It seems to me sensible to have P, it's not a needs base, but
it says, this is okay. Doesn't have an option tag.
NEW SPEAKER: Yes.
NEW SPEAKER: So it seems to me the conditions in which you want to remove the P
is if you want to change that what you proposed
NEW SPEAKER: Add the option tag.
NEW SPEAKER: Right.
NEW SPEAKER: A different ability to make changes to behavior and so on, because
you discovered the valve to take it outside.
NEW SPEAKER: Well, I don't think there's any, I'm going to try and cover the
functionality. You ought to be able to re name it anyway. So surely when you go
to the Internet draft, you've got to be able to indicate that.
I want to comment on the line before, that you highlighted. Must not be required
by introduction deployment. So define the P headers and then we're not allowed
to use them. That's -- at least that's the way I read it anyway.
NEW SPEAKER: No, considered something about specifications. That may mean more
than. It is not related to being compliant with I (e) and (f) specification:
NEW SPEAKER: Three G requires some things that are P headers. I read that to say
three G specification, it says you use information RFC, and maybe we just need
to look at the wording.
NEW SPEAKER: I think the idea is that that would be considered an extension
which is not IETF compliant. And you have to fall on base line behavior and
still work.
NEW SPEAKER: And it doesn't make their usage not IETF compliant. It makes it,
it's not, it's outside the question of IETF compliance.
A part of this was about, don't make us say it's not SIP because then we'll
start changing SIP freely in all the other ways, and we want people to view
themselves as SIP compliant and IETF compliant.
NEW SPEAKER: We need wording there.
NEW SPEAKER: Send suggestions.
NEW SPEAKER: We were stunned by the idea that we were no longer SIPPING and we
were having header problems.
NEW SPEAKER: I have a minor problem. I feel uncomfortable mixes naming
conventions and algorithmic behavior. So I have no problem with saying you have
to have P headers. I do have problems saying my parser has to look and say, oh,
is this a P header, it has an option tag on it, reject the message. I don't like
the idea of having to parse inside header strings, right, to figure out --
NEW SPEAKER: Why?
NEW SPEAKER: To figure out what's going on there. So I have no problem with P
being a naming convention, but I do have a problem with having the right code in
my parser that knows that P dash inside a larger token means something.
NEW SPEAKER: Just to be clear
(Several people talking.)
NEW SPEAKER: Just to be clear, because from what people are saying, it seems
like they think this is true. The name of the option tag is totally and
absolutely unrelated in every way to the name of the header.
NEW SPEAKER: Yes. And --
NEW SPEAKER: So the fact that you see ahead err with a P in it, and you don't
know what it means, there's no way to look to see if there's a require header
tag for that. You just can't. People know that? I mean, that's, so, you can't
do, there's no protocol processing when P is in front of the header, period.
Just to make sure people know that.
NEW SPEAKER: It seems to be confusion that, an H T T P extension model is
different than SIP.
NEW SPEAKER: It better be.
NEW SPEAKER: And the problem I have with what you're saying, seems to at least
imply that there is a notion that it is a P or non P headers, that those would
be appearing in any way, directly in a one one mapping in a require or support
header.
NEW SPEAKER: No. Actually, I'm sure there's quite a number of things Chula Vista
gotten out there already which don't have P which should not have option tags
and there should be a table related with appropriate option tags.
NEW SPEAKER: The point is a different one. In the sense, to amplify what
Jonathan said, there's no correlation, not just in naming, but at all between
header names and option tags, only in incidently.
NEW SPEAKER: Only that something correlates with the option tag, whatever your
option tag is.
NEW SPEAKER: No, this has nothing to do with standards time or not. This has
simply to do that the option tag has no relationship whatsoever with a
particular header.
(Several people talking.)
( They're all arguing. )
NEW SPEAKER: We can fix that if there's any implementation of that.
NEW SPEAKER: As you progress to option tags, that implies a relationship which
doesn't exist.
NEW SPEAKER: When you go to SIP it, because it's not a standard RFC, that's a
failure.
NEW SPEAKER: I don't see the connection here.
NEW SPEAKER: That's the actual path. You cannot have an option tag that is not
--
(Several people talking.)
NEW SPEAKER: I have no problem with having --
NEW SPEAKER: No, header requirements have options. They do
NEW SPEAKER: Yes. They do.
NEW SPEAKER: Replaces talks about an option tag.
NEW SPEAKER: I think I can clarify this.
NEW SPEAKER: Let the chairs who are talkers actually do this.
NEW SPEAKER: Okay.
NEW SPEAKER: I'm sorry. I'm a share of chair of a different working group.
Okay. If you write a, there's no need for you to be com compliant to do
something special in your parser just because ahead err had a P dash in front of
it. All you need to do in order to be compliant with the spirit of this document
is to simply, you know, in your array of things that you put, I'm going to stick
these in, I'm going to accept these in a require header and I'm going to send
these in a supported header, that you don't put anything in that list that isn't
a standard --
NEW SPEAKER: Header names are option tags, we're confusing the -- I have no
problem with saying that option requires tags when supported require tags should
not be in anything about a standard strike RFC. That has nothing whatsoever to
do with header names.
NEW SPEAKER: That's basically --
NEW SPEAKER: The problem the problem with the draft
NEW SPEAKER: I don't think the drafts
(Several people talking.)
NEW SPEAKER: That's the problem.
NEW SPEAKER: I don't think it does. Remember
NEW SPEAKER: Remember I asked if you studied the draft? The draft is carefully
worded by the chairs and people --
NEW SPEAKER: We screw up, so.
NEW SPEAKER:
NEW SPEAKER: Right here in this text that I've got highlighted, it talks about P
dash extensions, and really, we're talking about P dash extension headers.
NEW SPEAKER: Right.
NEW SPEAKER: Which is different than the sort of extension presence that's
negotiated by an option tag. I think that's where the real confusion is.
NEW SPEAKER: Oh.
NEW SPEAKER: You can't actually --
NEW SPEAKER: Got an oh.
NEW SPEAKER:
(Several people talking.)
NEW SPEAKER: Can I finish. The other categories of extensions, currently we
don't have a P outlet for. Only headers. Because all the other constraints,
there's no P measures, no Ps responses. There's no P group of things. In fact,
you have to look at that. But you might, I mean, you're going to have to try to
avoid sending extensions that use P. That's fairly simple.
NEW SPEAKER: What Henning is saying, we have extensions, I mean, s options that
they don't have a header related to them. So there's no header inform call P.
NEW SPEAKER: Yes, and those have standard RFCs associated with them. Well, if
they don't, they should. And, we may have to grandfather some, but,
NEW SPEAKER: This discussion seemed to stop by some assumption, this
specification or document, actually, impacts SIP implementations. It hasn't
impacted the authors of SIP RFCs, so basically we need to make sure we have the
application documents, whatever that's going to mean written corrections.
NEW SPEAKER: People who have standards show up in testing.
NEW SPEAKER: An implement of SIP does not need to read the specification and
should contain no requirements from a SIP specification.
NEW SPEAKER: That's great.
NEW SPEAKER: We may have to fix a few other words, Henning, to use it, but,
NEW SPEAKER: There's a little bit of text down here about informational. Or
individuals. Of there the packages. That's pretty light.
NEW SPEAKER: I mean, it's only an 01, but we could plan revs between zero and
one, so. Yes.
NEW SPEAKER: Just one last question. Which list is it going to be last call on?
NEW SPEAKER: IETF last call but that will be announced on SIP and SIPPING.
NEW SPEAKER: Okay. Now for an update on the update method. I practiced all day
for that.
NEW SPEAKER: Okay. So, I'm going the talk about the update draft. I'm going to
assume everybody has read it and I'm not going to present it. I'm just going to
talk about the open issues. As far as I can tell, there are really just a couple
minor issues raised. There was I think James sent out an extensive set of
comments, right, James or Joe?
What? Sorry. Okay. So, we got an extensive set of comments but I haven't gone
through all of them. Some are reflected here, but not all of them. The biggest
issue with the silly glare issues. I think that the current update draft only
specifies glare resolution update with itself. You can have glare with PRACK as
it turns out. It is in fact currently going to exist more possible for that to
happen. That happens in the scenario on the left here, right here, when you get
an invite with offer one, with a 183 and answer one, and in response to that,
it's inclined to send another offer for PRACK. But the user agent on the right
can send an offer because it has no outstanding offers in either direction and
those could possibly cross in the water. Not a big deal. We could apply the
current glare resolution to PRACK because you but somebody said that's bad
because you don't want to affect PRACK. We would rather avoid that. So the
proposal was, update should win. No no, it doesn't work. The reason it doesn't
work is because as we went through this before, with re invite, it is possible
to get to a glare condition, these kind of things were one side wins based on a
comparative operation of data. Only work when both sides know they're in a glare
position. And it's see east so for easy to for one side to think there's glare
and the other one not. And so that doesn't work.
The other approach is just to simply add a sentence that says the current glare
mechanism, you just use it. If you hit PRACK, call sell. Something along those
lines. That could cause rejection PRACK. That's bad. The third approach says,
the user agent server can't send an update, if it sent you know exec which has a
government PRACK yet. You effectively don't start the update exchange until the
PRACK is complete. And this is what Gonzala posted on the list. This is what it
said in the first place. It doesn't actually at the moment, I think it should.
So I propose what he said be codified into the spec. I think it's the best
approach. It a voids the problems. Any objections or comment OS that?
NEW SPEAKER: Just a comment. Yes, I, speaking about that, actually, it solves
the glare problem. It doesn't solve the problem of offer for PRACK --
NEW SPEAKER: You can do it. You can refuse the PRACK. Everything will work. So I
think what we need is words in the text that say, listen, the offer in the PRACK
is good. It could cut off some problems, but it has this consequence that you
may get needless transmissions of the provisional response if you do it. So use
it sparingly.
NEW SPEAKER: If we can respond to 4 '88 to a PRACK, I'm happy with that.
NEW SPEAKER: You can. I'm just saying, you generally shouldn't. It's not the
preferred mechanism.
NEW SPEAKER: Sort of a comment on that. It seemed to me like it would be
reasonable to send a 200 okay to the PRACK. But include, you know, a session
description that indicates that you're not willing to accept any of the streams
that were in that offer.
NEW SPEAKER: Sure, if it ends up being no different, then he has to do another
exchange anyway.
(Several people talking.)
NEW SPEAKER: Because then the next thing that you do, as you immediately send an
update to which there is a single response.
NEW SPEAKER: But this E intermediary, the nice thing about rejecting it
outright, is that you maintain the ad miss, if you accept it, you have a brief R
T P where media is --
NEW SPEAKER: Accept except for the, the media is halted anyway,
NEW SPEAKER: We don't want to make those assumptions.
(Several people talking.)
NEW SPEAKER: This exactly, this is a usage and, you know, you should be free to
do all of these things.
NEW SPEAKER: Right.
NEW SPEAKER: And in some of the cases, you know, some of the key example cases
for this mechanism, you know, all of those are all reasonable things to do.
Okay.
NEW SPEAKER: All right. I can answer more, but I'm hesitant about adding text
that says, to recommend strategy to reject with disabling all ports.
NEW SPEAKER: You can do it one sentence, and it's already actually permitted by
operating strategy.
NEW SPEAKER: Of course. It does a lot of things without needing to specify all
them. That's why we made a general purpose tool. So okay, I'll put some words in
there with appropriate caveats. But I think we're closed on this issue.
Okay, good.
Other issues, so there's this list of response codes that I call repairable
response codes. And they have this property that they, the user agent client
could fix them without human intervention. And how you define a repairable error
response. There's a long list of them. One of the comments was what about the 4
'93 decipherable. This is a new response code we've added to BIS, that gets sent
back when you encrypt a body, but it turns out along the way, the request went
somewhere else and hit a user that does not have the key to Dee crypt the body.
They send out a response that says nominee. This is one of these funny headers
where it may require user intervention to fix. A smart application would tell
the user, well, this didn't work, do you want to send this unencrypted. If they
say yes, it could do that.
Another approach would be to automatically re submit the approach unencrypted,
and that has security problems. So, so, I don't know. John?
NEW SPEAKER: Ideally, 4 '93 should contain the public key, so it should send you
back something saying, please re encrypt it with this and send it to me.
NEW SPEAKER: I may not want it that --
NEW SPEAKER: Agree.
(Several people talking.)
NEW SPEAKER: So, understood. Okay. So this is one of these things where, but
then again, my policy of will be that I just want to prevent intermediaries from
seeing it and, and you know, it's a reasonable configuration for my user agent
to check the box that says, always re try without asking me, if that's what you
want. It is a reasonable thing to do. You think it should never do that, never
automatically re try ever? I don't know about that.
If the user wants to do that, anyway, my proposal was to include it, asking that
this actually generally covers response codes which you know, which would be
under the category of you wouldn't automatically re try without prompting from
the user. So anything in this category without me naming all of them, would be
in the list. But you wouldn't re try without asking the user.
Okay. In other words, what we do want to avoid is that I send a one 5 5 and the
user agent says, got to re try that, and it does it, and if it got the 4 '93,
would it? And so I'm going to include text that says, don't do worse than you
would do if you got this error response. But I don't think we can mandate that
you have user intervention for a particular function. It's always possible to
put it on top not to represent your policy. I believe that's true.
So, anyone object to this particular thing or care about it, to make comments?
John, it's okay? Okay.
The last issue I have here, is some of the backwards compatibility stuff, which
I think still requires a little bit more attention. It did change between O O
and 01. It will change a little more. Right now, the spec says that user agent
server may generate a one 5 5 instead of generating a repairable error response.
It doesn't say should or must. It says may. If you wanted to force it, the proxy
inserts a require.
One of the comments is should is better here because you may end up with
situations where if the user agent server supports this capability, the proxy
may not support it. But the proxy may be running a service which would benefit
by sending a one 5 5. The nice thing about this whole solution is that an
existing forking service, running the proxy will just work better if the user
agent service starts doing this.
So, if you make it a should, it will work for proxies that don't understand
update and otherwise explicitly request it. I think that's reasonable so my
proposal was to accept that change.
Any comments on that? Okay. That is I think, it.
NEW SPEAKER: I have one question.
NEW SPEAKER: Yes?
NEW SPEAKER: The thing that was most troubling to me about this was the text
that says that the user agent client should be able to infer what the error is
in one 5 5, and to me, this is just screaming for the reason.
NEW SPEAKER: It is screaming for the reason header.
NEW SPEAKER:
(Several people talking.)
NEW SPEAKER: So, is there some way that --
NEW SPEAKER: Here's what I did. The reason header has a lot more work for this
to happen. We didn't want to put it in wholesale. It wasn't as simple as you
could put any response in there that you would otherwise put in there. There's
all kinds of extra functions, with response codes. This is time sensitive. So
what I basically said is that, I didn't require a reason or call for a reason. I
said, hey, it would be really cool if there were a magical header that could
give you the reason for this happening. Wouldn't that be great.
And if that happens to me, you could use it. So the point is that, for the case,
what's interesting, Bob, is that for the basic cases we're worried about
immediately, you can in fact infer from headers. But not 4 '93 for example. You
need the reason header for that. You got the text in there that hits people on
the head that you should look at that when it comes out without explicitly
referring to it. That's what we did.
NEW SPEAKER: I'm a little worried that it's sort of unnecessarily complicated.
But you know, I would be, I would be okay with doing a, you know, a simple
reason header or something. You know, just slamming, you know, the SIP response
code that you would have sent in that.
NEW SPEAKER: If people want to live with having two separate reason headers, one
specific to this error response and the more generic one, but it seems like
slippery slope to me.
NEW SPEAKER: On the SIP PRACK?
NEW SPEAKER: Actually, the reason, the reason header, also includes these
things, so you can already use it if you want. So you don't need to create
another spec or whatever.
NEW SPEAKER: But the problem is, the reason header is on a slower track.
NEW SPEAKER: I know.
NEW SPEAKER: It's not even on the charter right now.
NEW SPEAKER: We're going to speak about that later.
NEW SPEAKER: But the SIP frag is an interesting idea. It has, Alison is gone
already, right? It has other issues. Is she there?
NEW SPEAKER: No, she's gone.
NEW SPEAKER: Someone is raising their hand but it's not Alison. Laura is here.
Alison?
NEW SPEAKER: No.
NEW SPEAKER: The point is, message SIP route would be great except for another
process issue, which is the pleasure we in doing the line registration. People
want to know about the funny things that happened to have this document to be
delivered on time. Come talk to me. I think we will have some more problems, so,
especially with this one, maybe we can get over this, and maybe we can use
NEW SPEAKER: You have to have SIP refer, unless we change the refer.
NEW SPEAKER: But this is header refer. Let me do it this way. Instead of
figuring out the process, does the group agree that a message or SIP frag is,
would that be the preferred approach.
NEW SPEAKER: To indicate what?
NEW SPEAKER: To indicate the error was in 35 5.
NEW SPEAKER: There are three things, right. Requires that you be able to, you
could require that you need to be able to infer from the, you know, from the
message. You could add a, you know, add a new header, that is the simple reason
header, say. You could wait for the reason header, or you could do, you know,
you could do message to PRACK.
NEW SPEAKER: Or message SIP. Which is over kill but will work.
NEW SPEAKER: Those are the options.
NEW SPEAKER: Well, I'd like the reason headers. And I guess my question is, if
we did simple reason header, what specific reason couldn't we define a reason
header and then in the future add more code that could go --
NEW SPEAKER: The problem is that the reason header draft is separate syntax.
It's more than just the Code and the phrase. It's got like, I don't know, ice so
parameters or something in it. I don't
( Ice so. )
I don't understand it.
NEW SPEAKER: So maybe we do need a simple reason header.
NEW SPEAKER: Jonathan, it has actually one reason code which is the first idea,
for like I'm sending this buy because I want to release a call. Or whatever.
Then you have a vertical identifier. I'm the only thing you define, is SIP
actually and Q A 50 if you want to do anything. Basically you have SIP, the re
send code and phrase. That's all you need.
NEW SPEAKER: But unfortunately, that has nothing to do with -- the problem is,
that document is going to be behind update.
NEW SPEAKER: I know.
NEW SPEAKER: And if you incorporate it into update, verbatim, that might
accelerate it but I don't know if that's what we want to do because we need to
think about the protocol some more.
NEW SPEAKER: We want to be able to use it outside of a context dock.
NEW SPEAKER: It doesn't belong in update. That's why we wanted it outside.
NEW SPEAKER: Can we talk about reason when we talk about reason?
NEW SPEAKER: Yes. That's a reasonable thing to do, Eric.
NEW SPEAKER: Eric, that was totally unreasonable. Anything else? So. I don't
think we have consensus on this. So, I mean,
NEW SPEAKER: How about we revisit this after we do reason?
NEW SPEAKER: How does that help? This is a real practical problem. This thing
needs to go out before the reason header. And I don't want to do a second
header.
NEW SPEAKER: If we don't have a reason header or SIP F R A G. Then I think the
update spec needs to have clear and concise rules as to how the U A C implies --
NEW SPEAKER:
NEW SPEAKER: Does --
(Several people talking.)
NEW SPEAKER: It's not complete like a 4 16.
NEW SPEAKER: I can't do those because there's no header that can --
NEW SPEAKER: Right. Therein lies the problem.
NEW SPEAKER: I understand that's the problem. So it's a process issue more than
anything else. I'll turn to chairs for input.
NEW SPEAKER: Sorry.
NEW SPEAKER: I have a feeling this is going to have to be a work off line.
NEW SPEAKER: Yes.
NEW SPEAKER: I'm not convinced yet that it has to be solved in this draft you
could solve it in the reason code or zip code. I'm not suggesting one 5 5 out.
Just pulling the associated --
NEW SPEAKER: That's what we basically. That's what we've done now. So this draft
will work for those areas responses for which you can further call for headers,
4 01, it won't work for 4 '93. There's a place holder in there that we have a
reason header in there we'll deal with it.
NEW SPEAKER: So a bunch of people didn't understand why it was that way when we
started this discussion. Now we understand. Most people are fine with exam
exactly your current plan. I am anyway.
NEW SPEAKER: Yes. No?
NEW SPEAKER: What about pulling one 5 5 out of this draft?
NEW SPEAKER: All right. That's a fairly radical change in the structure. It's
solving one of the ideas of Unified proposal was that these are all related
problems, updating sessions headers all that stuff that we didn't want to
separate them.
NEW SPEAKER: Yes. The idea would be that there would be like a separate, header
G S R --
NEW SPEAKER: I should have picked a better acronym.
NEW SPEAKER: There would be a separate RF P draft that would, that would
describe how to use update method, that uses the one 5 5, defines the one 5 5
response and to depend on whatever, you know, whatever mechanism we decide to
convey the reason, I mean. I have mixed feelings about it but it seems like, you
know, it should, it's a reasonable option that should be considered at least.
NEW SPEAKER: It would make the draft like three pages, probably.
NEW SPEAKER: That might be good.
NEW SPEAKER: All right. Any comments on that?
NEW SPEAKER: I mean, I must admit, in reading the draft, I was confused by the
co-existence by one 5 5 and the update in the same document. One was taking away
from my understanding of the other. And vice versa. Make it more understandable.
NEW SPEAKER: Okay.
NEW SPEAKER: I think they are right the same draft. I'm happy with having them
together.
NEW SPEAKER: All right. That's not consensus either. So we've actually, I think,
we're going to step backwards, and now we're considering a more broad change.
Any comments? Otherwise, we have to do e-mail and, but if we're going to resolve
it, I need to start on the document right away. Anyone else? Okay. Thank you.
NEW SPEAKER: Okay. Now for the other half of the fight, the mini folks side that
uses update, more or less.
NEW SPEAKER: All right. I'll be presenting the new version of mini volt. As you
know, we have been writing the specification from version O four. Now we are an
offer compliant, and so I'll be describing the draft in one slide and then I'll
present the open issues. The changes we've made, now we are defining actually a
framework for pre condition. Before it was only for service and security.
Actually, the only kind of pre condition we define in the draft is quality of
service. But we have left room for IANA registration and other things like
security and whatever you want to come up with.
The idea in the draft is that we define the current state of the pre condition
and the session
( He talks really fast and he's hard to understand with a Spanish accent. )
NEW SPEAKER: So it's equal or better. We have define of course our global order
so I know always if character stage is there or equal or worse.
And then the other difference we have introduced is the status types. The end to
end status types, is always presenting the early version of many folks and
quality of service or influencing security. We have introduced a new one called
something status type. Which basically means that we have to service the access
networks, so we don't carryly about the back one. So we solve the problem and
you don't have problems in the backbone and the bottle next are in the access
networks.
That was introduced and something four. And you have an example of the syntax we
are using, that means the current status, we are using quality of service pre
conditions, end to end status type and the direction. And the bottom line is
that the discharge status type with the string type, which is mandatory,
optional or no.
So basically, you have the draft, the changes we made. And actually, we've got
an open issue, I been fixes some needs and some small comments I received. This
is a major one. Actually, many folks have other types of pre conditions, like
what happens if I receive a message, which has pre conditions but I don't
understand the type. For example, I introduce a required header saying pre
conditions but this doesn't mean that you have to understand quality of service
or security or other pre conditions. So I don't know if the other supports it.
So we have really two approaches. The first one, if I refuse everything I don't
understand, so if I receive pre condition and receive, and I don't know what pre
condition means, so I refuse it. With the least of pre condition types that I
understand like quality of service, or whatever. But it was brought up by mark
Watson in the mailing list that actually, if I have some kind of pre condition
that I don't understand, but actually it doesn't depend on me. For example, I'm
asking for a pre condition for look out to me. So the user agent can actually
ask for a confirmation and when this pre condition is met, it just goes on with
the session. It doesn't really have to do anything.
So, even if I'm not understanding the pre condition type it might actually work.
At the beginning, I thought really that was a bad idea, but, now I think that it
might be all right. So, there's
NEW SPEAKER: There's another condition where you want to accept the offer, which
is where somebody says, desire foo optional, you know, some, you know,
NEW SPEAKER: Sure, sure.
NEW SPEAKER: I'm talking about manager, yes.
NEW SPEAKER: If you have optional, you don't even care, yes, that's right. I
forgot to say that.
So, does anybody have a strong opinion, like, we should refuse everything we
don't understand? This is, I mean, some people have asked for something like,
stop session establishment, because I won. I don't give any reason, like service
or whatever. And then I will tell when to resume, so that could be a useful
feature for implementing stuff like that.
I don't really know what to do. I would go for option one. But basically, option
two might work still. So, does anybody have an opinion that anybody cares?
Should I do whatever? Shall we toss a coin?
NEW SPEAKER: Vote for option two.
NEW SPEAKER: Yes. Two.
NEW SPEAKER: You can have a thing called crypt something. If you don't
understand it, or ignore and keep going. So you could tell the author what you
want to do. So you could call it, if you don't understand it, call it kill, or
ignore and continue.
NEW SPEAKER: The thing is like, you cannot ignore it. You have a require header.
If you support the option, you cannot really say that you don't do anything.
Okay. I'll decide wherever I want. I will speak to Mark. And we will see what to
do.
All right, this is the second presentation. This is the recent code we were
talking about. I was asked to present some of the requirements, because now the
process you have to go through SIPPING, stating requirements and then coming
here to apply the solution, actually I'm going to explain why we didn't come up
with a requirement draft. And that was because we were working on several
working group items and we found this functionality was missing. And actually we
now want to define in one single document and see if it applies to several ones
so I have in line all the documents that it applies.
Actually, I think it's much cleaner to have a separate specific specification.
So I would like the working group to consider it a working group item. So this
might be useful for eye I S IP. Then ice {sus} full in, because SIP doesn't
allow us to refuse offers that they are appearing in responses. So basically
when I have this kind of response, I usually PRACK or ACK the, with an answer
and I send a by or cancel. So by or cancel should contain this phrase saying, I
couldn't meet the operating conditions or I couldn't accept your offer or
whatever.
So the other end understands I'm not releasing the session just because I don't
want to go on speaking, it was just this other case. It's useful for update. We
work on that now and useful for the transition to S D and D because if I'm
talking to {sar} server and some of them they support SDP I would get an error
response, and I again have to send the request.
So, this is useful for a working group items already and three P cc would be a
working group item, if I'm not mistaken so that's why we think it's a useful
mechanism and soon be a working group item. And this is the format we use in the
draft.
NEW SPEAKER: I'm just not certain if it's because you're talking in the Mike
or you're about ten feet back from it. I just want to throw out another use for
it, that Dave suggested a while back. Which is in the event that you fork a
request to a bunch of phones that somebody owns and one of them picks up, and
then you, proxy generates cancel, the other phone stops ringing, the reason for
the cancel is not because the user hung up, which would generate something in
the call log that said, you know, you got this call but it went unanswered but
it was answered, it was answered by a different connection. So this is a way to
convey that as another --
NEW SPEAKER: Yes. That's fine, thank you.
NEW SPEAKER: So it just occurred to me that there is sort of a lot of overlap
between the requirements which generated this document and the requirements for
request history.
And we all know how well that went over in SIPPING. So,
NEW SPEAKER: Well, there's no --
NEW SPEAKER: There's no identity, there's no any of that. I mean, how, it's like
that, in that this is information?
We have a lot of headers that give information, but I think that's about the end
of it.
NEW SPEAKER: You're providing, you know, the reason for, the reason for a
request failing or the reason for a request successioning is simple cases. Into
Actual
NEW SPEAKER: Actually you are providing why you send the request. I'm sending
the cancel because the other extension picked up.
NEW SPEAKER: And we decided, you know, there was something that was teased
apart, why did the request arrive here. And I'll let Dave give his opinions
there.
NEW SPEAKER: So, like Spanish inquisition, I said we needed to tease things
apart into two things and one is the information going back and the second is
telling somebody why something is happening. And I think on the forward path
here, I think we need to tease two things back, which is you need to separate
why you are sending the request from why you are sending the request to this
party.
And that's, those are actually separate pieces of information. This header does
not necessarily, or shouldn't actually carry any specific semantic as to why a
particular destination U R I is being contacted. Is being sent there. Only why
you are sending this message.
NEW SPEAKER: Well, this is specific for body anyway.
NEW SPEAKER: Let's get everybody else out and --
(Several people talking.)
NEW SPEAKER: The other thing, this may be inter request as opposed to intra
request.
NEW SPEAKER: I'm just wondering if we're all talking about the same sorts of
things here. I just see a list that says, I want to say something negative about
the request RFC, but I've got nothing else. Therefore a new header, everything
else, I don't know what else to put into it, which doesn't seem to be the right
way to define headers. We've already got separate headers that define these
reasons already. In particular, in relation to certain --
NEW SPEAKER: Are you arguing that you don't want to see a generalized header?
You want to see specific reason codes in every message.
NEW SPEAKER: I just have a worry it doesn't seem like the same thing that's been
done in the past. If I don't like a require, I don't support it. I don't put a
reason code, saying, I don't like what you said because of this reason. So,
we're already about three or four headers that do very similar jobs to say
negative things about --
NEW SPEAKER: No, the unsupported header doesn't say the reasoning for, the 4 20
response, you know, code says the reason. The problem is that we need to convey
the information in messages that don't convey in the status line, because it has
to have another status line or it's a request. So, there's no overlap with any
of those things. To me, this is a fairly well constrained well defined problem.
And it's exactly that. To take the information about why a rejection has
occurred and carry a request response that doesn't indicate that in the status
line, I mean, it's that simple.
NEW SPEAKER: I guess my issue with it, and you can correct me. The issue that I
put up on the SIPPING list, was actually not true, you know, everything is hunky
dory with the requirements that Mary put out. Except when you reference this is
H 4 50 all over again. A different reason code and a different whatever, for
every possible application, I mean, I just see this as a big can of worms.
NEW SPEAKER: Don't we have a list of enumerated error responses already in the
SIP spec?
NEW SPEAKER: Yes.
NEW SPEAKER: So? I mean, that's, this is that, plus a few more, that sort of
stem from the fact that we're '76 ing requests, but I don't get it, I mean, what
--
NEW SPEAKER: Well, I see this as a bit more than a few more. I mean, this is
going to be a huge list. Subtle shades of gray.
NEW SPEAKER: So, you know, casually at first glance it's not just, we have one
address space right now for errors, right and we just added one, two, three
more, right, moved to four. It might be -- I'm not against that necessarily, but
it is, it's, you know, that does have a bit of a kitchen sink look to it.
People's first reaction.
NEW SPEAKER: I didn't say it was all there.
(Several people talking.)
NEW SPEAKER: So the main point is, I think that the history, a bunch of the
stuff that was happening with the history requirements does definitely overlap
with what was happening here and we should consider both of them together a
little bit.
NEW SPEAKER: It seems to me, that the motivation was exactly to prevent having
to re in vent a new mechanism each time. This is knots informational in the
sense that, it is helpful but not required to the standard details of every
message that you get. So from that perspective it's not like we're adding newer
roar classes. I could add 700 classes or something like that. From that
perspective, you want actually to have the ability to easely add status code
which don't necessarily, you want to constrained to something which you know
everybody is going to understand the detail of, but you know enough detail, so
there's no information lost. That's why you have the Q A 50 stuff, which most
people don't care unless you need to debug the system. Because it's nice to know
what exactly happened along the way so you don't have to guess which of the ten
conditions triggered the same condition.
NEW SPEAKER: This needs to be covered by the SIP training process as well.
NEW SPEAKER: Oh, yes.
NEW SPEAKER: That's a good question.
NEW SPEAKER: So we're done.
NEW SPEAKER: We're done.
NEW SPEAKER: Okay. Are we done? No. More?
NEW SPEAKER: So can someone help me out and tell me how I get an additional
feedback into brick wise. Because I saw the presentation there the beginning
might be for writ wise which is not completely drafted, but Jonathan said we
have the papers signed for that. But think of the following case. I really want
to know, for example, downstream in a proxy chain, if I don't know that, or if
there might be some additional information, which is used for very practical
things, like bugging. And I would like to see that. Because I just may be see
transport address, but I really do not know what is happening therein that huge
SIP place, so what do you think to be the, to tell me in apply reply, to say
something is going wrong in this half. Or --
NEW SPEAKER: It's the same thing as who generated this error response. That
would be the same thing. You want to know who generated the error response.
NEW SPEAKER: Yes.
NEW SPEAKER: I normally receive a response, so it has nothing to do with that.
You have this problem without using this. I think this is another problem.
NEW SPEAKER: Okay. So, you don't define who, use this for kind of thing like I'm
speaking about?
NEW SPEAKER: We might agree to do it. I mean, at the first glance, I don't think
it's appropriate. But we might --
NEW SPEAKER: I'm just asking that, because I saw in your presentation you were
speaking about replace.
NEW SPEAKER: About replace?
NEW SPEAKER: I think so. Scroll back.
NEW SPEAKER: Sorry.
NEW SPEAKER: Why is this request or response being sent?
NEW SPEAKER: Yes. Why for example, I'm sending a one 5 5, why am I sending that?
Because I cannot unencrypt the message because I need proxy, because I don't
support SDP. Why am I sending the request as Jonathan was saying, because this
proxy was proxy, and the other terminal has picked up so that was what I meant.
NEW SPEAKER: Okay. So, has everybody had their say? All right. So the question I
want to ask is, what do we do at this point? I think we have two possibilities.
One is, we say, we have a crisp set of requirements, that are real clear, and
this is the, this is a reasonable solution to those crisp requirements. Or, we
don't have a crisp set of requirements, that's the first job. I know you guys
want to go and say, hey, this solves my problem. I need a by. But this is truly
something that we really either decide, we've got to put crisp requirements on
and we can go ahead, or in which case, we don't have crisp requirements and it
goes to SIPPING for requirements before we go onto solutions.
So, I hear a lot of discussion about whether this does or doesn't solve the job.
But I'd like to understand whether we understand, if we understand what is the
problem we're solving? He put them up. I mean, that's his statement. Okay. The
question is: Is this good enough set of requirements for this particular problem
to move ahead or is this not good enough, that you have to push back into
SIPPING and generate a requirements document?
NEW SPEAKER: Anybody want to talk on that or just call for a hum? All right.
Those who think that we have a sensible set of requirements and we can move
forward with the solution, based on the draft, give me a hum.
Okay. Those who think we don't have a good enough set of requirements, we have
more requirements work to do before we start talking about solutions, give me a
hum.
NEW SPEAKER: 50/50. Okay. So, to me, anyway, conservative says, do a better
requirements document.
What heart ache does this cause if we delay this for better requirements?
NEW SPEAKER: I really think this is important for update, for session S T P,
transition, I mean, it's important for a bunch of things. If you want I can
write a two-page requirement draft and wait until Japan, right, and we discuss
it?
NEW SPEAKER: No, we don't have to wait. We have a mailing list. We can move
stuff ahead fast and I'm willing to try and push this through fast. But I don't
think we have a clear consensus that we have a requirements document.
Requirements captured right and I'd like to try a little harder to get the
requirements right before we go off and in vent a new piece of SIP. It's clear
that we have some requirements but not enough of them to warrant going ahead.
Dave?
NEW SPEAKER: I'd like to ask for a hum on something slightly different. I
actually have no problem thinking a accounts bit more a little bit more about
the requirements. But there's a break point in requirements, where if we go over
that and add certain set of requirements, this will take years as opposed to
weeks or months. And that is, whether we get involved in requirements that
require identity.
NEW SPEAKER: Yes, and I think we all want to stay away from that.
NEW SPEAKER: If you would like to declare, anything with this reason stuff, that
if it goes over, if we start considering acquire that involve identity, in other
words, being able to communicate why you're sending it to this particular party
or this particular party, is telling you this information,
NEW SPEAKER: Fine.
NEW SPEAKER: If we can declare those requirements out of scope for this work and
allow this this work to go forward only based on requirements for feedback, on
why you're giving the request, irrespective of who you're giving it to, based on
feedback about that, I would be happy to go and spin the requirements once more.
NEW SPEAKER: I think it's authenticated identity that really gets us, anything
that you can prove.
NEW SPEAKER: I'm not interested in unauthenticated identity. So.
NEW SPEAKER: Just say no. We're not doing it. Move on.
NEW SPEAKER:
NEW SPEAKER: I consider that a very reasonable discussion, any problems with
that, as a constraint on this problem? Great. So considered.
NEW SPEAKER: Okay.
NEW SPEAKER: I don't think it matters much, but we're going to get it done fast,
and I'm not going, I think we can get the requirements document out before Japan
and bring the solution back up again before then. And I don't see any reason we
can't. Again, this is the issue about, you know, those of you who hummed against
it, are now bound to go talk about the requirements when we bring them up on the
list. It will be a list discussion. We're not waiting until Japan to settle this
out.
Thank you.
NEW SPEAKER: Can everybody hear me?
I'm talking about SIP extensions for media authorization.
NEW SPEAKER: Raise the microphone.
NEW SPEAKER: How's that?
I'm going to talk about the SIP extensions for media authorization, the draft,
which is now the O four version. From Cisco systems.
Real quick, the overview of changes here, what has happened since O three is
category on the draft is now informational. And as a result of that, the
extension header that's being defined in here has the P dash prefix on it, so
it's now P media authorization.
Also, we have applicability statement, talking about the appropriate use of this
extension. In particular, we go into a bit more detail about the architecture,
and we note that where this can be used is in an environment where you have a
SIP proxy and a policy server that belong to the same domain or you have
cooperation between the domains, but the point is here that the peerless
infrastructure has to be controlled by the same domain or entity as the SIP
proxy is.
Also, the rules about when you add P media authorization, header was updated
slightly. We noted there were some issues that weren't addressed in terms of
unreliable original responses, that got updated. There were forking issues as
well. So the rules hopefully reflect all of that now so both forking and
reliable and unreally able unreliable responses.
The P media header gives you an authorization token that is for authentication
and authorization from the network. So anybody who gets possession of that token
could potentially interfere with your QoS. So that means that if you pass a new
trusted E intermediary s, you are vulnerable to theft service and denial of
service.
Solution to that right now, the mechanisms that we have in SIP is basically to
say, well, don't pass it through untrusted Eintermediary s, because we can't
secure anything from the middle user agent.
Also, we have that proxy maybe to inspect the S T P, in order to actually figure
out what media to authorize, what P O S should be authorized. So if the user
agent starts encrypting the message, the proxy will have trouble doing that
correctly. So don't encrypt the P message in this case.
And then finally, we have various editorial changes.
In terms of open issues, which is what we are supposed to be talking about here,
I'm not aware of anyone. Except for the office list, which needs to be trimmed.
Documents currently working group last call, should expire in a week or so, so
if you have any issues, you know, please raise them now, or real soon.
NEW SPEAKER: It's minor. He flinches every time I get up to the mic.
NEW SPEAKER: It's minor stuff. So, one area that I think deserves a little more
attention is serious considerations, about encryption and authentication. You
know, that's, there's some issues that require specific attention. So one of the
things I thought of while sitting here, I don't think it's a problem but needs
to be discussed. So this token is about media authorization, you are authorized
to have access to the media. Generally, an authorization to do something depends
on knowing who it is you're authorizing to do something. Usually, it follows
authentication.
So obviously there the outgoing side, you want to authenticate the caller before
you pass them back a media authorization token. I don't know if the draft points
out an issue like that.
The other problem is, on the forward side, where the terminating side wants to
send the invite to the U A server, it obviously has not authenticated it at all.
So, how does that work?
NEW SPEAKER: What the extension header does, is provide, essentially uses it as
a transport to provide the authorization for the QoS infrastructure. So it does
talk about authenticating uses, but it does not deal with how do you execute or
actually determine what authorization token should be given to a given user.
NEW SPEAKER: I'm saying, if the this is a token for an authorization for
somebody to do something, you have to know who that somebody is before you give
them the token. Right?
NEW SPEAKER: Not necessarily. The applicability statement might help. It has
coupling between the infrastructure and QoS. So you don't have to be able to
authenticate that particular entity in the QoS infrastructure as long as you can
make the coupling later on. All you need to know is whoever is asking for QoS
has been authorized somehow.
NEW SPEAKER: But I'm saying, you don't know that and you forward it.
NEW SPEAKER: On the far end side.
NEW SPEAKER: On the U A side. They insert the head err to an element which it
has not authenticated.
NEW SPEAKER: You're assuming what we insert is the user agent
(Several people talking.)
NEW SPEAKER: I'm assuming that it inserts a media authorization header as
specified in your draft. And I'm assuming that's going to be inserted or not,
depending on what user you're calling. Right?
NEW SPEAKER: Not necessarily.
NEW SPEAKER: You're going to bill somebody without knowing who they are. I don't
get it.
NEW SPEAKER: Let me explain. Where the calling party is going to be paying for
all the resources that are going to be consumed, which means local and foreign
send and receive. So, there is nothing that talks about that the calling party
has to be authenticated, and based on that, you can send an authorization token.
It simply says here's an authorization token, use this one when you ask for QoS.
That's all.
NEW SPEAKER: Okay. It seems strange to me. You know, I guess I'm asking that
deeper thought be given to that kind of issue and the security consideration
section if that's the answer.
NEW SPEAKER: So, more discussion about authenticating user at the SIP level.
NEW SPEAKER: Exactly.
NEW SPEAKER: I mean, I actually think there's only reasonable answer to this
reasonable answer, is that you can authenticate the registration and that might
be sufficient. I don't know. But, more discussion on that.
NEW SPEAKER: Okay.
NEW SPEAKER: You authenticate, say, the invite and then you can carry that
authentication information all the way to the other, so why would you need to
have something else there?
NEW SPEAKER: I'm sorry. Could you repeat the question?
NEW SPEAKER: I mean, if you want to sort, in your example that you want chart
supporting user, right, so the caller user sends invite. That you authenticate,
and then that authorization information is carried all the way to the
destination. So, what is wrong with that? Why do you need something new for that
service?
NEW SPEAKER: I think we're talking about two different issues here. It sounds
like you're talking about billing for the SIP
NEW SPEAKER: It's a media authorization.
NEW SPEAKER: Let me see if I can respond to that. I think Jonathan is explaining
it. But there was a question that Jonathan just raised about authenticating the
calling party and
(Several people talking.) And
NEW SPEAKER: And the otherwise you end up paying for a call for somebody that
you didn't want to talk to. Right, Jonathan
NEW SPEAKER:
NEW SPEAKER: I'm sorry. I missed that.
NEW SPEAKER: You were talking about authenticating the call party. So you don't
want the invite delivered to the party you didn't want to talk to.
NEW SPEAKER: Another thing that seems weird is that, I guess maybe it's this
trust thing, but if you're saying that the caller, calling party pays, is it the
case that the same proxy is going to insert in the provisional response, or, is
that what you're saying?
NEW SPEAKER: Yes.
NEW SPEAKER: Okay all right. Just say that then. None of that was clear. My view
was there was a terminating thing and it mate not be in a domain from the
calling party, in this case, it would be the one that inserts the head err, it's
going to be in the originating site. )
NEW SPEAKER: They don't have to be the same. The idea is that the calling party
has a proxy server with him, that controls a router, that controls a QoS, for
his portion of the network, similarly on the terminating side.
NEW SPEAKER: Right.
NEW SPEAKER: And the authorization header only carries significance on that
access portion of the network.
NEW SPEAKER: I understand all that.
NEW SPEAKER: So it's not past end to end and not from the originating proxy to
the terminating proxy.
NEW SPEAKER: Okay. Okay.
NEW SPEAKER: But what you are really getting into is the whole billing
arrangement, which this draft does not get into, nor should it. About why is an
entity given an authorization token. All it talks about is it's given a token
for use in QoS requests.
NEW SPEAKER: It strikes me as odd that you're heading up a token to do something
without authenticating or discussing how you might think about that.
NEW SPEAKER: Without knowing who that someone is, you do know who that someone
is. The someone is the person that is placing the call. From the perspective of
this.
NEW SPEAKER: All right. Then just say that.
NEW SPEAKER: I think it's, it can be, I think it's needing more clarification, a
couple extra sentences.
NEW SPEAKER: I'm not asking for a new draft. Just additional text, that's all.
NEW SPEAKER: I thought also, we had discussed off the list, the issue of
handling tokens in general. In SIPPING, at a future date, because there are many
cases that we need to consider here, and we need to take this off the handling
in one fashion and well, rather than having a number of fragmented approaches
for authorization tokens for various purposes, whatever they might be, billing
or patient population or whatever.
NEW SPEAKER: I'd like to comment on that, if it's okay.
I think that the idea was, what I recall from that discussion was that we wanted
to have a general purpose SIP mechanism for authorization tokens. But that, you
know, what this is talking about is really an authorization token in the context
of QoS or usually cops or you know, something like that. And so, it's, it
strikes me as a bit out of scope to, you know, to sort of try and shoe horn our
requirements into that space.
NEW SPEAKER: SIP header drive --
NEW SPEAKER: Do you agree or disagree that we ought to have one approach to
handling tokens.
NEW SPEAKER: No. I think we ought to have one approach in SIP for SIP relevant
tokens and this is not a SIP relevant token. It's an informational header. And
it has to do with, you know, QoS and nina, I think they're different. Just my
opinion.
NEW SPEAKER: Anything else?
NEW SPEAKER: I'm sensing we're about done. I mean, I, the working group last
call is going to get over. Anybody who has issues, raise some more, I don't
know. It's, it fills a need. It's limited. We all know it's got limits. But,
it's been hanging around for a long time without alternatives. I'm inclined to
get it to go.
All right. So, last call will be it. We'll look forward.
NEW SPEAKER: All right. Thanks. Who's next? Ben.
NEW SPEAKER:
NEW SPEAKER: Well, I think I'm last on the agenda. So that means I get 40
minutes, right?
Actually, hopefully, this will be really quick.
NEW SPEAKER: Can't hear you.
NEW SPEAKER: Is there a switch on this? Is that better?
NEW SPEAKER: No.
NEW SPEAKER: How about that?
NEW SPEAKER: Yes.
NEW SPEAKER: Okay. I won't repeat my 40 minute joke for the rest of the room.
I'd like to talk about the message draft, which is the SIP extension for instant
messaging, a whole bunch of illustrious, current status, even though this is an
01 draft, it's actually the fifth version because it's been through two working
groups and a couple of name changes and a couple of revisions from each one of
those. The most recent changes were good. We took some C pin mapping information
out. We updated references, which are not going to happen again, because they're
RFC.
Jonathan mentioned we had a goal to try to get this into the third bundle, C S I
S G. So I need to have the finishing touches quickly. It's also dependency to
simple working group.
Okay. Highlights of the draft, really quick. This is for sending instant
messages, actual instant message in the body of the message. This does not
initiate a dialogue and nothing in the draft whatsoever talks about the
controversial message session, this is not about that.
Oh, I thought we were losing they were heading to the Mike.
Current open issues, there has not been much open issues. I've heard from
Jonathan, and he's co-author so I'm not sure that counts. Other than that, it
needs editorial changes, I'm aware of that. Many of which Jonathan pointed out.
There's some lessons to be learned from the other things that went to RFC, that
we can put in here and maybe avoid turnaround time. We need clarification of
wording and threading and I think those will be a couple of sentences
clarifications.
Anything else? I know that I was asked earlier if this was ready for last call.
I think it needs --
NEW SPEAKER: Can we call it something besides message. That confuses every third
person I talk to.
NEW SPEAKER: I thought about that, but I see how every discussion about re
naming everything seems to go.
NEW SPEAKER: It's a little late for that. It's burned into like windows X P.
NEW SPEAKER: Okay. There was some question earlier about is this ready for last
call. I think it's going to need one more revision, which we should have no
change in substance, but it will be primarily editorial and a couple of
clarifications. Probably make sense to wait for that one last call and I really
hope to have that one out really soon.
NEW SPEAKER: We'll wait until it comes out and presuming that we have got six
working group last calls still running, we'll run it as soon as -- I think it
will go right away, because there are only one or two outright now.
Yes. Everybody okay with that? Consider it done. Look for that working group
last call at your local e-mail list.
NEW SPEAKER: By the way, while we're, we have, we're way ahead. I'm going to, I
should wait until the session with more folks, but let me tell you,
administering this list is no picnic. Eye my latest problem is those of you who
are forwarding, people log, sign onto one group, forward to another, the forward
one goes over quota. The local forwarding site decides sending box of headers is
a bad idea so they send me fraction, O '78 9 is over quota. I love to turn you
off. I don't know who you are. You're forward.
Those of you who have this problem, if I find you, you ain't coming back. I get
these messages, like, you know, a hundred messages a day that somebody is over
quota. Thanks.
Please don't forward unless you make sure you don't run over quota.
NEW SPEAKER: Is this list now like a closed list that --
NEW SPEAKER: Yes. The list is now, only a subscribers can post. Those that don't
get referred to me, for moderation, I try and forward those right away, and if
you have, as you have two times, sent mail from another address, I'm putting it
in an alternate list.
NEW SPEAKER: Yes, because it is very common that I don't want my list mail to
come to my real time --
NEW SPEAKER: I understand.
NEW SPEAKER: That's why the list software that you're using, it should allow to
register the from address differently from the list address. The to address. I
mean, if that software doesn't allow it, it's bad software.
NEW SPEAKER: We need to take it --
NEW SPEAKER: A quick question. The
NEW SPEAKER: The list manager that you're using does allow people to join the
list, and opt out of --
NEW SPEAKER: Yes. There's a no mail option.
NEW SPEAKER: So that's the answer to your question. Take every address you've
got, you can subscribe to the list and set no mail.
NEW SPEAKER: The other solution is that you're asking, you'll find that I'll do
it automatically. There's an also allow to post list, which I maintain. Every
time one of you sends a message from another address, it does get moderated, I
do let it go forward but I take the address and put it in the also allow to post
list. So that only happens once. Okay. Now, I'll tell you that in fact, I let
the approvals go as fast as I can get to them, because I don't want people to be
held up and I don't always go put your address in right away. It depends on what
I'm doing in that moment in time. It gets there eventually. The list is growing,
as far as I know, there's no limit. Not to worry that you might see it delay at
first in time it happens to you.
The amount of spam you may have noticed has gone down considerably.
( Applause. )
NEW SPEAKER: Just don't forward, please. We're done with with the agenda. We
do have some more time. I'm perfectly willing to go. I'm perfectly willing to
stop. But if there are other issues that you'd like to take some time on, we can
entertain a short amount of play time. Oh, good, we'll go home.
We're adjourned.
updated 28 Mar 2002 01:13:04 -0600