Subject: [Sipping] Status of draft-ietf-sipping-toip-04.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 09 Mar 2006 13:26:59 +0200

Hi,

the WGLC on this draft finished a while ago. The authors received a few 
comments, which have been incorporated into this revision of the draft.

We will be requesting the publication of this draft as soon as a few 
formatting problems reported by the authors are resolved (e.g., several 
question mark signs and section number alignment). ID nits complains 
that there are 11 instances of lines with non-ascii characters in the 
document.

Additionally, the 4th paragraph of section 5 says:

" This section (Requirements) informs implementers about WHICH
    requirements the systems and services shall meet. The next section
    (Section 6 Framework Implementation) describes HOW to do it. "

It would be good to clarify that you are referring to "implementers of 
this framework". In a couple of places you talk about "any framework". 
It would be beneficial to only talk about the framework this draft 
defines and, consequently, clarify that the requirements apply to 
implementations of this framework. Adding such clarifications in those 
places should be trivial.

Thanks,

Gonzalo

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Roy, Radhika R." <[email-masked]>
Date: Thu, 9 Mar 2006 09:12:12 -0500

Gonzalo:
 
You are right, and we will be working on this to clarify further as follows
with the revised one as far as possible:

1.	

	Examine whether we can modify the title as "Framework for ToIP
Implementation Requirements."
2.	

	Provide Clear implementation requirements/guidelines of the
Real-Time Text application for the multimedia conferencing application
server.
3.	

	Provide Clear implementation requirements/guidelines for bridging of
the Real-Time Text by the media bridge.
4.	

	Provide Clear implementation requirements/guidelines for
interworking between Real-Time Text and Audio for both point-to-point call.
and multipoint call in the IP network only without mobility. This will
include many possible scenarios: a. Real-Time Text only users (p2p, mpt), b.
Combination of Real-Time Text and Audio users only (p2p, mpt), and c.
Combination of Real-Time Text + Video + Non-Real-Time Data/Applications
users and Audio + Video + Non-Real-Time Data/Applications users (p2p, mpt).
5.	

	Extend item 4 for mobility in IP network (Terminal + User) only.
(Note: It will include Wireless LANs, but not cellular wireless).
6.	

	Extend items 4 and 5 interworking between IP, Wireless LANs, and
cellular wireless networks.
7.	

	Extend item 4 interworking between IP and PSTN network only.
8.	

	Extend item 4 interworking between IP, Wireless LANs, Cellular
Wireless, and PSTN network.
9.	

	Indicate clearly what if implementations of the multimedia
application server and media bridges for items 6, 7, and 8. The locations of
these entities will make differences in implications.
10.	Like streaming audio/video, we also need to write-up the streaming
"Real-Time Text" implementations in IP, Wireless LAN, Cellular, and/or PSTN
networking environments. We have NOT done this yet. It is a NEW item. 

11.	The superfluous write-ups of wireless networking, mobility, and
other need to be focused ONLY on implementation guidelines/requirements.
(Note: People do not want tutorials or some stray descriptions of some
features in this document. If this guidelines are not satisfied, let us drop
all those write-ups.) 

12.	Some overall editorial comments are as follows: 

*	Must focus that ToIP is for all users (users with difficulties +
mainstream users). 

*	Use "Real-Time Text" consistently throughout the document. 

*	Define "Rea-Time Text" bridging with clear terms and focus the
requirements of this clearly because this is a new functional feature of the
media bridge. 

*	Differentiate between "Real-Time Text" bridging and "Non-Real-Time
Data/Text" bridging because they are two different things (NOT the same). 

*	Keep the texts/write-ups consistent for point-to-point calls and
multipoint calls. For multipoint calls, the application server and media
bridge will come into play. 

*	State implementation requirements for multipoint calls with
multimedia in clear terms in all entities without keeping any ambiguities.

Best regards,
Radhika

  _____  

From: [email-masked] on behalf of Gonzalo Camarillo
Sent: Thu 3/9/2006 6:26 AM
To: sipping
Cc: Rohan Mahy; Arnoud van Wijk; Dean Willis
Subject: [Sipping] Status of draft-ietf-sipping-toip-04.txt

Hi, 

Thanks, 

Gonzalo 

