<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>AW: Report of Q.5 (mobility) phone conference, December 18th, 200 1</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Mr. Roy,</FONT>
</P>

<P><FONT SIZE=2>since my company actively promoted the Annex G approach I have no problem with it. But H.22x would NOT be a NEW protocol, it would still be H.225.0 annex G (v2, to be precise) if used between border elements. The only "documentation" advantage of a separate recommendation is that for further applications it may be cleaner to use H.22x than H.225.0 annex G. What we ought to avoid is that a further application specifies nearly the same protocol again from scratch.</FONT></P>

<P><FONT SIZE=2>Regards,</FONT>
<BR><FONT SIZE=2>Ernst Horvath </FONT>
</P>

<P><FONT SIZE=2>> -----Ursprüngliche Nachricht-----</FONT>
<BR><FONT SIZE=2>> Von: Roy, Radhika R, ALASO [<A HREF="mailto:rrroy@att.com">mailto:rrroy@att.com</A>]</FONT>
<BR><FONT SIZE=2>> Gesendet am: Freitag, 18. Jänner 2002 17:08</FONT>
<BR><FONT SIZE=2>> An: Horvath Ernst; ITU-SG16@echo.jf.INTEL.COM</FONT>
<BR><FONT SIZE=2>> Cc: Meyer, Greg W</FONT>
<BR><FONT SIZE=2>> Betreff: RE: Report of Q.5 (mobility) phone conference, December 18th,</FONT>
<BR><FONT SIZE=2>> 200 1</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> (I would request Mr. Meyer to send the message to the SG16 </FONT>
<BR><FONT SIZE=2>> reflector ... and thanks to Mr. Meyer. )</FONT>
<BR><FONT SIZE=2>> --------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>> ----------</FONT>
<BR><FONT SIZE=2>>  </FONT>
<BR><FONT SIZE=2>> Hi, Mr. Ernst and All:</FONT>
<BR><FONT SIZE=2>>  </FONT>
<BR><FONT SIZE=2>> We have seen all pros and cons of all arguments.</FONT>
<BR><FONT SIZE=2>>  </FONT>
<BR><FONT SIZE=2>> There are some fundamental problems to develop another NEW </FONT>
<BR><FONT SIZE=2>> protocol like "H.22x" among the BEs.</FONT>
<BR><FONT SIZE=2>>  </FONT>
<BR><FONT SIZE=2>> So, my vote will be for "H.225.0 Annex v2" that will include </FONT>
<BR><FONT SIZE=2>> all mobility features extending H.225.0 Annex G v1.</FONT>
<BR><FONT SIZE=2>>  </FONT>
<BR><FONT SIZE=2>> Best regards,</FONT>
<BR><FONT SIZE=2>>  </FONT>
<BR><FONT SIZE=2>> Radhika R. Roy</FONT>
<BR><FONT SIZE=2>> rrroy@att.com</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: Horvath Ernst [<A HREF="mailto:ernst.horvath@SIEMENS.AT">mailto:ernst.horvath@SIEMENS.AT</A>]</FONT>
<BR><FONT SIZE=2>> Sent: Friday, January 18, 2002 4:02 AM</FONT>
<BR><FONT SIZE=2>> To: ITU-SG16@echo.jf.INTEL.COM</FONT>
<BR><FONT SIZE=2>> Subject: AW: Report of Q.5 (mobility) phone conference, </FONT>
<BR><FONT SIZE=2>> December 18th, 200 1</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> We should really try to stop going in circles and come to a </FONT>
<BR><FONT SIZE=2>> conclusion. </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> These are the facts: </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> 1) For a full year the procedures described in H.MMS.1 have </FONT>
<BR><FONT SIZE=2>> been stable; they referred to H.225.0 Annex G, but that was </FONT>
<BR><FONT SIZE=2>> opposed by some participants in the mobility discussion. This </FONT>
<BR><FONT SIZE=2>> was one reason why mobility work progressed slower than expected. </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> 2) In Dublin we found a compromise which did not change the </FONT>
<BR><FONT SIZE=2>> technical solution, just the form of presentation and </FONT>
<BR><FONT SIZE=2>> documentation: the "protocol kernel" should be lifted out of </FONT>
<BR><FONT SIZE=2>> H.225.0 Annex G and turned into an own recommendation. This </FONT>
<BR><FONT SIZE=2>> would allow different applications to make use of this </FONT>
<BR><FONT SIZE=2>> protocol independently and still maintain the protocol in a </FONT>
<BR><FONT SIZE=2>> single document. One application would be H.225.0 Annex G v2, </FONT>
<BR><FONT SIZE=2>> another one mobility management.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> 3) The effect on H.MMS.1 is probably minimal, just a change </FONT>
<BR><FONT SIZE=2>> of reference. </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> 4) Contrary to Mr. Roy's statement there is absolutely no </FONT>
<BR><FONT SIZE=2>> overlap with H.225.0 Annex G since the protocol specification </FONT>
<BR><FONT SIZE=2>> is removed from Annex G and replaced by a reference to H.22x. </FONT>
<BR><FONT SIZE=2>> The protocol itself is fully backwards compatible with Annex </FONT>
<BR><FONT SIZE=2>> G version 1.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> It is now up to the work group to decide how to proceed, </FONT>
<BR><FONT SIZE=2>> either in the present way with an external protocol </FONT>
<BR><FONT SIZE=2>> specification in H.22x or in the former way with the protocol </FONT>
<BR><FONT SIZE=2>> specification integrated in H.225.0 Annex G. In the latter </FONT>
<BR><FONT SIZE=2>> case Annex G version 2 would have to include some extensions </FONT>
<BR><FONT SIZE=2>> needed by H.MMS.1 and H.235 Annex G.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Whatever the decision will be, H.MMS.1 will hardly be </FONT>
<BR><FONT SIZE=2>> affected. The implications for H.225.0 annex G v2 and H.MMS.0 </FONT>
<BR><FONT SIZE=2>> would be bigger: both of these documents will either simply </FONT>
<BR><FONT SIZE=2>> refer to H.22x or contain their own (yet very similar) </FONT>
<BR><FONT SIZE=2>> protocol specification. </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> In any case, we should try our best to finalize H.MMS.1 in </FONT>
<BR><FONT SIZE=2>> February. This means the protcol must be finalized as well, </FONT>
<BR><FONT SIZE=2>> whether it's H.22x or H.225.0 Annex G v2.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Kind Regards, </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Ernst Horvath </FONT>
<BR><FONT SIZE=2>> Siemens AG </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> > -----Ursprüngliche Nachricht----- </FONT>
<BR><FONT SIZE=2>> > Von: Meyer, Greg W [ <A HREF="mailto:greg.w.meyer@INTEL.COM">mailto:greg.w.meyer@INTEL.COM</A>] </FONT>
<BR><FONT SIZE=2>> > Gesendet am: Freitag, 11. Jänner 2002 21:35 </FONT>
<BR><FONT SIZE=2>> > An: ITU-SG16@echo.jf.INTEL.COM </FONT>
<BR><FONT SIZE=2>> > Betreff: Report of Q.5 (mobility) phone conference, December </FONT>
<BR><FONT SIZE=2>> > 18th, 200 1 </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > -----Original Message----- </FONT>
<BR><FONT SIZE=2>> > From: Roy, Radhika R, ALASO [ <A HREF="mailto:rrroy@att.com">mailto:rrroy@att.com</A>] </FONT>
<BR><FONT SIZE=2>> > Sent: Friday, January 11, 2002 9:02 AM </FONT>
<BR><FONT SIZE=2>> > To: BOUGANT François FTRD/DAC/ISS; ITU-SG16@echo.jf.INTEL.COM </FONT>
<BR><FONT SIZE=2>> > Cc: Meyer, Greg W </FONT>
<BR><FONT SIZE=2>> > Subject: RE: Report of Q.5 (mobility) phone conference, </FONT>
<BR><FONT SIZE=2>> December 18th, </FONT>
<BR><FONT SIZE=2>> > 200 1 </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > (Mr. Greg Meyer: Kindly forward the mail to the SG16 mailing list.) </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Further to my earlier email, I like to add a summary. The </FONT>
<BR><FONT SIZE=2>> > main reason is </FONT>
<BR><FONT SIZE=2>> > that H.22x is almost a duplicate set of H.225.0 Annex G </FONT>
<BR><FONT SIZE=2>> > protocol except few </FONT>
<BR><FONT SIZE=2>> > parameters related to mobility (what can be done through </FONT>
<BR><FONT SIZE=2>> > extending H.225.0 </FONT>
<BR><FONT SIZE=2>> > Annex G). </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Please note that we have developed as modular sets that are </FONT>
<BR><FONT SIZE=2>> > decoupled as </FONT>
<BR><FONT SIZE=2>> > follows: </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > H.225.0 RAS - Pre-call setup (among the terminals, GKs, and GWs) </FONT>
<BR><FONT SIZE=2>> > H.225.0 Q.931 - Call setup (among the terminals, GKs, and GWs) </FONT>
<BR><FONT SIZE=2>> > H.225.0 Annex G - among the BEs </FONT>
<BR><FONT SIZE=2>> > H.245 Call/media control (terminals, media-aware GKs, GWs) </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > The proposed H.22x overlaps completely with H.225.0 Annex G </FONT>
<BR><FONT SIZE=2>> except few </FONT>
<BR><FONT SIZE=2>> > mobility related parameters. Here lies the fundamental confusions. </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Best regards, </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Radhika R. Roy </FONT>
<BR><FONT SIZE=2>> > rrroy@att.com </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > -----Original Message----- </FONT>
<BR><FONT SIZE=2>> > From: Roy, Radhika R, ALASO </FONT>
<BR><FONT SIZE=2>> > Sent: Friday, January 11, 2002 11:42 AM </FONT>
<BR><FONT SIZE=2>> > To: 'BOUGANT François FTRD/DAC/ISS'; ITU-SG16@echo.jf.INTEL.COM </FONT>
<BR><FONT SIZE=2>> > Cc: 'Meyer, Greg W' </FONT>
<BR><FONT SIZE=2>> > Subject: RE: Report of Q.5 (mobility) phone conference, </FONT>
<BR><FONT SIZE=2>> December 18th, </FONT>
<BR><FONT SIZE=2>> > 200 1 </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > (Mr. Greg Meyer: Kindly forward the mail to the SG16 mailing list.) </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Hi, Mr. Francois and All: </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > The fundamental arguments have been that a protocol is </FONT>
<BR><FONT SIZE=2>> > defined with its own </FONT>
<BR><FONT SIZE=2>> > characteristics. For example, H.323 protocol has its own </FONT>
<BR><FONT SIZE=2>> entities like </FONT>
<BR><FONT SIZE=2>> > terminals, GKs, BEs, and GWs. Whatever protocol is used by </FONT>
<BR><FONT SIZE=2>> > these entities </FONT>
<BR><FONT SIZE=2>> > among themselves is known as H.323 protocol suit: For </FONT>
<BR><FONT SIZE=2>> > example, H.225.0 Annex </FONT>
<BR><FONT SIZE=2>> > G among BEs. So, the argument is that whatever protocol is </FONT>
<BR><FONT SIZE=2>> > used among the </FONT>
<BR><FONT SIZE=2>> > BEs is known as H..25.0 Annex G. The question is: How can we </FONT>
<BR><FONT SIZE=2>> > define another </FONT>
<BR><FONT SIZE=2>> > protocol like H.22x among the same BEs of H.323? Is it not </FONT>
<BR><FONT SIZE=2>> > contradictory to </FONT>
<BR><FONT SIZE=2>> > the fundamentals for development of the protocol? Will it </FONT>
<BR><FONT SIZE=2>> not confuse </FONT>
<BR><FONT SIZE=2>> > everything? (An analogy: How can we say that let us develop another </FONT>
<BR><FONT SIZE=2>> > protocol, say, H.ZZZ to be used among terminals, GKs, and GWs </FONT>
<BR><FONT SIZE=2>> > in addition to </FONT>
<BR><FONT SIZE=2>> > H.323?) </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > The solution that we have been discussed among ourselves is </FONT>
<BR><FONT SIZE=2>> > as follows (I am </FONT>
<BR><FONT SIZE=2>> > providing a copy): </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > -------------------------------------------------------------- </FONT>
<BR><FONT SIZE=2>> > -------------- </FONT>
<BR><FONT SIZE=2>> > ------------------------------------------- </FONT>
<BR><FONT SIZE=2>> > 1. We are developing a new protocol where no protocol exists </FONT>
<BR><FONT SIZE=2>> > and the same </FONT>
<BR><FONT SIZE=2>> > can used by all applications to solve the mobility related </FONT>
<BR><FONT SIZE=2>> > problems. For </FONT>
<BR><FONT SIZE=2>> > example, no protocol exits among BE/AMFE, VLF, HLF, and AuF. </FONT>
<BR><FONT SIZE=2>> > Here where we </FONT>
<BR><FONT SIZE=2>> > are defining a new "generic" protocol. This is not specific </FONT>
<BR><FONT SIZE=2>> > to the H.323 </FONT>
<BR><FONT SIZE=2>> > protocol. (Whether VLF, HLF, and AuF will be colocated with </FONT>
<BR><FONT SIZE=2>> > the BE/AMFE is a </FONT>
<BR><FONT SIZE=2>> > matter of implementation.) </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > 2. We have the H.225.0 Annex G protocol that allows us to </FONT>
<BR><FONT SIZE=2>> > communicate among </FONT>
<BR><FONT SIZE=2>> > the H.323 BEs. This is specific to H.323. All we need to do </FONT>
<BR><FONT SIZE=2>> > is to extend </FONT>
<BR><FONT SIZE=2>> > this protocol to serve our purposes. (An analogy can be </FONT>
<BR><FONT SIZE=2>> > provided. It should </FONT>
<BR><FONT SIZE=2>> > be done in a way what Paul Reddy has done for H.xxx Annex E.) </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > 3. We have the H.225.0 (RAS + Q.931) protocol that is used </FONT>
<BR><FONT SIZE=2>> > among the H.323 </FONT>
<BR><FONT SIZE=2>> > Terminals, GKs, and GWs. This is specific to H.323. All we </FONT>
<BR><FONT SIZE=2>> > need to do is to </FONT>
<BR><FONT SIZE=2>> > extend this protocol to serve our purposes. (An analogy can </FONT>
<BR><FONT SIZE=2>> > be provided. It </FONT>
<BR><FONT SIZE=2>> > should be done in a way what Paul Reddy has done for H.xxx </FONT>
<BR><FONT SIZE=2>> Annex E.) </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > The questions that I have to you all: Why do you want to </FONT>
<BR><FONT SIZE=2>> > develop a generic </FONT>
<BR><FONT SIZE=2>> > protocol (if it is not H.323 specific) for items 2 and 3? If </FONT>
<BR><FONT SIZE=2>> > you want to do </FONT>
<BR><FONT SIZE=2>> > so, how do you definite the generic functional entities like </FONT>
<BR><FONT SIZE=2>> > terminals, GKs, </FONT>
<BR><FONT SIZE=2>> > BEs, GWs, etc? (Please also note that H.324 and H.310 do </FONT>
<BR><FONT SIZE=2>> not have the </FONT>
<BR><FONT SIZE=2>> > concept of functional entities like GKs.) </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > My assumption has been that the same (items 2 and 3) can also </FONT>
<BR><FONT SIZE=2>> > be done for </FONT>
<BR><FONT SIZE=2>> > H.324, H.310, or other protocol while all protocols can use </FONT>
<BR><FONT SIZE=2>> the same </FONT>
<BR><FONT SIZE=2>> > "generic" protocol as developed in item 1. </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Please also note that if we develop a "generic" protocol for </FONT>
<BR><FONT SIZE=2>> > items 2 and 3 </FONT>
<BR><FONT SIZE=2>> > instead of being making protocol-specific extension, we will </FONT>
<BR><FONT SIZE=2>> > force each </FONT>
<BR><FONT SIZE=2>> > protocol (H.323, H.324, H.310, etc.) to use the DUPLICATE </FONT>
<BR><FONT SIZE=2>> > sets of protocols </FONT>
<BR><FONT SIZE=2>> > (protocol specific + generic) among all its functional </FONT>
<BR><FONT SIZE=2>> > entities. Is it nor </FONT>
<BR><FONT SIZE=2>> > wastage of resources? </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > -------------------------------------------------------------- </FONT>
<BR><FONT SIZE=2>> > -------------- </FONT>
<BR><FONT SIZE=2>> > ----------------------------------------- </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > It is not that we cannot develop many fency things like </FONT>
<BR><FONT SIZE=2>> H.22x, but it </FONT>
<BR><FONT SIZE=2>> > contradicts the fundamental goals of the protocol development. </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Best regards, </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Radhika R. Roy </FONT>
<BR><FONT SIZE=2>> > rrroy@att.com </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > -----Original Message----- </FONT>
<BR><FONT SIZE=2>> > From: BOUGANT François FTRD/DAC/ISS </FONT>
<BR><FONT SIZE=2>> > [ <A HREF="mailto:francois.bougant@RD.FRANCETELECOM.COM">mailto:francois.bougant@RD.FRANCETELECOM.COM</A>] </FONT>
<BR><FONT SIZE=2>> > Sent: Friday, January 11, 2002 10:32 AM </FONT>
<BR><FONT SIZE=2>> > To: ITU-SG16@echo.jf.INTEL.COM </FONT>
<BR><FONT SIZE=2>> > Subject: Re: Report of Q.5 (mobility) phone conference, </FONT>
<BR><FONT SIZE=2>> December 18th, </FONT>
<BR><FONT SIZE=2>> > 200 1 </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Dear all, </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > During the last rapporteur's meeting (Dublin - Ireland), it </FONT>
<BR><FONT SIZE=2>> > was expressed </FONT>
<BR><FONT SIZE=2>> > that defining H.22x (designed on the basis of H.225 annex G </FONT>
<BR><FONT SIZE=2>> v2 at the </FONT>
<BR><FONT SIZE=2>> > current state - the backward compatibility with H.225 annex G </FONT>
<BR><FONT SIZE=2>> > v1 would be </FONT>
<BR><FONT SIZE=2>> > necessary) as a protocol used on BE--BE and BE--{Backend </FONT>
<BR><FONT SIZE=2>> > service entities} </FONT>
<BR><FONT SIZE=2>> > interfaces (other interfaces implying GKs could be </FONT>
<BR><FONT SIZE=2>> > considered) and stopping </FONT>
<BR><FONT SIZE=2>> > H.225 annex G would be a better way than defining a new </FONT>
<BR><FONT SIZE=2>> > protocol used on </FONT>
<BR><FONT SIZE=2>> > BE--{Backend service entities} interfaces and going on H.225 v2. </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > A significant argument is : in the latter case, the BE would </FONT>
<BR><FONT SIZE=2>> > support two </FONT>
<BR><FONT SIZE=2>> > application-layer protocols that may evolve separatly in the </FONT>
<BR><FONT SIZE=2>> > future. This </FONT>
<BR><FONT SIZE=2>> > would tend to make BE functionalities harder to implement. </FONT>
<BR><FONT SIZE=2>> > A second one is : if the H.22x "body" includes the H.225 </FONT>
<BR><FONT SIZE=2>> > annex G protocol , </FONT>
<BR><FONT SIZE=2>> > it can be used for information exchange on BE--BE interface </FONT>
<BR><FONT SIZE=2>> > even in the </FONT>
<BR><FONT SIZE=2>> > H.323 mobility management context. </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > To my understanding, H.22X would not contain any functional </FONT>
<BR><FONT SIZE=2>> > architecture </FONT>
<BR><FONT SIZE=2>> > description. This would be specifically described in every </FONT>
<BR><FONT SIZE=2>> > H.MMS.x draft, </FONT>
<BR><FONT SIZE=2>> > depending on the application context (H.323 specific, etc.). </FONT>
<BR><FONT SIZE=2>> > To give an </FONT>
<BR><FONT SIZE=2>> > example, the definition of generic entities would be </FONT>
<BR><FONT SIZE=2>> > contained in H.MMS.0. </FONT>
<BR><FONT SIZE=2>> > Specific entities such as GKs would be described in H.MMS.1. </FONT>
<BR><FONT SIZE=2>> > Then, mobility management implies a limited set of </FONT>
<BR><FONT SIZE=2>> > information exchanges </FONT>
<BR><FONT SIZE=2>> > that are independants from the application (although the type </FONT>
<BR><FONT SIZE=2>> > of exchange </FONT>
<BR><FONT SIZE=2>> > data depends on the application). These are related to the </FONT>
<BR><FONT SIZE=2>> > same actions at </FONT>
<BR><FONT SIZE=2>> > least : user registration/deregistration, location update, </FONT>
<BR><FONT SIZE=2>> > authentication, </FONT>
<BR><FONT SIZE=2>> > information update (e.g. user service profile transfer, </FONT>
<BR><FONT SIZE=2>> > update), location </FONT>
<BR><FONT SIZE=2>> > information request. So I think it is possible to define a </FONT>
<BR><FONT SIZE=2>> > "simple" generic </FONT>
<BR><FONT SIZE=2>> > protocol. </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Best regards, </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > François Bougant </FONT>
<BR><FONT SIZE=2>> > France Telecom </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > -----Message d'origine----- </FONT>
<BR><FONT SIZE=2>> > De : Roy, Radhika R, ALASO [ <A HREF="mailto:rrroy@att.com">mailto:rrroy@att.com</A>] </FONT>
<BR><FONT SIZE=2>> > Envoyé : mercredi 9 janvier 2002 16:16 </FONT>
<BR><FONT SIZE=2>> > À : BOUGANT François FTRD/DAC/ISS; ITU-SG16@echo.jf.INTEL.COM </FONT>
<BR><FONT SIZE=2>> > Cc : Meyer, Greg W </FONT>
<BR><FONT SIZE=2>> > Objet : RE: Report of Q.5 (mobility) phone conference, </FONT>
<BR><FONT SIZE=2>> December 18th, </FONT>
<BR><FONT SIZE=2>> > 2001 </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Hi, Mr. Francois and All: </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > In addition, we also had some email correspondences among the </FONT>
<BR><FONT SIZE=2>> > conference </FONT>
<BR><FONT SIZE=2>> > participants and few interested folks including Mr. Jones and </FONT>
<BR><FONT SIZE=2>> > Mr. Reddy. It </FONT>
<BR><FONT SIZE=2>> > has been opined that H.22x is NOT needed because the </FONT>
<BR><FONT SIZE=2>> extensions of the </FONT>
<BR><FONT SIZE=2>> > existing application-specific protocol (e.g., H.225.0 Annex </FONT>
<BR><FONT SIZE=2>> > G) for mobility </FONT>
<BR><FONT SIZE=2>> > will serve the purpose. </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Copies of the emails are enclosed below. </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Best regards, </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > Radhika R. Roy </FONT>
<BR><FONT SIZE=2>> > rrroy@att.com </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > PS: I would highly appreciate if Mr. Greg Meyer would send </FONT>
<BR><FONT SIZE=2>> > the email to the </FONT>
<BR><FONT SIZE=2>> > SG16 reflector as you know that I can receive the mail from </FONT>
<BR><FONT SIZE=2>> > the reflector, </FONT>
<BR><FONT SIZE=2>> > but cannot send it because of problems in filtering. </FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> </FONT>
</P>

</BODY>
</HTML>