Try out our Premium Member services: Virtual Legal Assistant, Query Alert Service and an ad-free experience. Free for one month and pay only if you like it.
REPORTABLE IN THE SUPREME COURT OF INDIA CIVIL APPELLATE/ORIGINAL JURISDICTION CIVIL APPEAL NO. 2284 OF 2010 (Arising out of SLP(C) No. 7101 of 2009) M. Nizamudeen ...Appellant Versus M/s. Chemplast Sanmar Limited and Others ...Respondents WITH W.P. (Civil) No. 130 OF 2009 WITH T.P. (Civil) Nos. 365-367 OF 2009 JUDGEMENT
R.M. Lodha, J.
Leave granted in SLP (Civil) No. 7101 of 2009.
2. In this group of five matters before us, civil appeal is directed against the judgment of Madras High Court passed on October 31, 2008 whereby a writ petition in the nature of Public Interest Litigation (PIL) filed by the appellant - M. Nizamudeen - has been dismissed. Out of the other four matters; one is a writ petition being W.P. (C) No. 130 of 2009 preferred directly before this Court under Article 32 of the Constitution while the other three matters are transfer petitions seeking transfer of Writ Petition nos. 37043 of 2006, 8125 of 2007 and 23122 of 2007 filed before the Madras High Court.
3. M/s. Chemplast Sanmar Limited (for short, `Chemplast') proposed to set up a project for manufacturing Poly-Vinyl Chloride (PVC) at Semmankuppam village, SIPCOT Industrial Complex, Phase-II, Cuddalore District (Tamil Nadu). An Environmental Impact Assessment Report (EIA) as well as Risk Analysis Report (RA) for the proposed PVC project was obtained by Chemplast and, then, they made proposal (vide application dated May 27, 2002) to the concerned authorities for setting up the said project. The feasibility of the project was considered by public hearing panel in the meeting held on June 7, 2002. The proposal of Chemplast was sent by the government of Tamil Nadu with its recommendations, after 2 accepting the conditional consent issued by Tamil Nadu Pollution Control Board (for short `TNPCB'), to the Ministry of Environment and Forests, Government of India (for short, `MOEF'). The MOEF examined the proposal submitted by the Chemplast in light of the questionnaire, EIA, RA and other relevant documents and accorded environmental clearance to the project proposed by Chemplast on November 28, 2005 subject to strict compliance to the specific and general conditions laid down therein.
4. One of the raw-materials for manufacturing PVC is Vinyl Chloride Monomer (VCM). VCM is not available indigenously and Chemplast planned to import the said raw- material for their plant use from international suppliers. Chemplast in their proposal also proposed to install a Marine Terminal Facility (for short, `MTF') near the seashore at Chitrapettai Village for receiving and transferring VCM from the ships to the PVC plant through underground pipeline.
5. The District Coastal Zone Management Committee in its meeting held on June 7, 2005 considered the proposal of Chemplast for setting up of MTF including the conveyance 3 mains and resolved to recommend to the Tamil Nadu State Coastal Zone Management Authority (TNSCZMA) to consider in principle clearance for the following facilities:
"01. Laying of pipe lines for the transportation of Vinyl Chloride Monomer (VCM) as permitted vide Ministry of Environment and Forests, Coastal Regulation Zone Notification dated 19th February 1991 In paragraph 2 (Prohibited Activities), in sub paragraph (ii) with proviso "except transfer of hazardous substances from ships to ports terminals and refineries and vice-versa In the port areas".
02. Treated effluent lines and sea water intake and return lines as permitted vide Ministry of Environment and Forests, Costal Regulation Zone Notification dated 19th February 1991 in paragraph 2 (Prohibited Activities) in sub paragraph
(xii) with proviso "except facilities for carrying treated effluents and waste water discharges into the sea, facilities for carrying sea water for cooling purposes, oil, gas and similar pipelines and facilities essential for activities permitted under this Notification'.
03. Constructions for jetty activities and control room as permitted vide Ministry of Environment and Forests, Coastal Regulation Zone Notification dated 19th February 1991 in paragraph 3 (Regulation of Permissible Activities) in sub paragraph 2 of (ii) with proviso "operational constructions for ports and harbours and light houses and constructions for activities such as jetties, wharves, quays and slipways'."
6. The aforesaid recommendations were considered by the TNSCZMA and they resolved in its meeting held on October 17, 2005 to recommend to the state government to 4 forward the proposal to the MOEF for the issue of CRZ clearance to Chemplast with the following conditions :
"1. The unit shall comply safety measures stipulated by the Navigational Safety in Ports Committee (NSPC), Goa and shall obtain the clearance from NSPC before Commissioning of the jetty.
2. The unit shall inform in advance to the Assistant Director of Fisheries Department, Cuddalore as and when the loading and unloading of VCM is done from the ship.
3. The unit shall obtain NOC from the Tamil Nadu Pollution Control Board before commissioning of the jetty and the unit shall comply with the norms prescribed by the Tamil Nadu Pollution Control Board from time to time.
4. The unit shall submit the Disaster Management Plan to the District Authorities before commissioning of the jetty.
5. The Unit shall transport and dispose the treated effluent and R.O rejects of the Desalination Plant by conducting Hydrological study through National Institute of Ocean Technology/National Institute of Oceanography.
6. The Unit shall install double walled pipeline in a concrete trench for the transport of VCM from the Jetty to the Plant.
7. The Unit shall install Emergency shutdown valves in the Jetty and leak detection system in the onshore pipeline.
8. The unit shall install adequate fire fighting equipment to encounter any eventuality due to fire.
9. The unit's marine activity shall not give any hindrance to the public as well as to the aquatic life.
10. The unit shall provide and operate sufficient Navigational lighting Indication system during the night hours,
11. The waste water after treatment in the effluent treatment plant should not be discharged into the sea."5
7. Pursuant thereto, the Director, Department of Environment, Government of Tamil Nadu considered the resolution dated October 17, 2005 of the TNSCZMA and forwarded the proposal to the state government by his communication dated October 28, 2005.
8. The government of Tamil Nadu by its communication dated November 9, 2005 informed the National Coastal Zone Management Authority its acceptance of the recommendation made by the TNSCZMA and recommended the proposal of Chemplast seeking environmental clearance for setting up of MTF. Along with its communication dated November 9, 2005, the state government sent, inter-alia :
(i) questionnaire for environmental appraisal for MTF (ii) EIA prepared by LT Ramboll; (iii) RA prepared by LT Ramboll; and
(iv) minutes of the 34th meeting of the TNSCZMA held on 17.10.2005.
9. Chemplast submitted further application to the MOEF on November 14, 2005. The MOEF, then, considered the proposal involving the activities namely, (i) construction of island jetty at 1000 meters from the shoreline; (ii) laying of 6 sub-sea pipelines from jetty to landfall point; (iii) construction of port office with communication facilities; and (iv) laying of onshore piping from landfall point to the CRZ area and thereon to the plant. The MOEF took into consideration, inter alia, that the MTF will be located offshore of Chitrapettai village; that the landfall point will be at Chitrapettai village, which is 2500 meters from the PVC plant; that the total length of the pipelines onshore will be 3500 meters; that the offshore pipelines and the onshore pipelines will be laid in a covered RCC trench; that the island jetty would be consisting of an operating platform, berthing dolphins, mooring dolphins and interconnecting walkway; that the platform and dolphins will be RCC structures suitable for open sea marine service; that sub sea pipelines will be laid with proper insulation and mechanical protection; that piping design would also take into effect stresses arising out of risers, temperature variation, buckling, buoyancy and sea bed erosion. In the backdrop of aforesaid facts and aspects, the MOEF granted environmental clearance on December 19, 2005 under the provisions of Coastal Regulation Zone Notification, 1991 (for short, `1991 Notification') as amended from time to 7 time for construction of revetment for setting up of MTF on the specific and general conditions set out therein including all the conditions stipulated by the government of Tamil Nadu in the letter dated November 9, 2005 and recommendations of the TNSCZMA.
10. The environmental clearance dated December 19, 2005 granted by the MOEF clarified that the stipulations/conditions set out therein will be enforced among others under the Water (Prevention and Control of Pollution) Act, 1974, Air (Prevention and Control of Pollution) Act, 1981, Environment (Protection) Act, 1986, the Hazardous Chemicals (Manufacture, Storage and Import) Rules, 1989, the 1991 Notification and its subsequent amendments and the Public Liability Insurance Act, 1991 and the Rules made thereunder. Chemplast was also directed to ensure that the proposal complies with the provisions of the approved Coastal Zone Management Plan of Tamil Nadu, 1996 (for short, `1996 Plan').
11. The TNPCB in light of the environmental clearance dated December 19, 2005 granted by the MOEF accorded its 8 consent on September 14, 2006 for the PVC plant as well as MTF and pipeline project of the Chemplast.
12. Chemplast made an application on February 6, 2008 to the Executive Engineer, PWD, Vellar Basin Division, WRO, Vridhachalam (for short, `Executive Engineer') seeking permission for carrying seawater and raw-materials through pipelines laid 3.50 meter below the river bed. The Executive Engineer granted permission on February 27, 2008 subject to the conditions set out therein. In less than a month on March 19, 2008, the Executive Engineer, cancelled the aforesaid permission observing that VCM may cause pollution and health hazard to the public.
13. The order cancelling permission was challenged by Chemplast by filing writ petition before the High Court of Judicature at Madras. The High Court allowed writ petition on July 18, 2008 and set aside the order of the Executive Engineer passed on March 19, 2008 revoking the permission granted on February 27, 2008. It was then that the appellant - M. Nizamudeen - filed PIL before the Madras High Court praying therein that the order passed by the Executive Engineer on 9 February 27, 2008 be quashed and Chemplast be directed to forebear from laying of pipelines for drawing VCM raw-material from jetty to their plant in Semmankuppam village. In the writ petition, M. Nizamudeen did not challenge environmental clearances granted by MOEF on November 28, 2005 and December 19, 2005. The High Court, vide its Judgment dated October 31, 2008, dismissed the writ petition which is subject matter of challenge in the civil appeal.
14. It appears that after Petition for Special Leave to Appeal challenging the judgment of Madras High Court came to be filed by M. Nizamudeen before this Court that a writ petition under Article 32 of the Constitution has been preferred directly before this Court by A. Bhunanenthiran praying therein that the permission granted by the MOEF on December 19, 2005 be quashed and a Writ of Mandamus be issued to the MOEF, TNSCZMA and TNPCB to ensure that no prohibited activity, viz., handling of any hazardous chemical through pipelines or otherwise takes place in CRZ areas on both sides of Uppanar river.
10
15. Be it noted here that three more writ petitions (Writ Petition nos. 37043/2006, 8125/2007 and 23122/2007) came to be filed before Madras High Court challenging environmental clearances granted by the MOEF to the Chemplast. The appellant - M. Nizamudeen - has sought transfer of these petitions to this Court. I.A. No. 7 has been made therein for deletion of respondent nos. 21 and 22. As the issues are common, these writ petitions are transferred to this Court and respondent nos. 21 and 22 are deleted from array of parties.
16. We heard learned senior counsel and counsel for the parties at considerable length.
17. Mr. Ranjit Kumar, learned senior counsel for the appellant - M. Nizamudeen - submitted: that 100 meters from the High Tide Line (HTL) on both sides of Uppanar river are CRZ-III areas where handling of hazardous substance is prohibited; that VCM is hazardous substance notified under the Notification of MOEF issued on November 27, 1989 and handling of a substance includes transfer, as per Section 2(d) of Environment (Protection) Act, 1986; that Chemplast did not 11 seek any permission in respect of the pipelines in the CRZ on both sides of Uppanar river, rather existence of Uppanar river itself was suppressed in the proposals made; that 1996 Plan was neither annexed nor referred to in the proposals made before the competent authorities, nor was even brought to the notice of the High Court and it is being referred to and relied upon for the first time by Chemplast before this Court; that Chemplast while submitting proposals to the competent authorities itself annexed a demarcation map prepared by the National Institute of Oceanography (NIO) to show the High Tide Line/Low Tide Line [HTL/LTL] and the relevant CRZ area; that the said demarcation map prepared by NIO, for the purpose of environmental clearance, must prevail over 1996 Plan and in any case 1996 Plan has become redundant by the amendments in 1991 Notification.
18. Mr. Ranjit Kumar, learned senior counsel also submitted that a close look at the environmental clearance dated December 19, 2005 granted by the MOEF would show that it neither covers nor includes the activities of laying of pipelines across and underneath Uppanar river and drawing of 12 VCM through pipelines. He lastly submitted that Executive Engineer had no authority to permit laying of pipelines in the CRZ of Uppanar river.
19. Dr. Rajeev Dhavan, learned senior counsel for writ petitioner - A. Bhunanenthiran - adopted the submissions of Mr. Ranjit Kumar and further submitted that identification and demarcation of CRZ of any particular State involve two distinct processes and, although, 1996 Plan does not show the land portion of the banks of Uppanar river under CRZ area but the very concept of CRZ areas surrounding rivers changed in 2002. He would submit that 1998 amendment in 1991 Notification lays down that demarcation of CRZ has to be done by the authorized agencies and, therefore, the initial determination of CRZ has to be reassessed in light of the demarcation of the HTL / LTL and CRZ area carried out by authorized demarcating agencies.
20. Dr. Rajeev Dhavan, learned senior counsel would submit that the application made on May 27, 2002 was abandoned by Chemplast because the statutory designated authority, in its inspection held in the month of June 2005, 13 declared the relevant area to be CRZ and the District Coastal Zone Management Committee and TNSCZMA had examined the earlier application for the port area alone. He submitted that realising that the CRZ extended to the Uppanar river, Chemplast made devious hidden changes in its application made on November 14, 2005. Learned senior counsel submitted that the permission granted by MOEF on December 19, 2005 is limited to MTF and no more. He reiterated that the phrase "and thereon to the plant" in the permission dated December 19, 2005 does not cover permission for the pipeline all the way to the Uppanar river.
21. Learned senior counsel urged that 1996 Plan is obsolete and must make way for the plan prepared by NIO and the demarcation of CRZ by the NIO being final, the said plan must prevail over 1996 Plan.
22. According to Dr. Rajeev Dhavan, CRZ-III status has to be attributed to both banks of the Uppanar river through which the pipeline carrying the hazardous substance VCM is to be taken to the plant. Referring to the 1991 Notification as amended in 2002, Dr. Rajeev Dhavan submitted that VCM can 14 be brought on to the port area but not carried any further by pipeline in or across CRZ area including the CRZ-III area in relation to rivers, creeks and backwaters where the salinity concentration is 5 ppt for a distance of 100 meters from the HTL or the width of the river whichever is less. He referred to public trust doctrine and precautionary and public interest principles and submitted that in relation to the CRZ, the public interest to protect the environment is paramount and the benefit of doubt and precaution should be given to the environment. Learned senior counsel submitted that interest of Chemplast and the industry must yield to the public interest in the environment. He would submit that although there has been no challenge to the permission granted on November 28, 2005 to the PVC plant utilizing the VCM but, since the tanks of Chemplast probably fall in the CRZ area, this Court must order the plant to be CRZ compliant by shifting the storage tanks. As regards carriage of VCM, Dr. Rajeev Dhavan suggested that VCM can be carried in tankers at minus 13 degree centigrade which cannot be done by pipeline by going upstream and crossing a bridge and this being an alternative solution, the 15 Court may accept the same which would be consistent with the public interest principles.
23. On the other hand, Mr. K.K. Venugopal, learned senior counsel for the Chemplast submitted that PIL filed before the High Court and also directly before this Court are not bona fide as the petitioners in these matters have been set up by a corporate rival, viz., Cuddalore Powergen Corporation Limited (CPCL) who wanted the land in question at a much cheaper price. CPCL instigated and got these persons who had objected to the scheme in 2002. Learned senior counsel submitted that after obtaining necessary approvals and permissions, the plant at the cost of about Rs. 600 crores has been set up and after having obtained the consent to operate, the plant has started its commercial production. He also submitted that 1996 Plan still holds the field and as per that plan, particularly, sheet no. 10 prepared for the Cuddalore District, the tidal influence in the Uppanar river ends above Thiyagavalli village and below Kudigadu village of Cuddalore Old Town area and, therefore, the area on both sides of Uppanar river through which the pipeline traverses is not CRZ area at all. Mr. K.K. Venugopal 16 contended that the plan prepared by the NIO is not approved plan and the said plan cannot override 1996 Plan approved by the central government under 1991 Notification. Learned senior counsel also submitted that laying of pipelines for transfer of VCM is not a prohibited activity as contended by the petitioners as the interpretation given by them to paragraph 2(ii) of 1991 Notification is too restrictive and narrow.
24. Learned counsel for Union of India urged that the point at which the pipelines pass under the Uppanar river and its banks is not a part of CRZ as per 1996 Plan prepared by the state government and approved by the central government and, therefore, no permission or environmental clearance is required for that portion of the pipeline that passes under the Uppanar river nor such permission was granted. He submitted that environmental clearance was only required for the MTF and that portion of the pipeline that falls within the CRZ abutting the sea, i.e. within 500 meters from HTL and vide permission dated December 19, 2005, environmental clearance was granted for this portion of the pipeline only. He would also submit that the interpretation given to paragraph 2(ii) of 1991 Notification by the 17 petitioners is not correct interpretation and that exception in paragraph 2(ii) needs to be construed in a purposive manner.
25. In view of the contentions advanced by the senior counsel and counsel for the parties, the first question which we have to look to is, whether Uppanar river and its banks at the point where pipelines pass, fall in the CRZ III area. If the answer to this is in the affirmative, obviously, the pipelines crossing underneath Uppanar river would require environmental clearance. The other main question we have to consider in connection with these matters is, whether paragraph 2(ii) of 1991 Notification restricts transfer of VCM (hazardous substance) beyond port area to the PVC plant through pipelines. Other considerations would depend on answer to these two core issues.
26. In considering the first question, we need to look to 1991 Notification which came to be issued by the MOEF declaring the coastal stretches as Coastal Regulation Zone (CRZ) and regulating activities in such area. 1991 Notification 18 has been amended from time to time. To the extent it is relevant, it reads :
"Now, therefore, in exercise of the powers conferred by Clause (d) of sub-rule (3) of Rule 5 of the Environment (Protection) Rules, 1986, and all other powers vesting in its behalf, the Central Government hereby declares the coastal stretches of seas, bays, estuaries, creeks, rivers and backwaters which are influenced by tidal action (in the landward side) upto 500 metres from the High Tide Line (HTL) and the land between the Low Tide Line (LTL) and the HTL as Coastal Regulation Zone; and imposes with effect from the date of this Notification, the following restrictions on the setting up and expansion of industries, operations or processes etc. in the said Coastal Regulation Zone (CRZ).1
[(i) For the purposes of this notification, the High Tide Line means the line on the land up to which the highest water line reaches during the spring tide. The High Tide Line shall be demarcated uniformly in all parts of the country by the demarcating authority or authorities so authorised by the Central Government, in accordance with the general guidelines issued in this regard] 2 [(ii) The distance from the High Tide Line shall apply to both sides in the case of rivers, creeks and backwaters and may be modified on a case to case basis for reasons to be recorded in writing while preparing the Coastal Zone Management Plans provided that this distance shall not be less than 100 meters or the width of the creek, river or backwaters, which ever is less. The distance up to which development along rivers, creeks and backwaters is to be regulated shall be governed by the distance up to which the tidal effects are experienced which shall be determined based on salinity concentration of 5 parts per thousand (ppt).
For the purpose of this notification, the salinity measurements shall be made during the driest period of the year and the distance upto which tidal effects are experienced shall be clearly identified and demarcated accordingly in the Coastal Zone Management Plans.;] 1 Substituted by S.O.1122(E), dated 29th December, 1998. Gazette of India (Extra). No. 849, dated 29-12-1998.
2Inserted as per S.O.(E). No. 550 (E), dated 21st May, 2002 19
2. Prohibited Activities :
The following activities are declared as prohibited within the Coastal Regulation Zone, namely :
(i) ............. (ii) manufacture or handling or storage or disposal
of hazardous substances as specified in the Notifications of the Government of India in the Ministry of Environment & Forests No. S.O. 594(E) dated 28th July, 1989, S.O. 966(E) dated 27th November, 1989 and GSR 1037(E) dated 5th December, 1989; 3[except transfer of hazardous substances from ships to ports, terminals and refineries and vice versa, in the port areas:] ...........................
3. Regulation of Permissible Activities :
All other activities, except those prohibited in para 2 above, will be regulated as under :
1. .........
2. The following activities will require environmental clearance from the Ministry of Environment and Forests, Government of India, namely:
(i) .........
(ii) 4[Operational constructions for ports, harbours and light houses and construction activities of jetties, wharves, Slipways, pipelines and conveying systems including transmission lines provided that environmental clearance in case of constructions or modernization or expansion of jetties and wharves in the Union Territory of Lakshadweep for providing embarkation and disembarkation facilities shall be on the basis of a report of scientific study conducted by the Central Government or any agency authorized or 3 Added by S.O. 494(E), dated 9th July, 1997. Gazette of India (Extra) No. 393, Part II, Sec. 3(ii), dated 9th July, 1997.
4Substituted by Notification No. S.O. No. 636 (E), dated 30-05-2003. 20 recognized by it suggesting environmental safeguard measures required to be taken for minimizing damage to corals and associated biodiversity.] (3) (i) The coastal States and Union Territory Administrations shall prepare, within a period of one year from the date of this Notification, Coastal Zone Management Plans identifying and classifying the CRZ areas within their respective territories in accordance with the guidelines given in Annexures-I and II of the Notification and obtain approval (with or without modifications) of the Central Government in the Ministry of Environment & Forests;
(ii) Within the framework of such approved plans, all development and activities within the CRZ other than those covered in para 2 and para 3 (2) above shall be regulated by the State Government, Union Territory Administration or the local authority as the case may be in accordance with the guidelines given in Annexures-I and II of the Notification; and
(iii) In the interim period till the Coastal Zone Management Plans mentioned in para 3(3)(i) above are prepared and approved, all developments and activities within the CRZ shall not violate the provisions of this Notification. State Governments and Union Territory Administrations shall ensure adherence to these regulations and violations, if any, shall be subject to the provisions of the Environment (Protection) Act, 1986."
27. Indian Council for Enviro-Legal Action filed a writ petition before this Court challenging some of the amendments made in 1991 Notification; they also raised the grievance that the MOEF except for issuing the 1991 Notification had taken no steps to follow up its own directions contained in that 21 Notification. This Court while disposing of writ petition filed by Indian Council for Enviro-Legal Action [(1996) 5 SCC 281], inter alia, issued the following directions:
"(1) .........................
(2)..........................
(3) Considering the fact that the Pollution Control Boards are not only overworked but simultaneously have a limited role to play insofar as it relates to controlling of pollution for the purpose of ensuring effective implementation of the notifications of 1991 and 1994, as also of the Management Plans, the Central Government should consider setting up under Section 3 of the Act, State Coastal Management Authorities in each State or zone and also a National Coastal Management Authority.
(4) The States which have not filed the Management Plans with the Central Government are directed to file the complete plans by 30-6-1996. The Central Government shall finalise and approve the said plans, with or without modifications within three months thereafter. It is possible that the plans as submitted by the respective State Governments and Union Territories may not be acceptable to the Ministry of Environment and Forests. Returning the said plans for modifications and then resubmission of the same may become an unnecessary, time-consuming and, perhaps, a futile exercise. In order to ensure that these plans are finalised at the very earliest, we direct that the plans as submitted will be examined by the Central Government who will inform the State Government or the Union Territory concerned with regard to any shortcomings or modifications which the Ministry of Environment and Forests may suggest. If necessary, a discussion amongst the representatives of the State Governments and the Ministry of Environment and Forests should take place and thereafter the plans should be finalised by the Ministry of Environment, if necessary, by carrying out such modifications as may be required. The decision by the Ministry of Environment and Forests in this regard shall be final and binding.22
A report with regard to the submission and the finalisation of the plans should be filed in this Court and the case will be listed for noting compliance in September 1996. ........................................................"
28. Paragraph 3(3)(i) of 1991 Notification requires the Coastal States and UT Administrations to prepare Coastal Zone Management Plans for identification and classification of the CRZ areas within their respective territories in accordance with the guidelines given in Annexures I and II of the Notification. It further mandates Coastal States and UT Administrations to obtain approval of such plans from the Central Government. As a matter of fact, the said provision provided a period of one year for preparation of such plans from the date of the Notification, but the Coastal States and UT Administrations remained dormant for many years in this regard. However, consequent upon directions of this Court, the State of Tamil Nadu submitted its Coastal Zone Management Plan to the MOEF on August 23, 1996 which was approved on September 27, 1996 (1996 Plan) containing 31 sheets corresponding to maps for different stretches of the coastline of the State of Tamil Nadu with certain conditions/modifications/ 23 classifications. Sheet no.10 pertains to the coastal stretch of Cuddalore District. The MOEF, based on sheet no. 10 (1996 Plan) have stated in their affidavit that the land portion of the banks of Uppanar river adjacent to the plant in Thiyagavalli village where the pipeline crosses Uppanar river does not come under the CRZ area. This position is reiterated by the TNSCZMA in their affidavit filed before this Court:
"..................as per the approved Coastal Zone Management Plan, the banks of Uppanar River adjacent to the Plant in Thiyagavalli Village where the pipeline crosses River Uppanar does not come under CRZ area.................. ......."
29. We were also shown a copy of sheet no.10 from which it did not transpire that Uppanar river and its banks where the pipelines pass have tidal influence and come under the CRZ area. That 1996 Plan does not reflect the area on both sides of the Uppanar river through which the pipelines pass as CRZ area is not in dispute. The contention of the senior counsel for the petitioner/appellant is that 1996 Plan has become redundant and obsolete in view of change in the CRZ regime 24 due to amendments in 1991 Notification, first on December 29, 1998 and then on May 21, 2002.
30. By 1998 amendment, it has been provided in 1991 Notification that HTL shall be demarcated uniformly in all parts of the country by the demarcating authority or authorities so authorized by the central government in accordance with the general guidelines issued in this regard. By further amendment on May 21, 2002, sub-paragraph (ii) was inserted in the first para of 1991 Notification providing therein that the distance from the HTL shall apply to both sides in the case of rivers, creeks and backwaters. The said amendment provides that the distance up to which development along rivers, creeks and backwaters is to be regulated shall be governed by the distance up to which the tidal effects are experienced which shall be determined based on salinity concentration of 5 ppt. It further provides that salinity measurements shall be made during the driest period of the year and distance up to which tidal effects are experienced shall be clearly identified and demarcated in the Coastal Zone Management Plans. It is perfectly true that at the time of preparation and approval of 1996 Plan, the 25 amendments of December 29, 1998 and May 21, 2002 in 1991 Notification had not seen the light of the day and the declaration made in first para that the coastal stretches of seas, bays, estuaries, creeks, rivers and backwaters which are influenced by tidal action (in the landward side) upto 500 meters from the HTL and the land between the LTL and the HTL are CRZ was kept in view but in the absence of any modification carried out thereafter, 1996 Plan remains operative. The authorities authorized to demarcate HTL, we are afraid, cannot override the plan prepared and approved under paragraph 3(3)(i) as the said paragraph leaves no manner of doubt that Coastal Zone Management Plan prepared by the Coastal State (or for that matter State Coastal Zone Management Authority) and duly approved by the MOEF is the relevant plan for identification and classification of CRZ areas. The plan prepared by NIO, thus, cannot be said to have superseded 1996 Plan for the Cuddalore coastal stretch.
31. Moreso, while giving approval on September 27, 1996 to 1996 Plan, the MOEF appended, inter alia, a condition that government of Tamil Nadu would not make any change in 26 the approved categorization of CRZ area without its prior approval. Seen thus, 1996 Plan for the purposes of demarcation and classification of CRZ area in the state of Tamil Nadu has to be treated as final and conclusive and has been rightly treated as such by the MOEF. We hold, as it must be, that the Uppanar river and its banks at the relevant place where the pipelines laid by the Chemplast pass do not fall under CRZ III area as per 1996 Plan and no environmental clearance is needed for such pipelines. The stand of the MOEF is, which seems to us to be correct, that they have granted permission to the onshore pipelines insofar as these pass through the CRZ abutting the sea, i.e. 500 meters from the HTL and no clearance has been granted as it was not required for laying of pipelines under the Uppanar river.
32. Here, we may also deal with the objection of the petitioners that Chemplast has suppressed the material facts regarding the existence of Uppanar river in its proposals. In the first place, there seems to be no substance in the said objection. From the materials available on record that include the Environment Impact Assessment Report (EIA) and Risk 27 Analysis Report (RA), it cannot be said that existence of Uppanar river has been suppressed by the Chemplast in its proposals although in these reports Uppanar river has been described as Uppanar canal. In EIA prepared by L & T Ramboll, in Section <IP_ADDRESS>., it is stated:
"The onshore pipeline to the extent possible is routed in a direct line from the landfall point to the Plant in order to minimise the length. The route crosses the Uppanar canal where the pipeline will be trenched sufficiently deep into the canal bed to avoid impact from grounding vessels, dropped objects or dragged anchors. The pipeline section crossing the Uppanar will be of a type similar to the marine pipeline section. As regards the onshore section, the selection of pipeline type and installation is discussed in the following paragraphs :
The main options for the land pipeline will be :
7 Trenched, sub terrain pipe line (-1.0 to -1.5 m) 7 Pipeline on low supports at the terrain surface (+0.2 to +0.5m) 7 Overhead pipeline on masts/columns above bus/truck passage heights (+4.5 to 5m) (Approximate levels given from existing natural ground level)"
Similarly, in Section 5 of RA, reference is made to pipeline crossing Uppanar canal. The position is clarified by Chemplast in their subsequent application made on November 14, 2005. In the second place, and more importantly, this objection pales into insignificance in view of our finding that the 28 land portion of the banks of Uppanar river where the pipelines laid by Chemplast pass Uppanar river does not fall under CRZ III area.
33. Now, we advert to the other main issue concerning paragraph 2(ii) of 1991 Notification. This paragraph prohibits manufacture or handling or storage or disposal of hazardous substances, as specified in the Notifications issued by MOEF (dated 28th July, 1989, 27th November, 1989 and 5th December, 1989), except transfer of hazardous substances from ships to ports, terminals and refineries and vice-versa, in the port areas. That VCM is hazardous substance notified vide notification dated November 27, 1989 is not in dispute. There is also no dispute, rather it is an admitted position, that handling of a substance includes transfer as per Section 2(d) of the Environment (Protection) Act, 1986. It was contended by the senior counsel for the appellant/petitioner that transfer of VCM in CRZ area is completely prohibited and VCM cannot be carried through the CRZ except in the port area. Their argument is that VCM can be brought onshore by pipeline to the port area but not in the CRZ area. The arguments of 29 learned senior counsel have put in issue the scope of expression, "except transfer of hazardous substances from ships to ports, terminals and refineries and vice versa in the port areas" which was added in paragraph 2(ii) on 9th July, 1997. We are called upon to ascertain the true meaning and intention of the Executive in bringing this exception. In the original 1991 Notification there was no exception clause. It appears to have been added for the purpose of enabling transfer of hazardous substances from ships to ports, ships to terminals and ships to refineries and vice versa. Is such transfer of hazardous substances confined to terminals and refineries located in the port areas? The answer in the affirmative may make the said provision unworkable and would also result in absurdity inasmuch as the hazardous substance would be brought in to the port, refinery or terminal in the port area from the ship and would remain there and could not be taken beyond the port area because of the prohibition. This surely could not have been the intention of the Executive in adding the exception clause. It is well settled that if exception has been added to remedy the mischief or defect, it should be 30 so construed that remedies the mischief and not in a manner which frustrates the very purpose. Purposive construction has often been employed to avoid a lacuna and to suppress the mischief and advance the remedy. It is again a settled rule that if the language used is capable of bearing more than one construction and if construction is employed that results in absurdity or anomaly, such construction has to be rejected and preference should be given to such a construction that brings it into harmony with its purpose and avoids absurdity or anomaly as it may always be presumed that while employing a particular language in the provision absurdity or anomaly was never intended. Notwithstanding imperfection of expression and that exception clause is not happily worded, we are of the view that by applying purposive construction, the expression, `in the port areas' should be read as, `in or through the port areas'. The exception in paragraph 2 (ii) then would achieve its objective and read, `except transfer of hazardous substances from ships to ports, ships to terminals and ships to refineries and vice versa, in or through the port areas'. This construction will be harmonious with paragraph 3(2)(ii) which permits the activity of 31 laying pipelines in the CRZ area. As a matter of fact, the MOEF in their affidavit before this Court have clearly stated that the permission granted to Chemplast on 19th December, 2005 is in exercise of the powers conferred under paragraph 3(2)(ii) of 1991 Notification. We do not find any infirmity in the permission granted by the MOEF on 19th December, 2005. Having held that, there is no illegality in the permission granted by the Executive Engineer on February 27, 2008 either.
34. In view of our foregoing discussion in respect of the two core issues, we do not deem it necessary to deal with the objection raised by Mr. K.K. Venugopal, learned senior counsel for the Chemplast about the maintainability of PILs and that the petitioners have been instigated and set up by a corporate rival - Cuddalore Powergen Corporation Limited.
35. By way of footnote, we may observe that the project has been established by investing huge amount of about Rs. 600 crores and has already been commissioned after obtaining necessary approvals and, therefore, it shall not be in the interest of justice nor in the public interest now to interfere with the project. The alternative solution suggested by 32 Dr. Rajeev Dhavan for carrying VCM across Uppanar river to the plant is noted to be rejected.
36. In the result, Civil Appeal and Writ Petition (Civil) No. 130 of 2009 are dismissed. Writ Petition Nos. 37043 of 2006, 8125 of 2007 and 23122 of 2007 filed before Madras High Court and transferred to this Court are dismissed. Transfer Petitions and I.A. No. 7 stand disposed of. I.A. No. 4 filed by the appellant - M. Nizamudeen - for initiating proceedings for perjury against the MOEF is dismissed. The parties shall bear their own cost.
........................CJI
........................J
(R. M. Lodha)
........................J
New Delhi, (Dr.B.S. Chauhan)
March 10, 2010.
33


American Airlines flight attendants voice 737 MAX concerns to Boeing CEO: letter
The Association of Professional Flight Attendants (APFA), which represents American Airlines Group flight attendants, still has safety concerns about a relaunch of the Boeing 737 MAX, its president told Boeing Chief Executive Dennis Muilenburg in a letter seen by Reuters.
CHICAGO: The Association of Professional Flight Attendants (APFA), which represents American Airlines Group flight attendants, still has safety concerns about a relaunch of the Boeing 737 MAX, its president told Boeing Chief Executive Dennis Muilenburg in a letter seen by Reuters.
The letter, dated Oct. 30, follows two days of hearings in Washington during which lawmakers grilled Muilenburg about the development of the 737 MAX following two crashes that killed 346 people and led to the aircraft's worldwide grounding in March.
In the letter, APFA President Lori Bassani told Muilenburg that the hearings show breakdowns in supervision of the 737 MAX and raise questions about the Federal Aviation Administration's resources for oversight.
"The 28,000 flight attendants working for American Airlines refuse to walk onto a plane that may not be safe and are calling for the highest possible safety standards to avoid another tragedy," Bassani said.
Pilot and flight attendant unions are expected to play a role in an eventual campaign to win over public sentiment on the aircraft once the FAA approves its return to service.
Boeing has said it is targeting FAA approval in the fourth quarter.
U.S. airlines that operated the 737 MAX before its grounding have removed the jet from their flying schedules into early next year.
(Reporting by Tracy Rucinski; Editing by Chris Reese and Dan Grebler)


This page demonstrates parallel for loops with no communication.
The TBC code is as follows.
parFor( count, (i : Int) -> { var ball = balls[i] ; var t = 0 ; loop( pause( 60 ) > exec( () -> { t = t + 60 ; var x = 250-10 + 100 * Math.cos( t / (512+4*i) ) ; ball.css( "left", x ) ; } ) ) ; } ) ;
The haxe code is here.


| TOC |
|
This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
This Internet-Draft will expire on August 2, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1.
Introduction
1.1.
Notational Conventions
1.2.
Terminology
1.3.
Overview
2.
Authenticated Requests
2.1.
Authorization Request Header Field
2.2.
Form-Encoded Body Parameter
2.3.
URI Query Parameter
3.
The WWW-Authenticate Response Header Field
3.1.
Error Codes
4.
Security Considerations
4.1.
Security Threats
4.2.
Threat Mitigation
4.3.
Summary of Recommendations
5.
IANA Considerations
5.1.
OAuth Access Token Type Registration
5.1.1.
The "Bearer" OAuth Access Token Type
5.2.
Authentication Scheme Registration
5.2.1.
The "Bearer" Authentication Scheme
6.
References
6.1.
Normative References
6.2.
Informative References
Appendix A.
Acknowledgements
Appendix B.
Document History
§
Authors' Addresses
| TOC |
OAuth enables clients to access protected resources by obtaining an access token, which is defined in OAuth 2.0 Authorization [I‑D.ietf‑oauth‑v2] (Hammer, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” January 2012.) as "a string representing an access authorization issued to the client", rather than using the resource owner's credentials directly.
Tokens are issued to clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server. This specification describes how to make protected resource requests when the OAuth access token is a bearer token.
This specification defines the use of bearer tokens over HTTP/1.1 [I‑D.ietf‑httpbis‑p1‑messaging] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 1: URIs, Connections, and Message Parsing,” January 2012.) using TLS [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) to access protected resources. TLS is mandatory to implement and use with this specification; other specifications may extend this specification for use with other transport protocols. While designed for use with access tokens resulting from OAuth 2.0 Authorization [I‑D.ietf‑oauth‑v2] (Hammer, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” January 2012.) flows to access OAuth protected resources, this specification actually defines a general HTTP authorization method that can be used with bearer tokens from any source to access any resources protected by those bearer tokens.
| TOC |
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in Key words for use in RFCs to Indicate Requirement Levels [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
This document uses the Augmented Backus-Naur Form (ABNF) notation of HTTP/1.1, Part 1 [I‑D.ietf‑httpbis‑p1‑messaging] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 1: URIs, Connections, and Message Parsing,” January 2012.), which is based upon the Augmented Backus-Naur Form (ABNF) [RFC5234] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) notation. Additionally, the following rules are included from HTTP/1.1, Part 7 [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” January 2012.): auth-param, auth-scheme, and b64token; and from Uniform Resource Identifier (URI) [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.): URI-Reference.
Unless otherwise noted, all the protocol parameter names and values are case sensitive.
| TOC |
- Bearer Token
- A security token with the property that any party in possession of the token (a "bearer") can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of-possession).
All other terms are as defined in OAuth 2.0 Authorization [I‑D.ietf‑oauth‑v2] (Hammer, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” January 2012.).
| TOC |
OAuth provides a method for clients to access a protected resource on behalf of a resource owner. In the general case, before a client can access a protected resource, it must first obtain an authorization grant from the resource owner and then exchange the authorization grant for an access token. The access token represents the grant's scope, duration, and other attributes granted by the authorization grant. The client accesses the protected resource by presenting the access token to the resource server. In some cases, a client can directly present its own credentials to an authorization server to obtain an access token without having to first obtain an authorization grant from a resource owner.
The access token provides an abstraction, replacing different authorization constructs (e.g. username and password, assertion) for a single token understood by the resource server. This abstraction enables issuing access tokens valid for a short time period, as well as removing the resource server's need to understand a wide range of authentication schemes.
+--------+ +---------------+ | |--(A)- Authorization Request ->| Resource | | | | Owner | | |<-(B)-- Authorization Grant ---| | | | +---------------+ | | | | Authorization Grant & +---------------+ | |--(C)--- Client Credentials -->| Authorization | | Client | | Server | | |<-(D)----- Access Token -------| | | | +---------------+ | | | | +---------------+ | |--(E)----- Access Token ------>| Resource | | | | Server | | |<-(F)--- Protected Resource ---| | +--------+ +---------------+
| Figure 1: Abstract Protocol Flow |
The abstract flow illustrated in Figure 1 (Abstract Protocol Flow) describes the overall OAuth 2.0 protocol architecture. The following steps are specified within this document:
E) The client makes a protected resource request to the resource server by presenting the access token.
F) The resource server validates the access token, and if valid, serves the request.
| TOC |
This section defines three methods of sending bearer access tokens in resource requests to resource servers. Clients MUST NOT use more than one method to transmit the token in each request.
| TOC |
When sending the access token in the Authorization request header field defined by HTTP/1.1, Part 7 [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” January 2012.), the client uses the Bearer authentication scheme to transmit the access token.
For example:
GET /resource HTTP/1.1 Host: server.example.com Authorization: Bearer vF9dft4qmT
The Authorization header field uses the framework defined by HTTP/1.1, Part 7 [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” January 2012.) as follows:
credentials = "Bearer" 1*SP b64token
The b64token syntax was chosen over the alternative #auth-param syntax also defined by HTTP/1.1, Part 7 [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” January 2012.) both for simplicity and for compatibility with existing implementations. If additional parameters are needed in the future, a different scheme would need to be defined.
Clients SHOULD make authenticated requests with a bearer token using the Authorization request header field with the Bearer HTTP authorization scheme. Resource servers MUST support this method.
| TOC |
When sending the access token in the HTTP request entity-body, the client adds the access token to the request body using the access_token parameter. The client MUST NOT use this method unless all of the following conditions are met:
The entity-body MAY include other request-specific parameters, in which case, the access_token parameter MUST be properly separated from the request-specific parameters using & character(s) (ASCII code 38).
For example, the client makes the following HTTP request using transport-layer security:
POST /resource HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded access_token=vF9dft4qmT
The application/x-www-form-urlencoded method SHOULD NOT be used except in application contexts where participating browsers do not have access to the Authorization request header field. Resource servers MAY support this method.
| TOC |
When sending the access token in the HTTP request URI, the client adds the access token to the request URI query component as defined by Uniform Resource Identifier (URI) [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) using the access_token parameter.
For example, the client makes the following HTTP request using transport-layer security:
GET /resource?access_token=vF9dft4qmT HTTP/1.1 Host: server.example.com
The HTTP request URI query can include other request-specific parameters, in which case, the access_token parameter MUST be properly separated from the request-specific parameters using & character(s) (ASCII code 38).
For example:
https://server.example.com/resource?x=y&access_token=vF9dft4qmT&p=q
Because of the security weaknesses associated with the URI method (see Section 4 (Security Considerations)), including the high likelihood that the URL containing the access token will be logged, it SHOULD NOT be used unless it is impossible to transport the access token in the Authorization request header field or the HTTP request entity-body. Resource servers MAY support this method.
| TOC |
If the protected resource request does not include authentication credentials or does not contain an access token that enables access to the protected resource, the resource server MUST include the HTTP WWW-Authenticate response header field; it MAY include it in response to other conditions as well. The WWW-Authenticate header field uses the framework defined by HTTP/1.1, Part 7 [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” January 2012.).
All challenges defined by this specification MUST use the auth-scheme value Bearer. This scheme MUST be followed by one or more auth-param values. The auth-param attributes used or defined by this specification are as follows. Other auth-param attributes MAY be used as well.
A realm attribute MAY be included to indicate the scope of protection in the manner described in HTTP/1.1, Part 7 [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” January 2012.). The realm attribute MUST NOT appear more than once.
The scope attribute is a space-delimited list of scope values indicating the required scope of the access token for accessing the requested resource. In some cases, the scope value will be used when requesting a new access token with sufficient scope of access to utilize the protected resource. Use of the scope attribute is OPTIONAL. The scope attribute MUST NOT appear more than once. The scope value is intended for programmatic use and is not meant to be displayed to end users.
If the protected resource request included an access token and failed authentication, the resource server SHOULD include the error attribute to provide the client with the reason why the access request was declined. The parameter value is described in Section 3.1 (Error Codes). In addition, the resource server MAY include the error_description attribute to provide developers a human-readable explanation that is not meant to be displayed to end users. It also MAY include the error_uri attribute with an absolute URI identifying a human-readable web page explaining the error. The error, error_description, and error_uri attributes MUST NOT appear more than once.
Values for the scope attribute MUST NOT include characters outside the set %x21 / %x23-5B / %x5D-7E for representing scope values and %x20 for delimiters between scope values. Values for the error and error_description attributes MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E. Values for the error_uri attribute MUST conform to the URI-Reference syntax, and thus MUST NOT include characters outside the set %x21 / %x23-5B / %x5D-7E.
For example, in response to a protected resource request without authentication:
HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm="example"
And in response to a protected resource request with an authentication attempt using an expired access token:
HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm="example", error="invalid_token", error_description="The access token expired"
| TOC |
When a request fails, the resource server responds using the appropriate HTTP status code (typically, 400, 401, 403, or 405), and includes one of the following error codes in the response:
- invalid_request
- The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats the same parameter, uses more than one method for including an access token, or is otherwise malformed. The resource server SHOULD respond with the HTTP 400 (Bad Request) status code.
- invalid_token
- The access token provided is expired, revoked, malformed, or invalid for other reasons. The resource SHOULD respond with the HTTP 401 (Unauthorized) status code. The client MAY request a new access token and retry the protected resource request.
- insufficient_scope
- The request requires higher privileges than provided by the access token. The resource server SHOULD respond with the HTTP 403 (Forbidden) status code and MAY include the scope attribute with the scope necessary to access the protected resource.
If the request lacks any authentication information (i.e. the client was unaware authentication is necessary or attempted using an unsupported authentication method), the resource server SHOULD NOT include an error code or other error information.
For example:
HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm="example"
| TOC |
This section describes the relevant security threats regarding token handling when using bearer tokens and describes how to mitigate these threats.
| TOC |
The following list presents several common threats against protocols utilizing some form of tokens. This list of threats is based on NIST Special Publication 800-63 [NIST800‑63] (Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S., and E. Nabbus, “NIST Special Publication 800-63-1, INFORMATION SECURITY,” December 2008.). Since this document builds on the OAuth 2.0 specification, we exclude a discussion of threats that are described there or in related documents.
- Token manufacture/modification:
- An attacker may generate a bogus token or modify the token contents (such as the authentication or attribute statements) of an existing token, causing the resource server to grant inappropriate access to the client. For example, an attacker may modify the token to extend the validity period; a malicious client may modify the assertion to gain access to information that they should not be able to view.
- Token disclosure:
- Tokens may contain authentication and attribute statements that include sensitive information.
- Token redirect:
- An attacker uses a token generated for consumption by one resource server to gain access to a different resource server that mistakenly believes the token to be for it.
- Token replay:
- An attacker attempts to use a token that has already been used with that resource server in the past.
| TOC |
A large range of threats can be mitigated by protecting the contents of the token by using a digital signature or a Message Authentication Code (MAC). Alternatively, a bearer token can contain a reference to authorization information, rather than encoding the information directly. Such references MUST be infeasible for an attacker to guess; using a reference may require an extra interaction between a server and the token issuer to resolve the reference to the authorization information. The mechanics of such an interaction are not defined by this specification.
This document does not specify the encoding or the contents of the token; hence detailed recommendations about the means of guaranteeing token integrity protection are outside the scope of this document. The token integrity protection MUST be sufficient to prevent the token from being modified.
To deal with token redirect, it is important for the authorization server to include the identity of the intended recipients (the audience), typically a single resource server (or a list of resource servers), in the token. Restricting the use of the token to a specific scope is also RECOMMENDED.
The authorization server MUST implement TLS. Which version(s) ought to be implemented will vary over time, and depend on the widespread deployment and known security vulnerabilities at the time of implementation. At the time of this writing, TLS version 1.2 [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) is the most recent version, but has very limited actual deployment, and might not be readily available in implementation toolkits. TLS version 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) is the most widely deployed version, and will give the broadest interoperability.
To protect against token disclosure, confidentiality protection MUST be applied using TLS [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) with a ciphersuite that provides confidentiality and integrity protection. This requires that the communication interaction between the client and the authorization server, as well as the interaction between the client and the resource server, utilize confidentiality and integrity protection. Since TLS is mandatory to implement and to use with this specification, it is the preferred approach for preventing token disclosure via the communication channel. For those cases where the client is prevented from observing the contents of the token, token encryption MUST be applied in addition to the usage of TLS protection. As a further defense against token disclosure, the client MUST validate the TLS certificate chain when making requests to protected resources.
Cookies are typically transmitted in the clear. Thus, any information contained in them is at risk of disclosure. Therefore, bearer tokens MUST NOT be stored in cookies that can be sent in the clear.
In some deployments, including those utilizing load balancers, the TLS connection to the resource server terminates prior to the actual server that provides the resource. This could leave the token unprotected between the front end server where the TLS connection terminates and the back end server that provides the resource. In such deployments, sufficient measures MUST be employed to ensure confidentiality of the token between the front end and back end servers; encryption of the token is one possible such measure.
To deal with token capture and replay, the following recommendations are made: First, the lifetime of the token MUST be limited; one means of achieving this is by putting a validity time field inside the protected part of the token. Note that using short-lived (one hour or less) tokens reduces the impact of them being leaked. Second, confidentiality protection of the exchanges between the client and the authorization server and between the client and the resource server MUST be applied. As a consequence, no eavesdropper along the communication path is able to observe the token exchange. Consequently, such an on-path adversary cannot replay the token. Furthermore, when presenting the token to a resource server, the client MUST verify the identity of that resource server, as per Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) [RFC6125] (Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” March 2011.). Note that the client MUST validate the TLS certificate chain when making these requests to protected resources. Presenting the token to an unauthenticated and unauthorized resource server or failing to validate the certificate chain will allow adversaries to steal the token and gain unauthorized access to protected resources.
| TOC |
- Safeguard bearer tokens:
- Client implementations MUST ensure that bearer tokens are not leaked to unintended parties, as they will be able to use them to gain access to protected resources. This is the primary security consideration when using bearer tokens and underlies all the more specific recommendations that follow.
- Validate SSL certificate chains:
- The client MUST validate the TLS certificate chain when making requests to protected resources. Failing to do so may enable DNS hijacking attacks to steal the token and gain unintended access.
- Always use TLS (https):
- Clients MUST always use TLS [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) (https) or equivalent transport security when making requests with bearer tokens. Failing to do so exposes the token to numerous attacks that could give attackers unintended access.
- Don't store bearer tokens in cookies:
- Implementations MUST NOT store bearer tokens within cookies that can be sent in the clear (which is the default transmission mode for cookies). Implementations that do store bearer tokens in cookies MUST take precautions against cross site request forgery.
- Issue short-lived bearer tokens:
- Token servers SHOULD issue short-lived (one hour or less) bearer tokens, particularly when issuing tokens to clients that run within a web browser or other environments where information leakage may occur. Using short-lived bearer tokens can reduce the impact of them being leaked.
- Issue scoped bearer tokens:
- Token servers SHOULD issue bearer tokens that contain an audience restriction, scoping their use to the intended relying party or set of relying parties.
- Don't pass bearer tokens in page URLs:
- Bearer tokens SHOULD NOT be passed in page URLs (for example as query string parameters). Instead, bearer tokens SHOULD be passed in HTTP message headers or message bodies for which confidentiality measures are taken. Browsers, web servers, and other software may not adequately secure URLs in the browser history, web server logs, and other data structures. If bearer tokens are passed in page URLs, attackers might be able to steal them from the history data, logs, or other unsecured locations.
| TOC |
| TOC |
This specification registers the following access token type in the OAuth Access Token Type Registry.
| TOC |
- Type name:
- Bearer
- Additional Token Endpoint Response Parameters:
- (none)
- HTTP Authentication Scheme(s):
- Bearer
- Change controller:
- IETF
- Specification document(s):
- [[ this document ]]
| TOC |
This specification registers the following authentication scheme in the Authentication Scheme Registry defined in HTTP/1.1, Part 7 [I‑D.ietf‑httpbis‑p7‑auth] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” January 2012.).
| TOC |
- Authentication Scheme Name:
- Bearer
- Pointer to specification text:
- [[ this document ]]
- Notes (optional):
- (none)
| TOC |
| TOC |
| [I-D.ietf-httpbis-p1-messaging] | Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 1: URIs, Connections, and Message Parsing,” draft-ietf-httpbis-p1-messaging-18 (work in progress), January 2012 (TXT). |
| [I-D.ietf-httpbis-p7-auth] | Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., and J. Reschke, “HTTP/1.1, part 7: Authentication,” draft-ietf-httpbis-p7-auth-18 (work in progress), January 2012 (TXT). |
| [I-D.ietf-oauth-v2] | Hammer, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” draft-ietf-oauth-v2-23 (work in progress), January 2012 (TXT, PDF). |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC2246] | Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” RFC 2246, January 1999 (TXT). |
| [RFC3986] | Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML). |
| [RFC5234] | Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” STD 68, RFC 5234, January 2008 (TXT). |
| [RFC5246] | Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008 (TXT). |
| [RFC6125] | Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” RFC 6125, March 2011 (TXT). |
| [USASCII] | American National Standards Institute, “Coded Character Set -- 7-bit American Standard Code for Information Interchange,” ANSI X3.4, 1986. |
| [W3C.REC-html401-19991224] | Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” World Wide Web Consortium Recommendation REC-html401-19991224, December 1999 (HTML). |
| TOC |
| [NIST800-63] | Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S., and E. Nabbus, “NIST Special Publication 800-63-1, INFORMATION SECURITY,” December 2008. |
| [RFC2616] | Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2616, June 1999 (TXT, PS, PDF, HTML, XML). |
| [RFC2617] | Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” RFC 2617, June 1999 (TXT, HTML, XML). |
| TOC |
The following people contributed to preliminary versions of this document: Blaine Cook (BT), Brian Eaton (Google), Yaron Y. Goland (Microsoft), Brent Goldman (Facebook), Raffi Krikorian (Twitter), Luke Shepard (Facebook), and Allen Tom (Yahoo!). The content and concepts within are a product of the OAuth community, the WRAP community, and the OAuth Working Group.
The OAuth Working Group has dozens of very active contributors who proposed ideas and wording for this document, including: Michael Adams, Amanda Anganes, Andrew Arnott, Dirk Balfanz, John Bradley, Brian Campbell, Leah Culver, Bill de hÓra, Brian Ellin, Igor Faynberg, Stephen Farrell, George Fletcher, Tim Freeman, Evan Gilbert, Yaron Y. Goland, Thomas Hardjono, Justin Hart, Phil Hunt, John Kemp, Eran Hammer-Lahav, Chasen Le Hara, Barry Leiba, Michael B. Jones, Torsten Lodderstedt, Eve Maler, James Manger, Laurence Miao, William J. Mills, Chuck Mortimore, Anthony Nadalin, Julian Reschke, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius Scurtescu, Naitik Shah, Justin Smith, Jeremy Suriel, Christian Stübner, Paul Tarjan, Hannes Tschofenig, Franklin Tse, and Shane Weeden.
| TOC |
[[ to be removed by the RFC editor before publication as an RFC ]]
-16
-15
-14
-13
-12
-11
-10
-09
-08
-07
-06
-05
-04
-03
-02
-01
-00
| TOC |
| Michael B. Jones | |
| Microsoft | |
| Email: |<EMAIL_ADDRESS>|
| URI: | http://self-issued.info/ |
| Dick Hardt | |
| independent | |
| Email: |<EMAIL_ADDRESS>|
| URI: | http://dickhardt.org/ |
| David Recordon | |
| Email: |<EMAIL_ADDRESS>|
| URI: | http://www.davidrecordon.com/ |