<https://www1.ietf.org/mailman/listinfo/sipping>

---

From: "Guido Gybels" <[email-masked]>
Date: Thu, 9 Mar 2006 18:33:44 -0000

Radhika,

I don't know with what authority you speak here, but I certainly strongly disagree with you on a number of issues. As Gonzalo says, we have received *specific* comments after the previous draft version as part of the WGLC process. We have attempted to address these specific issues in this new draft. You seem to suggest we suddenly change the scope, contents,... of this draft. I do not think that is either appropriate or relevant.

Specifically:

1) When you say: <<Examine whether we can modify the title as "Framework for ToIP Implementation Requirements.">>

This is nothing I have seen any of the otyher co-authors agree to. The title was changed between version 3 and 4 to answer the specific comment that was received as part of WGLC that we needed to be more clear about what this draft describes. The question was asked whether or not this draft describes either an implementation framework or a set of requirements. The draft and the title were thus changed to: "Framework for real-time text over IP using SIP" as to remove this ambiguity. Your proposal to now, immediately after we have made that clarification, reintroduce the previous ambiduity is inappropriate, confusing and certainly does not have my support as a co-author. We can see what the other authors say, but I would be greatly surprised if they would now want to revert back to the ambiguity of before.

2) When you say: "Provide Clear implementation requirements/guidelines of the Real-Time Text application for the multimedia conferencing application server."

That has not been part of the scope for this draft at any time. I don't see any argument to suddenly introduce this as a new part of the draft's scope at this stage, after WGLC. You are obviously free to introduce a separate draft on this topic.

3) When you say: "Provide Clear implementation requirements/guidelines for bridging of the Real-Time Text by the media bridge."

That has also not been part of the scope for this draft. I don't see any reason to introduce it at this late stage into the draft. You are obviously free to introduce a separate draft on this topic.

4) When you say: Provide Clear implementation requirements/guidelines for interworking between Real-Time Text and Audio for both point-to-point call. and multipoint call in the IP network only without mobility. This will include many possible scenarios: a. Real-Time Text only users (p2p, mpt), b. Combination of Real-Time Text and Audio users only (p2p, mpt), and c. Combination of Real-Time Text + Video + Non-Real-Time Data/Applications users and Audio + Video + Non-Real-Time Data/Applications users (p2p, mpt).>>

The current draft discusses interworking in a relevant way by outlining where interworking is an issue and what considerations have to be taken. I don't see any reason for suddenly dramatically altering the concept or the scope of the current draft (convoluting more like it) and I am not aware of any of my fellow co-authors requesting this or supporting it.

5) When you say: <<Extend item 4 for mobility in IP network (Terminal + User) only. (Note: It will include Wireless LANs, but not cellular wireless).>>

I do not believe there is any scope for extension of that topic in this draft beyond what is currently covered by it. I am not aware of any of the fellow co-authors making such a suggestion or supporting it.

6) When you say: <<Extend items 4 and 5 interworking between IP, Wireless LANs, and cellular wireless networks.>>

I do not believe there is any scope for extension of that topic in this draft beyond what is currently covered by it. I am not aware of any of the fellow co-authors making such a suggestion or supporting it. This was not raised during WGLC and I do not believe the current draft is lacking anything in this respect. I do not agree any additions should be made.

7) When you say: <<Extend item 4 interworking between IP and PSTN network only.>>

I do not believe there is any scope for extension of that topic in this draft beyond what is currently covered by it. I am not aware of any of the fellow co-authors making such a suggestion or supporting it. This was not raised during WGLC and I do not believe the current draft is lacking anything in this respect. I do not agree any additions should be made.

8) When you say: <<Extend item 4 interworking between IP, Wireless LANs, Cellular Wireless, and PSTN network.>>

I do not believe there is any scope for extension of that topic in this draft beyond what is currently covered by it. I am not aware of any of the fellow co-authors making such a suggestion or supporting it. This was not raised during WGLC and I do not believe the current draft is lacking anything in this respect. I do not agree any additions should be made.

9) When you say: <<Indicate clearly what if implementations of the multimedia application server and media bridges for items 6, 7, and 8. The locations of these entities will make differences in implications. 10.	Like streaming audio/video, we also need to write-up the streaming "Real-Time Text" implementations in IP, Wireless LAN, Cellular, and/or PSTN networking environments. We have NOT done this yet. It is a NEW item.>>