What I do.
Welcome to my portfolio website. There is variety of visual art here. my focus is on 3D modeling and sculptor plus animation and motion graphics.
Welcome to my portfolio website. There is variety of visual art here. my focus is on 3D modeling and sculptor plus animation and motion graphics.
I do Photography, drawing, Painting and webdesign on the side in addition to 3D.


Jquery Selection
Single
Select Country
India
Afghanistan
USA
Canada
South Africa
Nigeria
Multiple
Select Color
White
Black
Green
Red
Blue
Orange
Already Selected
Select Color
White
Black
Green
Red
Blue
Orange


Hi {{analysesIndex.user.first_name}}. This is your Analysis List. Create a new Analysis or check the status of an existing one to proceed.


Inflation steady at 1.9%
by The Canadian PressThe annual pace of inflation held steady in October as the consumer price index rose 1.9 per cent compared with a year ago, matching its moves in August and September, Statistics Canada said Wednesday.
The result was also in line with the expectations of economists, according to financial markets data firm Refinitiv.
The overall rise in prices came as food prices rose 3.7 per cent compared with a year ago. Fresh fruit prices rose 7.9 per cent and fresh vegetable prices climbed 7.5 per cent.
Compared with a year ago, the price of gasoline was down 6.7 per cent in October compared with a 10.0 per cent decline in September. Natural gas prices rose 3.3 per cent compared with a year ago following a 5.8 per cent increase in September.
Statistics Canada said although global demand for oil remained low in October, there were slight price increases on a monthly basis due to temporary supply disruptions in the Middle East and a drop in crude oil inventories in the United States.
Excluding gasoline, the annual pace of inflation was 2.3 per cent in October, down from 2.4 per cent in September.
The average of Canada's three measures for core inflation, which are considered better gauges of underlying price pressures, was 2.07 per cent compared with a revised figure of 2.03 per cent in September.
The core readings are closely monitored by the Bank of Canada, which adjusts its key interest rate target to manage inflation.
Regionally, prices were up 2.3 per cent compared with a year ago in Quebec, while Manitoba and B.C. both saw increases of 2.2 per cent. The annual pace of inflation was 1.7 per cent in Ontario.