This is out of scope. It could be part of a separate draft. I do anticipate that various additional drafts can be meaningfully written on the topic of ToIP. However, that does not mean that the current draft, with its specific objective of describing a ToIP framework for implementation using SIP+RTP is incomplete or that we should suddenly change the scope of it.

10) When you say: <<The superfluous write-ups of wireless networking, mobility, and other need to be focused ONLY on implementation guidelines/requirements. (Note: People do not want tutorials or some stray descriptions of some  features in this document. If this guidelines are not satisfied, let us drop all those write-ups.)>>

I don't understand this comment. I don't see what is superfluous nor what you propose to change. I have not seen specific comments on this as part of WGLC by you or anyone else. Again, the draft discusses a relevant set of issues that are of importance to implementers. What you think is missing or should be changes, I have no idea.

11) When you say: <<Must focus that ToIP is for all users (users with difficulties + mainstream users).>>

The draft already does this.

12) When you say: <<Use "Real-Time Text" consistently throughout the document.>>

I am not aware of any inconsistency anywhere in the way the draft uses this term. Unless you can suggest a specific location in the draft where specific wording needs to be inserted or changed, I suggest this comment is invalid.

13) When you say: <<Define "Rea-Time Text" bridging with clear terms and focus the requirements of this clearly because this is a new functional feature of the media bridge.>>

IF you want to describe a new feature of the media bridge, you are welcome to publish a draft on that topic.

14) When you say: <<Differentiate between "Real-Time Text" bridging and "Non-Real-Time Data/Text" bridging because they are two different things (NOT the same).>>

I am not sure what this is supposed to mean. The draft describes a ToIP framework. It lists the considerations for making the ToIP framework as described interwork with various other interactive text platforms on other networks and it provides recommendations for interworking with IM. I don't see where there is any lack of clarity, ambiguity or missing definition. Unless you can suggest a specific location in the draft where specific wording needs to be inserted or changed, I suggest this comment is invalid.

15) When you say: <<Keep the texts/write-ups consistent for point-to-point calls and multipoint calls. For multipoint calls, the application server and media bridge will come into play.>>

I don't see what you are suggesting is missing in the draft. I do not believe anything is missing in this respect in this draft. Unless you can suggest a specific location in the draft where specific wording needs to be inserted or changed, I suggest this comment is invalid.

16) When you say: <<State implementation requirements for multipoint calls with multimedia in clear terms in all entities without keeping any ambiguities.>>

I don't see what ambiguity in this draft and within the agreed scope for it you are referring to. Unless you can suggest a specific location in the draft where specific wording needs to be inserted or changed, I suggest this comment is invalid.

Guido

Guido Gybels
Director of New Technologies

RNID, 19-23 Featherstone Street
London EC1Y 8SL, UK
Tel +44(0)207 294 3713
Fax +44(0)207 296 8069  

Want to Hear More?

If you're not hearing as well as you used to, or feel someone near you may be missing out, call 0845 600 55 55 now and take our five-minute telephone hearing check.

For more information visit www.breakingthesoundbarrier.org.uk

*******************************************************************
This email and attachments (if any) must be swept for viruses before opening. Their contents may be confidential or privileged and are intended solely for the named recipient. If you are not the intended recipient and you have received this email in error you must not read or use this email and should notify RNID on: +44 (0) 20 7296 8282.

RNID, Registered Office 19-23 Featherstone Street, London EC1Y 8SL No. 454169 (England, Registered Charity No. 207720)

********************************************************************

---

From: "Guido Gybels" <[email-masked]>
Date: Fri, 10 Mar 2006 08:37:56 -0000

Radhika,

You have EVERY right to supply comments - as much as I have the right to reply to them.

<<The scope has NOT been changed.>>

Correct, the WG did NOT change the scope for the WG item. It seems to me that with your last set of comments YOU suggested changing the scope at this late stage and I used my right to express my opinion that this would be inappropriate.

<<The way the draft has been written it is technically inconsistent.>>

I disagree.

<<The draft itself says two different things: a. Requirements and d. Implementation Framework.>>