Issue 82
Welcome to another issue of Haskell Weekly!  This is a weekly summary of what’s going on in its community.
Want to see something featured in Haskell Weekly? We love contributions! Tweet us at @HaskellWeekly or open a pull request.
Featured
-
The GHC Team is pleased to announce a new minor release of GHC. This release builds on the performance and stability improvements of 8.2.1, fixing a variety of correctness bugs, improving error messages, and making the compiler more portable.
-
Finite-state machines part 2: Explicit typed state transitions
Using a sort of extended MTL style, with conventions for state machine encodings, gives us more type safety in state transitions. Abstract state values, impossible to create outside the instance, are now passed explicitly in state transitions.
-
Anatomy of a Haskell-based application, revisited
Speaking of refactoring, we are happy that we chose Haskell, a wonderful language that enables large refactoring with ease, perhaps even turning what could be unthinkable architectural changes in other languages into pure tedium.
-
In part one we learned about the package database. Part two then introduced the tools and programs built when building GHC. In this part we will look at how the actual stages are built.
-
Joys and frustrations of putting 34,000 lines of Haskell into production
What did we really build in 34,000 lines of Haskell? Flexi-payment plugin, DelayedJob clone along with UI, SendGrid library, working clone of Inky to send bulletproof HTML emails, Opaleye boilerplate code-generator, and deep instrumentation wrappers over core libs.
-
MonadBaseControl
in five minutesThe big idea behind
MonadIO
m is that you can perform a transformationIO a -> m a
. The big idea behindMonadBaseControl
is that you can perform a transformationm a -> IO a
. -
To really get good performance, we need to simultaneously optimize along two orthogonal dimensions: get more done simultaneously, by parallelizing, but also make each sequential unit of work run faster.
-
Independent Redis query aggregation
Instead of executing many independent
get
commands, Redis providesmget key1 key2 ...
, which will perform all the lookups at once in a single command. Which brings me to the topic of this post: is there a way to systematically constructmget
queries in a type-safe way? -
A curious topological result in euclidean spaces is the number of possible regular polytopes in n dimensions. The series (starting with dimension 0) goes like this: 1 1 ∞ 5 6 3 3 3 …
-
Quick and easy user-defined operators with Plated
All infix operators have precedence and associativity. A language that supports user-defined operators should also give the user a way to control these attributes for their custom operators. Modern languages do this in a variety of ways.
Jobs
-
Job openings with the Strats team at Standard Chartered bank
The Strats team at Standard Chartered are hiring again. We have openings for various roles. These will typically involve direct contact with traders to automate processes, often in rapid delivery style.
In brief
- Anki deck: Haskell lens operators
- Announcing
fin
andvec
packages - Announcing MMark
- Continuous integration to continuous delivery Haskell project with GitLab
- Hannah: A DSL for parsing and generating files and network traces
- Haskell equality table
- materialize-hakyll: a new theme for hakyll based on material design
mega-sdist
: The mega repo helper- Øredev 2017: Ashic Mahtab: Actually Using Haskell
- Type-directed code generation
tzimtsum
: A Presburger arithmetic proposition decider Haskell library
Package of the week
This week’s package of the week is Flow, a library for writing more understandable Haskell by using better operators.
Call for participation
- Carp: Benchmarking examples
- eta:
etlas exec
inside of a sandbox fails - hledger: hledger-web doesn’t show results for accounts with an apostrophe
Events
- November 23: Madrid Haskell Users Group: Un encuentro mágico: Bitcoin y Haskell
- November 27: Frankfurt Haskell User Group: Shoebox - Status und nächste Schritte Peter Althainz
- November 28: Indy FP: Haskell Type Level Rest Api ⚡ Talk
- November 29: Wellington Functional Programming: Using Haskell Everywhere by Hamish Mackenzie
- November 30: HaskellerZ: Tom Sydney Kerckhove: An overview of validity based testing
- December 6: Berlin Functional Programming Group: FP Forum: Learn, Teach, Share, Grow