It does not. The draft CLEARLY and EXPLICITELY states that it is a framework for implementers. It does highlight what requirements such implementation would satisfy, something that is neither inconsistent, inappropriate nor unprecedented in RFC history. As such, I can only think you must be confused.

<<What is this framework for?>>

>From the draft: "This framework defines a text-based conversational service that is the text equivalent of voice based telephony".

<<What is this requirement for?>>

I don't understand the question. The draft offers a framework for ToIP (see above). It also states what requirements such a framework addresses. Did you actually read it?

<<The draft itself has contradicted.>>

Anybody can state anything. I don't see where there is contradiction. So, therefore, please SHOW me (line number, paragraph,...) WHERE there is contradiction.

<<Where had you been so long when I provided the comments to you all? Are these not the same comments?>>

The fact of commenting does not imply one is right. You have the right and had the opportunity to provide comments, that does not however mean that we have to agree with you.

As I see it, your case is that the ToIP framework should not have been published until all related pieces of work would have been published and included. That is the same as saying that RFC3261 should not have been published until RFC 3524, RFC 3515, RFC 3487 and dozens of other RFCs and drafts had been completed. That is plainly silly.

No one suggested that the ToIP story would be finished after this draft. However, that by itself does not constitute a flaw.

Your thesis seems to be that the draft, with the scope it has as a WG item, is incomplete. I simply disagree. In the end, the WG needs to decide. But I would offer the suggestion that unless you can *demonstrate* where this draft is incomplete in a way that would prevent it from being used for its purpose, the argument about incompleteness has not been backed up by any solid evidence.

I'm not going to waste people's time by reiterating through all the stuff again. It'll be up to the WG to decide how to proceed.

I would suggest Gunnar and Arnoud might be well placed to offer further comments.

Guido

Guido Gybels

Want to Hear More?

---

From: "Roy, Radhika R." <[email-masked]>
Date: Fri, 10 Mar 2006 10:23:57 -0500

Gudio:

You have no right to ask whether I have the "authority" or not. Period.

You are welcome to supply comments and send reply on comments on the draft
as much you can. That's all you can do. Let us continue to do as much as you
like.

By the way, you did not reply any technical comments before while raised to
all including yourself. Now you have come to the IETF list!

It is OK with me because I want that the draft MUST be technically
consistent containing the following: Scope, Implementation requirements, and
the networking environments - a. p2p, b. mpt, c. toip only media, d.
multiple media along with toip, d. ip only, e. ip + LANs, f. ip + pstn, g.
ip + pstn + cellular, f. mobility (user + terminal).

Inline [RRR].

Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of Guido Gybels
Sent: Friday, March 10, 2006 3:38 AM
To: [email-masked]
Subject: RE: [Sipping] RE: Status of draft-ietf-sipping-toip-04.txt

Radhika,

You have EVERY right to supply comments - as much as I have the right to
reply to them.

[RRR] See the reply provided above.

Correct, the WG did NOT change the scope for the WG item. It seems to me
that with your last set of comments YOU suggested changing the scope at this
late stage and I used my right to express my opinion that this would be
inappropriate.

[RRR] As I mentioned before, the draft deal with many things: a. p2p, b.
mpt, c. toip only media, d. multiple media along with toip, d. ip only, e.
ip + LANs, f. ip + pstn, g. ip + pstn + cellular, f. mobility (user +
terminal).

[RRR] The scope for requirements has already been set very specifically. In
addition, the general statement and the title have also stated the
implementation of toip requirements.

I disagree.

[RRR] There is NOTHING to disagree as stated above. The proof is above.

<<The draft itself says two different things: a. Requirements and d.
Implementation Framework.>>

It does not. The draft CLEARLY and EXPLICITELY states that it is a framework
for implementers. It does highlight what requirements such implementation
would satisfy, something that is neither inconsistent, inappropriate nor
unprecedented in RFC history. As such, I can only think you must be
confused.

[RRR] In the above, it has already been shown and proved what the draft is
all about. If those relevant things are not explained, or if those relevant
things are explained incompletely, or those things are explained through
making some stray statements here and there as pointed EXPLICITLY by me all
along, this draft has become technically INCONSISTENT.

[RRR] The only things that you are disguising your arguments as follows: Not
in the Scope, Separate Draft, etc. It will NOT go anywhere.

>From the draft: "This framework defines a text-based conversational service
that is the text equivalent of voice based telephony".

[RRR] Are you sure?

[RRR] In any event, this ToIP application, as explained in the draft, needs
to deal with all relevant requirements in the following environments as
explained above: a. p2p, b. mpt, c. toip only media, d. multiple media along
with toip, d. ip only, e. ip + LANs, f. ip + pstn, g. ip + pstn + cellular,
f. mobility (user + terminal).

[RRR] The draft did NOT deal with appropriately as explained before.

I don't understand the question. The draft offers a framework for ToIP (see
above). It also states what requirements such a framework addresses. Did you
actually read it?

[RRR] That is, this framework needs to address those as stated above.

Anybody can state anything. I don't see where there is contradiction. So,
therefore, please SHOW me (line number, paragraph,...) WHERE there is
contradiction.

[RRR] It is a contradiction because the scope, framework, and description of
the draft deals with a. p2p, b. mpt, c. toip only media, d. multiple media
along with toip, d. ip only, e. ip + LANs, f. ip + pstn, g. ip + pstn +
cellular, f. mobility (user + terminal). But the implementation requirements
do NOT explain all the relevant points of those as I have mentioned.

<<Where had you been so long when I provided the comments to you all? Are
these not the same comments?>>

The fact of commenting does not imply one is right. You have the right and
had the opportunity to provide comments, that does not however mean that we
have to agree with you.

[RRR] It has been a part of the all discussions, and the draft was NOT to be
submitted. When I raised the questions why the draft has been submitted, it
was told that it is a draft with work-in-progress. That does not mean that
you disagreed with me or others. So, it was part of my on-going job to
assure the IETF folks that this work is INCOMPLETE.

[RRR] Oh, you have every right to discuss anywhere either in the IETF or any
other forums. I welcome this. The only regret that I have that you did not
raise those concerns before as you are doing now. 

As I see it, your case is that the ToIP framework should not have been
published until all related pieces of work would have been published and
included. That is the same as saying that RFC3261 should not have been
published until RFC 3524, RFC 3515, RFC 3487 and dozens of other RFCs and
drafts had been completed. That is plainly silly.

[RRR] This draft needs to live with its own obligations: Scope,
Implementation requirements, and the networking environments: a. p2p, b.
mpt, c. toip only media, d. multiple media along with toip, d. ip only, e.
ip + LANs, f. ip + pstn, g. ip + pstn + cellular, f. mobility (user +
terminal).

[RRR] No one is saying that the draft needs to wait for all other things.
All is being said that this draft needs to complete its unfinished job.

No one suggested that the ToIP story would be finished after this draft.
However, that by itself does not constitute a flaw.

[RRR] The draft just needs to complete its unfinished job: Scope,
Implementation requirements, and the networking environments: a. p2p, b.
mpt, c. toip only media, d. multiple media along with toip, d. ip only, e.
ip + LANs, f. ip + pstn, g. ip + pstn + cellular, f. mobility (user +
terminal).

Your thesis seems to be that the draft, with the scope it has as a WG item,
is incomplete. I simply disagree. In the end, the WG needs to decide. But I
would offer the suggestion that unless you can *demonstrate* where this
draft is incomplete in a way that would prevent it from being used for its
purpose, the argument about incompleteness has not been backed up by any
solid evidence.

[RRR] Are you saying it is the final draft as it is now? Are you forgetting
all the discussions that we had? Did people not say that it is good to send
this INCOMPLETE draft to show some progress?

[RRR] First of all, you are misleading all because this draft was sent as
work-in-progress, NOT as a final one.

[RRR] The draft is INOMPLETE as explained above.

I'm not going to waste people's time by reiterating through all the stuff
again. It'll be up to the WG to decide how to proceed.

[RRR] It is good. You did not respond before while the comments were sent to
all including yourself. I ma surprised that you NOW spending so time
unnecessarily.

I would suggest Gunnar and Arnoud might be well placed to offer further
comments.

[RRR] Oh, sure! 

[RRR] Gunnar is the person who advocated to send the INCOMPLETE draft as
work-in-progress. So, he knows what we are after.