|
CmdMessenger
4.0.0
CmdMessenger is a serial port messaging library for the .Net / Mono Platform.
|
Command messenger main class. More...
Public Member Functions | |
| delegate void | MessengerCallbackFunction (ReceivedCommand receivedCommand) |
| Definition of the messenger callback function. | |
| CmdMessenger (ITransport transport, BoardType boardType=BoardType.Bit16) | |
| Constructor. | |
| CmdMessenger (ITransport transport, int sendBufferMaxLength, BoardType boardType=BoardType.Bit16) | |
| Constructor. | |
| CmdMessenger (ITransport transport, BoardType boardType, char fieldSeparator) | |
| Constructor. | |
| CmdMessenger (ITransport transport, BoardType boardType, char fieldSeparator, int sendBufferMaxLength) | |
| Constructor. | |
| CmdMessenger (ITransport transport, BoardType boardType, char fieldSeparator, char commandSeparator) | |
| Constructor. | |
| CmdMessenger (ITransport transport, BoardType boardType, char fieldSeparator, char commandSeparator, char escapeCharacter, int sendBufferMaxLength) | |
| Constructor. | |
| void | Dispose () |
| Disposal of CmdMessenger. | |
| void | SetControlToInvokeOn (Control controlToInvokeOn) |
| Sets a control to invoke on. | |
| bool | Disconnect () |
| Stop listening and end serial port connection. | |
| bool | Connect () |
| Starts serial port connection and start listening. | |
| void | Attach (MessengerCallbackFunction newFunction) |
| Attaches default callback for unsupported commands. | |
| void | Attach (int messageId, MessengerCallbackFunction newFunction) |
| Attaches default callback for certain Message ID. | |
| ReceivedCommand | SendCommand (SendCommand sendCommand, SendQueue sendQueueState=SendQueue.InFrontQueue, ReceiveQueue receiveQueueState=ReceiveQueue.Default) |
| Sends a command. If no command acknowledge is requested, the command will be send asynchronously: it will be put on the top of the send queue If a command acknowledge is requested, the command will be send synchronously: the program will block until the acknowledge command has been received or the timeout has expired. Based on ClearQueueState, the send- and receive-queues are left intact or are cleared. | |
| ReceivedCommand | SendCommand (SendCommand sendCommand, SendQueue sendQueueState, ReceiveQueue receiveQueueState, UseQueue useQueue) |
| Sends a command. If no command acknowledge is requested, the command will be send asynchronously: it will be put on the top of the send queue If a command acknowledge is requested, the command will be send synchronously: the program will block until the acknowledge command has been received or the timeout has expired. Based on ClearQueueState, the send- and receive-queues are left intact or are cleared. | |
| ReceivedCommand | SendCommandSync (SendCommand sendCommand, SendQueue sendQueueState) |
| Synchronized send a command. | |
| void | QueueCommand (SendCommand sendCommand) |
| Put the command at the back of the sent queue. | |
| void | QueueCommand (CommandStrategy commandStrategy) |
| Put a command wrapped in a strategy at the back of the sent queue. | |
| void | AddReceiveCommandStrategy (GeneralStrategy generalStrategy) |
| Adds a general command strategy to the receive queue. This will be executed on every enqueued and dequeued command. | |
| void | AddSendCommandStrategy (GeneralStrategy generalStrategy) |
| Adds a general command strategy to the send queue. This will be executed on every enqueued and dequeued command. | |
| void | ClearReceiveQueue () |
| Clears the receive queue. | |
| void | ClearSendQueue () |
| Clears the send queue. | |
Protected Member Functions | |
| virtual void | Dispose (bool disposing) |
Properties | |
| bool | PrintLfCr [get, set] |
| Gets or sets a whether to print a line feed carriage return after each command. | |
| Control | ControlToInvokeOn [get, set] |
| The control to invoke the callback on. | |
| long | LastReceivedCommandTimeStamp [get] |
| Gets or sets the time stamp of the last command line received. | |
Events | |
| EventHandler< CommandEventArgs > | NewLineReceived |
| Event handler for one or more lines received. | |
| EventHandler< CommandEventArgs > | NewLineSent |
| Event handler for a new line sent. |
Command messenger main class.
| CommandMessenger.CmdMessenger.CmdMessenger | ( | ITransport | transport, |
| BoardType | boardType = BoardType.Bit16 |
||
| ) |
Constructor.
| transport | The transport layer. |
| boardType | Embedded Processor type. Needed to translate variables between sides. |
| CommandMessenger.CmdMessenger.CmdMessenger | ( | ITransport | transport, |
| int | sendBufferMaxLength, | ||
| BoardType | boardType = BoardType.Bit16 |
||
| ) |
Constructor.
| transport | The transport layer. |
| sendBufferMaxLength | The maximum size of the send buffer |
| boardType | Embedded Processor type. Needed to translate variables between sides. |
| CommandMessenger.CmdMessenger.CmdMessenger | ( | ITransport | transport, |
| BoardType | boardType, | ||
| char | fieldSeparator | ||
| ) |
Constructor.
| transport | The transport layer. |
| boardType | Embedded Processor type. Needed to translate variables between sides. |
| fieldSeparator | The field separator. |
| CommandMessenger.CmdMessenger.CmdMessenger | ( | ITransport | transport, |
| BoardType | boardType, | ||
| char | fieldSeparator, | ||
| int | sendBufferMaxLength | ||
| ) |
Constructor.
| transport | The transport layer. |
| boardType | Embedded Processor type. Needed to translate variables between sides. |
| fieldSeparator | The field separator. |
| sendBufferMaxLength | The maximum size of the send buffer |
| CommandMessenger.CmdMessenger.CmdMessenger | ( | ITransport | transport, |
| BoardType | boardType, | ||
| char | fieldSeparator, | ||
| char | commandSeparator | ||
| ) |
Constructor.
| transport | The transport layer. |
| boardType | Embedded Processor type. Needed to translate variables between sides. |
| fieldSeparator | The field separator. |
| commandSeparator | The command separator. |
| CommandMessenger.CmdMessenger.CmdMessenger | ( | ITransport | transport, |
| BoardType | boardType, | ||
| char | fieldSeparator, | ||
| char | commandSeparator, | ||
| char | escapeCharacter, | ||
| int | sendBufferMaxLength | ||
| ) |
Constructor.
| transport | The transport layer. |
| boardType | Embedded Processor type. Needed to translate variables between sides. |
| fieldSeparator | The field separator. |
| commandSeparator | The command separator. |
| escapeCharacter | The escape character. |
| sendBufferMaxLength | The maximum size of the send buffer |
| void CommandMessenger.CmdMessenger.AddReceiveCommandStrategy | ( | GeneralStrategy | generalStrategy | ) |
Adds a general command strategy to the receive queue. This will be executed on every enqueued and dequeued command.
| generalStrategy | The general strategy for the receive queue. |
| void CommandMessenger.CmdMessenger.AddSendCommandStrategy | ( | GeneralStrategy | generalStrategy | ) |
Adds a general command strategy to the send queue. This will be executed on every enqueued and dequeued command.
| generalStrategy | The general strategy for the send queue. |
| void CommandMessenger.CmdMessenger.Attach | ( | MessengerCallbackFunction | newFunction | ) |
Attaches default callback for unsupported commands.
| newFunction | The callback function. |
| void CommandMessenger.CmdMessenger.Attach | ( | int | messageId, |
| MessengerCallbackFunction | newFunction | ||
| ) |
Attaches default callback for certain Message ID.
| messageId | Command ID. |
| newFunction | The callback function. |
Clears the receive queue.
Clears the send queue.
Starts serial port connection and start listening.
Stop listening and end serial port connection.
Disposal of CmdMessenger.
| delegate void CommandMessenger.CmdMessenger.MessengerCallbackFunction | ( | ReceivedCommand | receivedCommand | ) |
Definition of the messenger callback function.
| receivedCommand | The received command. |
| void CommandMessenger.CmdMessenger.QueueCommand | ( | SendCommand | sendCommand | ) |
Put the command at the back of the sent queue.
| sendCommand | The command to sent. |
| void CommandMessenger.CmdMessenger.QueueCommand | ( | CommandStrategy | commandStrategy | ) |
Put a command wrapped in a strategy at the back of the sent queue.
| commandStrategy | The command strategy. |
| ReceivedCommand CommandMessenger.CmdMessenger.SendCommand | ( | SendCommand | sendCommand, |
| SendQueue | sendQueueState = SendQueue.InFrontQueue , |
||
| ReceiveQueue | receiveQueueState = ReceiveQueue.Default |
||
| ) |
Sends a command. If no command acknowledge is requested, the command will be send asynchronously: it will be put on the top of the send queue If a command acknowledge is requested, the command will be send synchronously: the program will block until the acknowledge command has been received or the timeout has expired. Based on ClearQueueState, the send- and receive-queues are left intact or are cleared.
| sendCommand | The command to sent. |
| sendQueueState | Property to optionally clear/wait the send queue |
| receiveQueueState | Property to optionally clear/wait the send queue |
| ReceivedCommand CommandMessenger.CmdMessenger.SendCommand | ( | SendCommand | sendCommand, |
| SendQueue | sendQueueState, | ||
| ReceiveQueue | receiveQueueState, | ||
| UseQueue | useQueue | ||
| ) |
Sends a command. If no command acknowledge is requested, the command will be send asynchronously: it will be put on the top of the send queue If a command acknowledge is requested, the command will be send synchronously: the program will block until the acknowledge command has been received or the timeout has expired. Based on ClearQueueState, the send- and receive-queues are left intact or are cleared.
| sendCommand | The command to sent. |
| sendQueueState | Property to optionally clear/wait the send queue |
| receiveQueueState | Property to optionally clear/wait the send queue |
| useQueue | Property to optionally bypass the queue |
| ReceivedCommand CommandMessenger.CmdMessenger.SendCommandSync | ( | SendCommand | sendCommand, |
| SendQueue | sendQueueState | ||
| ) |
Synchronized send a command.
| sendCommand | The command to sent. |
| sendQueueState | Property to optionally clear/wait the send queue. |
| void CommandMessenger.CmdMessenger.SetControlToInvokeOn | ( | Control | controlToInvokeOn | ) |
Sets a control to invoke on.
| controlToInvokeOn | The control to invoke on. |
Control CommandMessenger.CmdMessenger.ControlToInvokeOn [get, set] |
The control to invoke the callback on.
Gets or sets the time stamp of the last command line received.
The last line time stamp.
bool CommandMessenger.CmdMessenger.PrintLfCr [get, set] |
Gets or sets a whether to print a line feed carriage return after each command.
true if print line feed carriage return, false if not.
Event handler for one or more lines received.
| EventHandler<CommandEventArgs> CommandMessenger.CmdMessenger.NewLineSent |
Event handler for a new line sent.