[RRR] As mentioned before, Arnoud and I exchanged emails. He is working on
this.

Guido

Guido Gybels

London EC1Y 8SL, UK

Tel +44(0)207 294 3713

Fax +44(0)207 296 8069 

Want to Hear More?

If you're not hearing as well as you used to, or feel someone near you may
be missing out, call 0845 600 55 55 now and take our five-minute telephone
hearing check.

This email and attachments (if any) must be swept for viruses before
opening. Their contents may be confidential or privileged and are intended
solely for the named recipient. If you are not the intended recipient and
you have received this email in error you must not read or use this email
and should notify RNID on: +44 (0) 20 7296 8282.

RNID, Registered Office 19-23 Featherstone Street, London EC1Y 8SL No.
454169 (England, Registered Charity No. 207720)

---

From: "Roy, Radhika R." <[email-masked]>
Date: Fri, 10 Mar 2006 15:51:49 -0500

Arnoud:
 
You have touched couple of good points, but still it falls short off what I
have been saying all along. Few points are as follows:

1.	

	I am NOT talking about future drafts at all. I clearly know what I
have to do in the future drafts as I started this one in the beginning both
as editor and co-author. I would not wait for anyone to do those if I have
time.
2.	

	We  agreed that the draft you have sent is INCOMPLETE and it was
sent, as Gunnar explained, it is a work-in-progress.
3.	

	What I am saying to complete the work-in-progress part. That is all
about. It is nothing to do with Rome that was not in a day. It is common
technical sense that the draft has to live with its implementation
requirements. As it was hurriedly sent all on a sudden to show as
work-in-progress, the remaining technical issues need to be completed, and
it is the framework of the implementation requirements for which the draft
has set the stage (a. p2p, b. mpt, c. toip only media, d. multiple media
along with toip, d. ip only, e. ip + LANs, f. ip + pstn, g. ip + pstn +
cellular, f. mobility [user + terminal]) .
4.	

	Are you saying the draft is COMPLETE as it stands NOW?

Best regards,
Radhika

  _____  

From: Arnoud van Wijk [mailto:[email-masked]]
Sent: Fri 3/10/2006 12:54 PM
To: Roy, Radhika R.; Guido Gybels; [email-masked]
Subject: RE: [Sipping] RE: Status of draft-ietf-sipping-toip-04.txt

I aplogize for this "Barfight".

And for scaring bartender Dean. :-)

This draft will show ToIP:

1.	It is just as normal and easy to implement as VoIP and Video-overIP.
That Text-over-IP is nothing exotic. If fact, when a network is fully SIP
and RTP compatible, ToIP must just be possible as VoIP is. Just know that
VoIP is not the only thing here. That is one thing. 

2.	Because ToIP is also an excellent medium for people to use it as
REPLACEMENT of voice, we added requirements to ensure that ToIP will stay
that way. 

3.	ToIP is for a number of people a bit strange, we are all used to
text as email or Instant Messaging and even the stuff you see printed on
your newspaper. The idea of having text streaming in real-time scares a
number of people. But it is not so scary at all. It is the lightest media of
the trio Voice, video and real-time text. But due the streaming and
real-time text..it behaves differently from what you are used to with
IM/Email/IRC/etc. 

4.	Attention goes to transcoding of ToIP when interworking with other
networks that do not use SIP/RTP. For the PSTN, we explain in detail since
we want to ensure that the hearing and speech impaired are conected to ToIP.
Even that ToIP mainstream is and suitable for everybody when voice is not so
appropriate to use. Going into depth describing call flows etc is out of
scope for this draft. Just that if SIP/RTP stops, it does not mean there is
no more real-time text on the different network. 

In separate future followup drafts we will go into details transcoding and
ToIP with usecases, call flows and deeper details.

Where we will highlight PSTN -IP

And Conferencing with ToIP

And Transcoding/ text relay gateways. Including how such text gateways
interconnect and use ToIP to ensure full interworking between the different
networks.

Emergency calls etc

It is possible that some of those future followup drafts will be in a
different working group the SIPPING WG. But this draft is the steady link to
refer to/from

I have been communicating with Radhika, and he disagrees with this version.
I did look at his arguments and points. Some of his feedback has been used
to clarify the draft. Which is great.

We did not plan a big overhaul, since WGLC is already over. And the feedback
from you as WG has been implemented. 

His other points will be covered in future drafts. And I encourage Radhika
to write down his points, and we will then place them in the suitable future
draft. Or he can start on a draft himself. 

Rome is not build in 1 day, and even I would love to build Rome in 1 day,
but sometimes it is better to begin with the Senate building and then build
the connecting districts. If you just have Rome fully in 1 day, Rome would
still not be build!

We have seen at least that there is a lot of passion in Real-time text/ToIP.
:-)

Greetz

Arnoud van Wijk

---

From: "Guido Gybels" <[email-masked]>
Date: Sat, 11 Mar 2006 11:56:43 -0000

Radhika,

Your statement that all of us agreed, where "us" I assume means "the authors" is simply incorrect. In fact, all of us except yourself agreed that this draft was ready for publication within its scope. Arnoud specifically asked all of us that and all the responses to that question apart from yours were that it was. I have noticed that what is written and what you read is most of the time not the same, but I thought this clarification to be useful, if not for you then at least for the WG.

As we said in previous private discussions and as Arnoud has repeated on the mailing list, we are all quite convinced that more drafts can follow describing other aspects relating to ToIP. This is exactlty the same with SIP itself. I'll say again that what you suggest would be equivalent to having one single document encompassing all RFCs and drafts in the SIP and SIPPING arenas. While certainly a novel approach to standardisation, I would suggest it might not be the most practical way of doing things.

For the benefit of the discussion, I also note that you failed to provide the requested specific references to back up your claims that this draft contradicts itself or is incomplete within its agreed scope. As such, I therefore postulate that the draft is both complete and consistent.

And now, if bartender Dean could please give me one of those nice, big pints of excellent lager, please!?

Guido

Want to Hear More?

---

From: "Roy, Radhika R." <[email-masked]>
Date: Sat, 11 Mar 2006 14:08:58 -0500

Hi, all:
 
The draft is NOT complete. It has to take care of the following comments:

1.	

Best regards,
Radhika
 
PS: The editor has taken unauthorized step through the sending draft without
taking care of those comments. It is is seriuosly doubted whether the edito
is working in good faith. I have all the copies of "internal" emails that
will prove it. Moreover, IETF is obliged to take of techniocal comments at
all stages: WGLC, IESG, and even after publishing the RFC. For example,
people even modify the published RFCs.

  _____  

From: Arnoud van Wijk [mailto:[email-masked]]
Sent: Sat 3/11/2006 5:31 AM
To: Gunnar Hellstrom; Roy, Radhika R.; [email-masked]
Subject: RE: [Sipping] RE: Status of draft-ietf-sipping-toip-04.txt

Hello, 
And yes, this draft is complete for the scope and means set in the SIPPING 
WG. 

Greetz 

Arnoud van Wijk 