Search a place:
Climate Change AI
Real Street View Images of {{location}}
{% for image_name in image_names %}
{% endfor %}
Generated Street View Images of {{location}}
{% for image in fake_images %}
{% endfor %}


Linkist helps you organize all of your favorite links in one place for your convenience!
Github Says: None
Get Started


Your answers
This section is: Pre-application
Business you’re registering
Answer: {% include "includes/business-address-nonlist.html" %}
What’s your business structure?
Answer: Limited company
What’s your company registration number?
Answer: A1234567
What’s your type of business?
Answer: Trust
What do you need to register?
Answer:-
{% include "includes/business-type.html" %}


Products from Novicehacks [Simple|Complex|Reusable]
Onecloud provides single portal for all the cloud storage services to a user in one single portal. A user can register as many services as he wants in this application from multiple service providers.
The genesis of onecloud is not meant to replace the features or services provided by the providers, but just to provide simple and easy access to the content from multiple accounts.
Onecloud application in no way caches or stores the user data in any of the servers except the oauth2 access tokens shared by the provider.
BETA VERSION: It is currently in development, and is hosted on openshift platform; and can be accessed here
With ever growing demand of large scale applications, and growing sizes of data centers, in order to run these applications smoothly the people in administration/operations department will perform the health check of all the systems at regular intervals.
Admin Autobot comes in handy to handle these kind of operations, it has the built in support for connecting to [unix|linux] machines; and perform the disk and cpu analysis at predefined intervals. It also helps by generating reports and monitoring the usage based on the set threshold.
In addition to the built in commands, it allows the user to specify any unix command to be executed periodically.
BETA VERSION: It is currently in testing phase, and is hosted on github platform.
Samartha Nauyana is a simple and elegant js library, it is used to retain the state in the navigation bar. The name is derived from sanskrit "Samartha(समर्थ)" - powerful, "Nauyana(नौयान)" - navigation, corresponding the "Powerful Navigation" scheme implemented in the library.
Samartha Nauyana, will not just create the navigation menu, but will also retain its state when a user navigates from one page to another. It uses the browser storage for retaining the state, and is engineered to be customized with simple JSON notation.
Samartha Nauyana is developed on top of JQuery UI's Accordion widget. All the credits for the look and feel will go to the owners of the widget.
BETA VERSION: It is currently in testing phase, and is hosted on github platform. A Demo of the library can be accessed from the project pages