> From: Gunnar Hellstrom [mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: zaterdag 11 maart 2006 8:14 
> To: Roy, Radhika R.; [email-masked] 
> Radhika and all, 
> The main WGLC comment was that it was unclear if the draft intended to 
> point 
> at required protocol additions or state user requirements. 
> 
> We have made an effort to clear that issue. We are just pointing at how to

> use existing mechanisms to include real time text in the general SIP 
> environment, and how to solve the specific interoperability issues with 
> real 
> time text in other networks. We also have separated user requirements from

> solutions. The draft is a profiling document, isolating a set of user 
> requirements and pointing at mechanisms to use for solving them in a 
> harmonized way, so that interoperability is maximised. 
> 
> We have not been requested to mention p2p or mobility, and we do not need 
> to 
> do it in this draft. From now on I expect all sipping authors to bring in 
> real-time text in the media examples in their drafts. Once you are in the 
> SIP environment, real-time text is just one medium among others. 
> 
> We made extensive rewording, so I just think that the draft needs a 
> thorough 
> review to check if we covered the WGLC comments properly. 
> 
> We will surely touch the text medium again in other drafts, but let us get

> this finalized without bringing in new topics that can be covered better 
> in 
> joint SIP-related specifications. 
> 
> Gunnar 
> 
> --------------------------------------------------------------------------

> -- 
> - 
> Gunnar Hellström, Omnitor 
> 
> 
> --- 
> 
> 
> Arnoud: 
>

---

From: "Roy, Radhika R." <[email-masked]>
Date: Sat, 11 Mar 2006 14:09:11 -0500

Hi, all:
 
I do not feel to reply this email because it has been addressed to Arnoud's
email.
 
BR/Radhika

  _____  

From: [email-masked] on behalf of Guido Gybels
Sent: Sat 3/11/2006 6:56 AM
To: [email-masked]
Subject: RE: [Sipping] RE: Status of draft-ietf-sipping-toip-04.txt

Radhika, 

Your statement that all of us agreed, where "us" I assume means "the
authors" is simply incorrect. In fact, all of us except yourself agreed that
this draft was ready for publication within its scope. Arnoud specifically
asked all of us that and all the responses to that question apart from yours
were that it was. I have noticed that what is written and what you read is
most of the time not the same, but I thought this clarification to be
useful, if not for you then at least for the WG.

As we said in previous private discussions and as Arnoud has repeated on the
mailing list, we are all quite convinced that more drafts can follow
describing other aspects relating to ToIP. This is exactlty the same with
SIP itself. I'll say again that what you suggest would be equivalent to
having one single document encompassing all RFCs and drafts in the SIP and
SIPPING arenas. While certainly a novel approach to standardisation, I would
suggest it might not be the most practical way of doing things.

For the benefit of the discussion, I also note that you failed to provide
the requested specific references to back up your claims that this draft
contradicts itself or is incomplete within its agreed scope. As such, I
therefore postulate that the draft is both complete and consistent.

And now, if bartender Dean could please give me one of those nice, big pints
of excellent lager, please!? 

Guido 

Want to Hear More?

---

From: "Guido Gybels" <[email-masked]>
Date: Sun, 12 Mar 2006 08:53:17 -0000

Radhika,

<<PS: The editor has taken unauthorized step through the sending draft without
taking care of those comments. It is is seriuosly doubted whether the edito
is working in good faith. I have all the copies of "internal" emails that
will prove it.>>

You REALLY need to get off those pills, man!

Seriously, don't dig yourself a bigger hole, comments like these are outrageous, so retain some dignity please.

OK, that's it, I'm stopping feeding the troll.

Guido

Want to Hear More?

---

From: "Roy, Radhika R." <[email-masked]>
Date: Sun, 12 Mar 2006 08:49:29 -0500

Guido:
 
No one should say the draft is COMPLETE while it was told that the draft is
INCOMPLETE defying all the things that had happened. It creates doubt about
integrity.
 
Radhika
 
  _____  

From: [email-masked] on behalf of Guido Gybels
Sent: Sun 3/12/2006 3:53 AM
To: [email-masked]
Subject: [Sipping] RE: Status of draft-ietf-sipping-toip-04.txt

Radhika, 

<<PS: The editor has taken unauthorized step through the sending draft
without 
taking care of those comments. It is is seriuosly doubted whether the edito 
is working in good faith. I have all the copies of "internal" emails that 
will prove it.>> 

Seriously, don't dig yourself a bigger hole, comments like these are
outrageous, so retain some dignity please. 

Guido 

Want to Hear More?

---

From: "Roy, Radhika R." <[email-masked]>
Date: Mon, 13 Mar 2006 11:50:43 -0500

Lawrence:

Oh, sure! I do. That's what I like to do. Something that I disagree with,
why I should be a part of it?

In any event, the technical comments are there before the WG to make it
better and technical consistent. Now, it is up to the WG.

Best regards,

Radhika

Hi Tom, folks,
As always, Tom has a sensible solution. I second the suggestion.
If there are areas Radhika doesn't think have been covered, he is
free to write his own draft covering them, with whomever he chooses.
(That's what I do, and everyone else does - that's what drafts are for :).
Please, no more - This train has left the station.
all the best,
Lawrence

On 12 Mar 2006, at 20:54, Tom-PT Taylor wrote: 

I have a serious suggestion to end this silly discussion. Why don't you
remove yourself as author and write the document you believe should be
written? AFAIK this isn't really your area of expertise, but if you have
some important ideas to contribute, don't hobble yourself with co-authors
who have differing views.

Roy, Radhika R. wrote: 

...