Welcome to the webpage for the 2012 STWing Mario Kart Tournament! To navigate this website, use the tabs at the top of the page.
Please complete the above form and hit submit if you plan on participating in the Mario Kart tournament.
On the day of the tournament, please arrive before 7:15pm to check in for the tournament to verify you are here. You may
also sign up at this time if you haven't already. Matches are expected to start at 7:30pm, so if you haven't signed up and checked in by then, you will be unable to do so once matches start.
Feel free to send any questions to
<EMAIL_ADDRESS>Please complete the above form and hit submit if you are willing to lend equipment for the tourney. We need as much extra equipment as possible! :)
We are looking for anyone that is willing to lend TVs, Nintendo Gamecubes/Wiis, Wiimotes, Gamecube Controllers, and copies of Mario Kart Double Dash.
Please bring your equipment on the day of the tournament sometime between 6-6:50pm to the 1938 lounge, and we will tag your equipment before setting it up.
When you need to leave, please see me and let me know that you are leaving (and remember to take your equipment with you).
Feel free to send any questions to
<EMAIL_ADDRESS>Kings Court English College House (KCECH) is an undergraduate dormitory on the campus of the University of Pennsylvania. It's address is 3465 Sansom St,
Philadelphia PA, 19104.
The entrance is between 36th and 34th Street on Sansom, and it is closer to 36th than it is to 34th.
Since it is a Penn dorm, non-resident Penn students need their Penn Cards to gain access to the building. Non-resident Penn students without a Penn Card
and non-Penn students need a photo ID and must be signed in by a resident to gain access to the building.

View On Google Maps


Number of views:
None.
There is no fracture or destructive lesion. The vertebral bodies and posterior elements are normal. The alignment, discs, and discovertebral relationships are normal. There is no evidence of instability.
Normal cervical spine.


--- redirect_from: /ru/WinApi.html title: "ConEmu | WinApi Definition" breadcrumbs: - url: TableOfContents.html#terms title: ConEmu - url: ConEmuTerms.html title: Terms ---
Windows application programming interface.
Set of functions exposed by Windows OS to running applications.


Uncompression settings window consist of
three buttons, edit field, file paths and label.
| Item | Description |
| ... | Output directory over file dialog. |
| OK | Close window and start uncompression. |
| Cancel | Close window and return to main window. |
| Item | Description |
| Output directory | Destination location of data. |
| Item | Description |
| File paths | Without, relative and full paths. |


Emporium
home
Home
group_work
About
account_circle
Login
Select Company
NABIL Bank
Prabhu Bank
NIC Asia Bank
Analyse
News
Calendar
News
List


Edo,
First, I apologize fro my redundant posting. My thinking was that, with the pre-compiled version of NWChem bundled with ECCE6.4, my compilation problems became moot, but qualitatively differenct problem has arisen.
But the plot is thicker. I took your keen advice that I had apparently used the invalid envar LINUX_64 (then denied it in my posting! My fingers don't always follow my eye's instructions.) When I recompiled with the right envar, I got back to my original error: "undefined reference to `_gfortran_copy_string'"
That problem I've gotten the upper hand on. Scouting around with the `nm` command, I find that indeed that the libgfortran.so.3 (as supplied by gfortran v4.6.3 - the latest synaptic offers) does not contain that symbol, but the libgfortran.so.1 supplied with the pre-compiled version of ECCE6.4 does. Linking with that library, I am able to compile the NWChem source ( NWChem-src-2012-Jul-25)
My compilation works in single cpu mode (as tested with a couple of your "examples".) But I'm not out of the woods. My build also produced the `parallel.x` executable. With the self-built version 6.0 of NWChem, I am able to exploit the 4 cpus on my computer, using the command `parallel nwchem <command-file>` (and appropritate ~/pdir/nwchem.p file), with nearly 4 times better speed. Now when I try the analogous command with version 6.1 nwchem and parallel.x, I get the following messaging error:
AUTHORS & CONTRIBUTORS
----------------------
E. J. Bylaska, W. A. de Jong, N. Govind, K. Kowalski, T. P. Straatsma,
M. Valiev, H. J. J. van Dam, D. Wang, E. Apra, T. L. Windus, J. Hammond,
J. Autschbach, F. Aquino, J. Mullin, P. Nichols, S. Hirata, M. T. Hackler,
Y. Zhao, P.-D. Fan, R. J. Harrison, M. Dupuis, D. M. A. Smith, K. Glaesemann,
sock=0, pid=1, nsent=-1, len=56
1: snd_remote: writing message to socket 399999999 (0x17d783ff).
1: snd_remote: writing message to socket 399999999 (0x17d783ff).
system error message: Bad file descriptor
sock=0, pid=2, nsent=-1, len=56
3: SemWait: error from semop -1 (0xffffffffffffffff).
3: SemWait: error from semop -1 (0xffffffffffffffff).
system error message: Invalid argument
2: snd_remote: writing message to socket 399999999 (0x17d783ff).
2: snd_remote: writing message to socket 399999999 (0x17d783ff).
system error message: Bad file descriptor
^C 4: interrupt(1)
Last System Error Message from Task 0:: Numerical result out of range
WaitAll: Child (31813) finished, status=0xd (killed by signal 13).
So again I'm stuck, and need your advice.
|