Thanks, Tracy In table 2 I note that the format of date/time is still shown as YYYY-MM-DD-HH-MM. My earlier email (attached) made comment on this. Also in Table 2, note appears to have been taken of my comments regarding latitude/longitude position for Longitude only, but ignores Latitude. We must not start requiring reformatting for transmitted data that is already designed into existing shipboard equipment - PLEASE! Many thanks Brian Brian Mullan Head, Maritime Safety Services Inmarsat, 99 City Road, London EC1Y 1AX, UK Tel: +44 (0)20 7728 1464 Fax: +44 (0)20 7728 1689 Mob: +44 (0)7711 495836 www.inmarsat.com ________________________________ From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Peverett, Tracy Sent: 29 May 2007 22:27 To: ccglrit-gcclrit(a)lists.ncf.ca Subject: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Second of two e-mails As promised, attached please find the updated LRIT Communications specification. Best regards Tracy Tracy Peverett Senior Policy Analyst Canadian Coast Guard Tel: 1-613-990-4046 Fax: 1-613-998-3255 e-mail: peverettT(a)dfo-mpo.gc.ca This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. In accordance with Inmarsat Information Security Policy and Guidelines on Computer use, emails sent or received may be monitored. Inmarsat plc, Registered No 4886072 and Inmarsat Global Limited, Registered No. 3675885. Both Registered in England and Wales with Registered Office at 99 City Road, London EC1Y 1AX. _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk

Craig Many thanks for your helpful response to Brian. Wearing both my hats - as intergovernmental overseer of Inmarsat's safety communication services and as the Co-ordinator I would like to enter a plea for simplicity here: meaning from my perspective I would very much prefer to see consistency with existing norms in the standards we adopt for LRIT, unless there is a compelling reason to go another way. We have unwittingly generated a number of inconsistencies in the past in IMO, we need to be sure of what we're doing here. I suspect we are seeing a clash of cultures in this, in that computer data practice may very well differ significantly from that used at the operational level in other maritime applications. I do not at present see the reasoning behind the date/time format you are adopting - given that have not participated in the deliberations of your Comms group up to now. I don't want to ask you go over old ground again just for my benefit, but I do ask that you review the logic behind what you propose so as to be sure there are sound and valid reasons for the decision you are taking in this respect. Best wishes Andy Andy Fuller Head of Operations International Mobile Satellite Organization 99 City Road, London EC1Y 1AX, UK Tel. + 44 (0) 207 728 1378 Fax + 44 (0) 207 728 1172 E-mail: andy_fuller(a)imso.org <mailto:andy_fuller@imso.org> www.imso.org <http://www.imso.org/> ________________________________ From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Hayley, Craig Sent: 31 May 2007 19:05 To: ccglrit-gcclrit(a)lists.ncf.ca Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Hi Brian, Thanks for the e-mail. I hope more people will take the time to read the documents and provide comments. I assume you are referring to the LRIT communication document. Please note the following text in the LRIT communications document: 1.1.1.1 The parameters added by the LRIT shipborne equipment include the latitude, longitude, Time Stamp when the position was generated, and the shipborne equipment identifier. The "Format" of these parameters as outlined in table 2 indicates how the parameters shall be formatted while the information is contained within the LRIT message and does not specify the format of how the shipborne equipment transmits the information. Regarding your concerns with the format of the date/time... The only difference that I can detect between the date/time you state and what is in Table 2 of the LRIT communications document is the separators ("-" versus ":") for the year, month, day, hour and minute. The separator used to separate the year, month, etc in the date stated in table 2 is not important and in no way linked to the format coming out of the shipborne equipment. The format is with respect to SOAP messages communicated along the various LRIT communication segments. CSPs for the IDC shall have to "build" SOAP messages complying with table 2 in the communications document using the format from the ship borne equipment. The important thing with the time stamp is that seconds are not transmitted. Regarding your concerns with the format for latitude... We had a discussion on your e-mail and the intention was to implement your recommendation. I can't recall why the "seconds" component of the latitude didn't change to decimal minutes with a precision of 2 decimal places. The most likely reason is that I forgot to incorporate this change in the document due to the numerous requests. My apologies on this topic. I will make the change for latitude to decimal minutes unless someone raises a compelling reason not to change. Any body from the Communications group recall if there was a specific reason why we didn't make the change (Jilian, Guy, etc.)??? I would like to high light to everyone that these documents are in constant flux as a result of many requests from different inputs at the Ad Hoc meeting. Thus, it is important to fully read the documents that come out of each meeting to ensure that any particular topic of interest is addressed in a satisfactory manner. Thanks, Craig Hayley System Engineer Canadian Coast Guard 709-772-7740 ________________________________ From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Brian Mullan Sent: Thursday, May 31, 2007 12:35 PM To: ccglrit-gcclrit(a)lists.ncf.ca Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Thanks, Tracy In table 2 I note that the format of date/time is still shown as YYYY-MM-DD-HH-MM. My earlier email (attached) made comment on this. Also in Table 2, note appears to have been taken of my comments regarding latitude/longitude position for Longitude only, but ignores Latitude. We must not start requiring reformatting for transmitted data that is already designed into existing shipboard equipment - PLEASE! Many thanks Brian Brian Mullan Head, Maritime Safety Services Inmarsat, 99 City Road, London EC1Y 1AX, UK Tel: +44 (0)20 7728 1464 Fax: +44 (0)20 7728 1689 Mob: +44 (0)7711 495836 www.inmarsat.com ________________________________ From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Peverett, Tracy Sent: 29 May 2007 22:27 To: ccglrit-gcclrit(a)lists.ncf.ca Subject: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Second of two e-mails As promised, attached please find the updated LRIT Communications specification. Best regards Tracy Tracy Peverett Senior Policy Analyst Canadian Coast Guard Tel: 1-613-990-4046 Fax: 1-613-998-3255 e-mail: peverettT(a)dfo-mpo.gc.ca This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. In accordance with Inmarsat Information Security Policy and Guidelines on Computer use, emails sent or received may be monitored. Inmarsat plc, Registered No 4886072 and Inmarsat Global Limited, Registered No. 3675885. Both Registered in England and Wales with Registered Office at 99 City Road, London EC1Y 1AX. _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk

Hi All, I'm please to see a good discussion has developed around this topic. Hopefully, more discussion on other topics in the documents will be initiated over the coming week before we meet in Hamburg. Given the e-mails on this topic, the text (including wording in the table) should be altered to eliminate any confusion. I agree that the specific data elements (latititude, longitude, year, month, day, hour, minute, unique equipment identifier) that the shipborne equipment transmits is the important information. The "format" of how those elements are displayed is accomplished by land based software (not shipborne equipment software). Essentially, an application piece of software will take those data elements, process them and display them in a given "format". It has been decided that SOAP messages (using XML format) will be the back bone of the LRIT communication system. Thus, the various data elements contained in a given LRIT message will have to be "formatted" as such. The question of whether application software residing at the CSP or ASP (not software on the shipborne equipment) begins to format the data elements into an LRIT message (SOAP using XML) as defined in the communications document is another issue. Currently, the document is written such that the CSP (for the International Data Centre case) begins to build SOAP messages and pass them to the ASP. We have to define an interface between the ASP and the CSP for the International Data Centre case. If we allowed CSPs to transmit information to the ASP using different formats, protocols, etc than it wouldn't be fair to the ASP. This would add an extra cost burden on the ASPs given that they would have to support multiple formats, protocols, etc. Please note that national data centers and regional data centers are free to define and allow different formats, protocols, etc from the CSP to the ASP. The intention of the LRIT communications document shall be to specify the data elements transmitted by the shipborne equipment as stated in Brian's previous e-mail: Shipborne Data Elements: Latitude -> degrees, minutes and decimal minutes to two decimal places N / S Longitude ->degrees, minutes and decimal minutes to two decimal places E / W Unique equipment ID -> number Year -> 4 digit year number Month -> 2 digit month number Day -> 2 digit day number Hour -> 2 digit hour number Minute -> 2 digit minute number Regards, Craig Hayley ________________________________ From: Brian Mullan [mailto:Brian_Mullan@inmarsat.com] Sent: Friday, June 01, 2007 6:18 AM To: Hayley, Craig Cc: ccglrit-gcclrit(a)lists.ncf.ca Subject: RE: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Hi, Hayley Many thanks for your email. I can agree that the text of the document is clear; but that the wording in the table is not consistent and appears even to contradict the text you quote. My copy of the document shows wording for 1.1.1.1 that is different: "The intent of this document is to outline the technical specifications for communication within the international Long-Range Identification and Tracking (LRIT) system as stated in the terms of reference of resolution MSC.211(81)." Your reference is new text in 2.2.2.4 in the copy that I received (15-02-2007 LRIT ad hoc WG) In Table 2, the heading indicates "Parameter provided by LRIT Shipborne Equipment" and then describes the various elements, including specifying the format. It is clear to me and others that this method of presenting the information in the table means that the information transmitted by the shipborne equipment *must* follow the format written in the table. This is where the difficulty lies - the wording is over-prescriptive and does not accord with the wording in 2.2.2.4. My original email showed how, in Inmarsat C position reporting at least, the way the information is transmitted. Other shipborne systems probably will have their own format for presenting data to the ASP. May I suggest, please, that we stick to requiring that the specific data elements (unique identifier, latitude/longitude and date/time of the position) are transmitted from the ship and then only start to prescribe the format for onward transmission from the ASP? In other words, as long as the shipborne equipment transmits, as a minimum, the required elements, any format is acceptable. This allows for all approved shipborne LRIT systems to be offered, no matter in which order or format the data is presented. This approach will also allow the table to be in accord with the new wording in 2.2.2.4 I hope that this is clear. Your hard work is very much appreciated and it is clearly understood that the document remains a "work in progress". Please don't take my input as criticism - it is not! All I seek is clarity of the wording for all. With best wishes Brian Brian Mullan Head, Maritime Safety Services Inmarsat, 99 City Road, London EC1Y 1AX, UK Tel: +44 (0)20 7728 1464 Fax: +44 (0)20 7728 1689 Mob: +44 (0)7711 495836 www.inmarsat.com ________________________________ From: Hayley, Craig [mailto:HayleyCR@DFO-MPO.GC.CA] Sent: 31 May 2007 19:05 To: ccglrit-gcclrit(a)lists.ncf.ca Cc: Brian Mullan Subject: RE: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Hi Brian, Thanks for the e-mail. I hope more people will take the time to read the documents and provide comments. I assume you are referring to the LRIT communication document. Please note the following text in the LRIT communications document: 1.1.1.1 The parameters added by the LRIT shipborne equipment include the latitude, longitude, Time Stamp when the position was generated, and the shipborne equipment identifier. The "Format" of these parameters as outlined in table 2 indicates how the parameters shall be formatted while the information is contained within the LRIT message and does not specify the format of how the shipborne equipment transmits the information. Regarding your concerns with the format of the date/time... The only difference that I can detect between the date/time you state and what is in Table 2 of the LRIT communications document is the separators ("-" versus ":") for the year, month, day, hour and minute. The separator used to separate the year, month, etc in the date stated in table 2 is not important and in no way linked to the format coming out of the shipborne equipment. The format is with respect to SOAP messages communicated along the various LRIT communication segments. CSPs for the IDC shall have to "build" SOAP messages complying with table 2 in the communications document using the format from the ship borne equipment. The important thing with the time stamp is that seconds are not transmitted. Regarding your concerns with the format for latitude... We had a discussion on your e-mail and the intention was to implement your recommendation. I can't recall why the "seconds" component of the latitude didn't change to decimal minutes with a precision of 2 decimal places. The most likely reason is that I forgot to incorporate this change in the document due to the numerous requests. My apologies on this topic. I will make the change for latitude to decimal minutes unless someone raises a compelling reason not to change. Any body from the Communications group recall if there was a specific reason why we didn't make the change (Jilian, Guy, etc.)??? I would like to high light to everyone that these documents are in constant flux as a result of many requests from different inputs at the Ad Hoc meeting. Thus, it is important to fully read the documents that come out of each meeting to ensure that any particular topic of interest is addressed in a satisfactory manner. Thanks, Craig Hayley System Engineer Canadian Coast Guard 709-772-7740 ________________________________ From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Brian Mullan Sent: Thursday, May 31, 2007 12:35 PM To: ccglrit-gcclrit(a)lists.ncf.ca Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Thanks, Tracy In table 2 I note that the format of date/time is still shown as YYYY-MM-DD-HH-MM. My earlier email (attached) made comment on this. Also in Table 2, note appears to have been taken of my comments regarding latitude/longitude position for Longitude only, but ignores Latitude. We must not start requiring reformatting for transmitted data that is already designed into existing shipboard equipment - PLEASE! Many thanks Brian Brian Mullan Head, Maritime Safety Services Inmarsat, 99 City Road, London EC1Y 1AX, UK Tel: +44 (0)20 7728 1464 Fax: +44 (0)20 7728 1689 Mob: +44 (0)7711 495836 www.inmarsat.com ________________________________ From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Peverett, Tracy Sent: 29 May 2007 22:27 To: ccglrit-gcclrit(a)lists.ncf.ca Subject: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Second of two e-mails As promised, attached please find the updated LRIT Communications specification. Best regards Tracy Tracy Peverett Senior Policy Analyst Canadian Coast Guard Tel: 1-613-990-4046 Fax: 1-613-998-3255 e-mail: peverettT(a)dfo-mpo.gc.ca This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. In accordance with Inmarsat Information Security Policy and Guidelines on Computer use, emails sent or received may be monitored. Inmarsat plc, Registered No 4886072 and Inmarsat Global Limited, Registered No. 3675885. Both Registered in England and Wales with Registered Office at 99 City Road, London EC1Y 1AX. _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk

You make a fair point... I would suggest other interested parties (such as ASPs wishing to bid on the ASP function for the IDC case) voice their position. If we allow CSPs to send the shipborne data to the ASP based upon any "format" or protocol than the ASP will have to absorb the cost of supporting multiple "formats" and communication protocols. The extra expense, of course, would likely be pushed back to the customers (contracting governments). This topic affects only ASPs and CSPs wishing to form the communication path to the International Data Centre (not national or regional data centers). Based upon e-mails written on this reflector and the discussion in the Hamburg meeting, the document will be aligned with the "consensus" view. Regards, Craig Hayley System Engineer Canadian Coast Guard ________________________________ From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Brian Mullan Sent: Friday, June 01, 2007 10:37 AM To: Hayley, Craig Cc: ccglrit-gcclrit(a)lists.ncf.ca Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Thanks, Craig Good clarification on the data format from the ships. However, you now infer that CSPs will perhaps be asked to format messages from ships - but not all CSPs have signed up to do this (I know of only one). It is the understanding of many CSPs that the manipulation of the "raw" data from ships starts at the ASP level. Also, the LRIT coordinator has said in the past that coordination ("oversight") starts at the ASP level. The CSP has largely been seen (until now) as purely the comms pipe that provides the LRIT data from ships to the ASP and to start involving CSPs in manipulating LRIT data would extend the oversight role. Writing in specifications for all CSPs would therefore appear to be premature! Kind regards Brian Brian Mullan Head, Maritime Safety Services Inmarsat, 99 City Road, London EC1Y 1AX, UK Tel: +44 (0)20 7728 1464 Fax: +44 (0)20 7728 1689 Mob: +44 (0)7711 495836 www.inmarsat.com ________________________________ From: Hayley, Craig [mailto:HayleyCR@DFO-MPO.GC.CA] Sent: 01 June 2007 13:52 To: Brian Mullan Cc: ccglrit-gcclrit(a)lists.ncf.ca Subject: RE: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Hi All, I'm please to see a good discussion has developed around this topic. Hopefully, more discussion on other topics in the documents will be initiated over the coming week before we meet in Hamburg. Given the e-mails on this topic, the text (including wording in the table) should be altered to eliminate any confusion. I agree that the specific data elements (latititude, longitude, year, month, day, hour, minute, unique equipment identifier) that the shipborne equipment transmits is the important information. The "format" of how those elements are displayed is accomplished by land based software (not shipborne equipment software). Essentially, an application piece of software will take those data elements, process them and display them in a given "format". It has been decided that SOAP messages (using XML format) will be the back bone of the LRIT communication system. Thus, the various data elements contained in a given LRIT message will have to be "formatted" as such. The question of whether application software residing at the CSP or ASP (not software on the shipborne equipment) begins to format the data elements into an LRIT message (SOAP using XML) as defined in the communications document is another issue. Currently, the document is written such that the CSP (for the International Data Centre case) begins to build SOAP messages and pass them to the ASP. We have to define an interface between the ASP and the CSP for the International Data Centre case. If we allowed CSPs to transmit information to the ASP using different formats, protocols, etc than it wouldn't be fair to the ASP. This would add an extra cost burden on the ASPs given that they would have to support multiple formats, protocols, etc. Please note that national data centers and regional data centers are free to define and allow different formats, protocols, etc from the CSP to the ASP. The intention of the LRIT communications document shall be to specify the data elements transmitted by the shipborne equipment as stated in Brian's previous e-mail: Shipborne Data Elements: Latitude -> degrees, minutes and decimal minutes to two decimal places N / S Longitude ->degrees, minutes and decimal minutes to two decimal places E / W Unique equipment ID -> number Year -> 4 digit year number Month -> 2 digit month number Day -> 2 digit day number Hour -> 2 digit hour number Minute -> 2 digit minute number Regards, Craig Hayley ________________________________ From: Brian Mullan [mailto:Brian_Mullan@inmarsat.com] Sent: Friday, June 01, 2007 6:18 AM To: Hayley, Craig Cc: ccglrit-gcclrit(a)lists.ncf.ca Subject: RE: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Hi, Hayley Many thanks for your email. I can agree that the text of the document is clear; but that the wording in the table is not consistent and appears even to contradict the text you quote. My copy of the document shows wording for 1.1.1.1 that is different: "The intent of this document is to outline the technical specifications for communication within the international Long-Range Identification and Tracking (LRIT) system as stated in the terms of reference of resolution MSC.211(81)." Your reference is new text in 2.2.2.4 in the copy that I received (15-02-2007 LRIT ad hoc WG) In Table 2, the heading indicates "Parameter provided by LRIT Shipborne Equipment" and then describes the various elements, including specifying the format. It is clear to me and others that this method of presenting the information in the table means that the information transmitted by the shipborne equipment *must* follow the format written in the table. This is where the difficulty lies - the wording is over-prescriptive and does not accord with the wording in 2.2.2.4. My original email showed how, in Inmarsat C position reporting at least, the way the information is transmitted. Other shipborne systems probably will have their own format for presenting data to the ASP. May I suggest, please, that we stick to requiring that the specific data elements (unique identifier, latitude/longitude and date/time of the position) are transmitted from the ship and then only start to prescribe the format for onward transmission from the ASP? In other words, as long as the shipborne equipment transmits, as a minimum, the required elements, any format is acceptable. This allows for all approved shipborne LRIT systems to be offered, no matter in which order or format the data is presented. This approach will also allow the table to be in accord with the new wording in 2.2.2.4 I hope that this is clear. Your hard work is very much appreciated and it is clearly understood that the document remains a "work in progress". Please don't take my input as criticism - it is not! All I seek is clarity of the wording for all. With best wishes Brian Brian Mullan Head, Maritime Safety Services Inmarsat, 99 City Road, London EC1Y 1AX, UK Tel: +44 (0)20 7728 1464 Fax: +44 (0)20 7728 1689 Mob: +44 (0)7711 495836 www.inmarsat.com ________________________________ From: Hayley, Craig [mailto:HayleyCR@DFO-MPO.GC.CA] Sent: 31 May 2007 19:05 To: ccglrit-gcclrit(a)lists.ncf.ca Cc: Brian Mullan Subject: RE: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Hi Brian, Thanks for the e-mail. I hope more people will take the time to read the documents and provide comments. I assume you are referring to the LRIT communication document. Please note the following text in the LRIT communications document: 1.1.1.1 The parameters added by the LRIT shipborne equipment include the latitude, longitude, Time Stamp when the position was generated, and the shipborne equipment identifier. The "Format" of these parameters as outlined in table 2 indicates how the parameters shall be formatted while the information is contained within the LRIT message and does not specify the format of how the shipborne equipment transmits the information. Regarding your concerns with the format of the date/time... The only difference that I can detect between the date/time you state and what is in Table 2 of the LRIT communications document is the separators ("-" versus ":") for the year, month, day, hour and minute. The separator used to separate the year, month, etc in the date stated in table 2 is not important and in no way linked to the format coming out of the shipborne equipment. The format is with respect to SOAP messages communicated along the various LRIT communication segments. CSPs for the IDC shall have to "build" SOAP messages complying with table 2 in the communications document using the format from the ship borne equipment. The important thing with the time stamp is that seconds are not transmitted. Regarding your concerns with the format for latitude... We had a discussion on your e-mail and the intention was to implement your recommendation. I can't recall why the "seconds" component of the latitude didn't change to decimal minutes with a precision of 2 decimal places. The most likely reason is that I forgot to incorporate this change in the document due to the numerous requests. My apologies on this topic. I will make the change for latitude to decimal minutes unless someone raises a compelling reason not to change. Any body from the Communications group recall if there was a specific reason why we didn't make the change (Jilian, Guy, etc.)??? I would like to high light to everyone that these documents are in constant flux as a result of many requests from different inputs at the Ad Hoc meeting. Thus, it is important to fully read the documents that come out of each meeting to ensure that any particular topic of interest is addressed in a satisfactory manner. Thanks, Craig Hayley System Engineer Canadian Coast Guard 709-772-7740 ________________________________ From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Brian Mullan Sent: Thursday, May 31, 2007 12:35 PM To: ccglrit-gcclrit(a)lists.ncf.ca Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Thanks, Tracy In table 2 I note that the format of date/time is still shown as YYYY-MM-DD-HH-MM. My earlier email (attached) made comment on this. Also in Table 2, note appears to have been taken of my comments regarding latitude/longitude position for Longitude only, but ignores Latitude. We must not start requiring reformatting for transmitted data that is already designed into existing shipboard equipment - PLEASE! Many thanks Brian Brian Mullan Head, Maritime Safety Services Inmarsat, 99 City Road, London EC1Y 1AX, UK Tel: +44 (0)20 7728 1464 Fax: +44 (0)20 7728 1689 Mob: +44 (0)7711 495836 www.inmarsat.com ________________________________ From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Peverett, Tracy Sent: 29 May 2007 22:27 To: ccglrit-gcclrit(a)lists.ncf.ca Subject: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Second of two e-mails As promised, attached please find the updated LRIT Communications specification. Best regards Tracy Tracy Peverett Senior Policy Analyst Canadian Coast Guard Tel: 1-613-990-4046 Fax: 1-613-998-3255 e-mail: peverettT(a)dfo-mpo.gc.ca This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. In accordance with Inmarsat Information Security Policy and Guidelines on Computer use, emails sent or received may be monitored. Inmarsat plc, Registered No 4886072 and Inmarsat Global Limited, Registered No. 3675885. Both Registered in England and Wales with Registered Office at 99 City Road, London EC1Y 1AX. _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk

Jeff, Thanks for the e-mail. There is alot of information in the e-mail and it will certainly provide for useful discussion at the Hamburg meeting. Given that the intent of the LRIT communications document is to add technical details to the basic functions outlined in the Performance Standards, it seems a good idea to add some boundaries to the communication link between the CSP entity and the ASP entity. Ignoring this communication link in the communications document or simply implementing a "anything goes" strategy seems dangerous. If the CSP entity takes the "raw" payload from the shipborne equipment and does not format any of the information before it is sent to the ASP than that seems ok (We can modify document text to handle this). However, I think the delivery mechanism(s) that the CSP uses to send the information to the ASP should be specified. We should at least list acceptable mechanisms and ensure some standard level of data security. If I understand correctly (maybe I don't), many CSPs deliver data information (such as shipborne location co-ordinates) to the associated ASP over the internet. Thus, application software at the CSP would have to build IP packets with the "raw data" from the shipborne equipment as the payload. If the CSP entity can build IP packets than why can't it build SOAP messages with the "raw data" as the payload? Jeff: I would be interested in chatting with you via phone early next week if you are available and willing? Thanks, Craig Hayley System Engineer Candian Coast Guard ________________________________ From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Jeff Douglas Sent: Friday, June 01, 2007 2:02 PM To: ccglrit-gcclrit(a)lists.ncf.ca Cc: 'Jeff Chandler'; 'Iain Hayes' Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Craig I'm sorry that I missed the June meetings there - so please excuse any duplication or overlap below as the topics may have been discussed during the working groups. Some thoughts on the question of how data formats arise, and the appropriate point within the LRIT Infrastructure follows: As a practical matter many ASPs today support most, if not all, of the satellite providers likely to meet the performance standards for LRIT (and thus be potentially CSPs or support CSPs). Therefore I would disagree that this aspect is overly burdensome. Converting data is not, in context, likely to determine the success or failure of an ASP considering all other factors within an ASP's list of responsibilities (securing customers, maintaining a data center, certification into LRIT). However; in our view that discussion itself is rendered moot by the bigger question of what is technically feasible for a CSP. The view here is that CSPs will be unable to convert data to the proposed format (or any other standard format for that matter). Each CSP provides a communications path via a specific satellite network. However CSPs do not, in most instances, have knowledge of payload interpretation, protocol or format of the data exchanged between the ASP and the Shipboard Equipment. Such aspects are handled by firmware, scripting or other configuration mechanisms that are specific to each equipment vendor. Hence the data transmitted via any given CSP may vary from device-to-device and change over time as new software or firmware revisions are made to the onboard equipment. To our knowledge, all potential CSPs provide flexibility in the representation of the LRIT requirements over their networks (e.g. the raw encoding of a position report). Most potential CSPs also provide several different delivery mechanisms which are proven both technically and commercially. As the CSP cannot generally control the scripting/firmware/configuration options present on each piece of Shipboard Equipment it becomes technically infeasible to assign any data translation capabilities to the CSP. Furthermore; even if a CSP did have knowledge of the payload protocol - and thus could translate it - that approach may have unintended consequences. If would lead to a lowest-common-denominator approach within the data available to ASPs. Shipboard Equipment and CSPs often make data available in addition to the fields required for LRIT. We anticipate that ASPs are likely to use this additional data to offer services complementary to LRIT - in terms of their offerings to fleet owners and operators. Consequently; we do not believe that it is desirable for a CSP to remove all additional data as that would limit the overall utility of the LRIT system to fleet owners and operators. Such a step would also reduce the commercial opportunities available to ASPs. Our view is that the earliest point in the LRIT infrastructure where sufficient information is available to standardize a format is at the ASP. Of note the ability to satisfy the Performance Standards arises through the use of two system components in conjunction: a) Shipboard equipment; including configuration options (scripts, firmware versions etc) b) The CSP; including the account configuration and selected delivery formats etc (i.e. VPN, Internet, header formats) There are two additional notes here - to avoid potential misinterpretation of the above: 1) A CSP may also act as an ASP. In that case the ASP+CSP can take responsibility for the configuration of shipboard equipment - and thus is able interpret the payload data fully within the ASP aspects of its dual role. 2) It may initially appear that Inmarsat-C equipment operating in according to the baseline PDR specifications is an exception - as this is a rare case of a network operating defining a position reporting protocol. However; it should be noted that most deployed Inmarsat-C equipment extends the Inmarsat-C baseline standards in vendor proprietary ways - and this is specifically allowed within the Inmarsat-C baseline PDR specifications. 3) Finally; any translation to a common format could not be performed once per "physical" satellite network. The "CSP" for example in Inmarsat could be a Land Earth Station operator, other distribution partner or Virtual Network Operator (i.e. Inmarsat-D+). The same comment applies to other satellite providers who elect to have distribution partner(s) act as the CSP. It should be noted that this may be required by the telecommunications regulators in some countries (where a specific legal entity or reseller holds the concession to land traffic from a given network within a defined country). Consequently, care should be taken here not to equate "CSP" in the LRIT lexicon with "Satellite Network" in the sense of the physical satellite constellations available - there may be many CSPs sharing the same physical satellite network. Hence the apparent simplicity of the "one-CSP" vs. "many-ASP" argument falls down. It is actually quite possible that there would be fewer ASPs than CSPs in practice once LRIT is deployed. Best Regards Jeff Douglas Director ABSOLUTE SOFTWARE INC www.absolutesw.com <http://www.absolutesw.com/> ________________________________ From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Hayley, Craig Sent: Friday, June 01, 2007 09:43 To: ccglrit-gcclrit(a)lists.ncf.ca Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany You make a fair point... I would suggest other interested parties (such as ASPs wishing to bid on the ASP function for the IDC case) voice their position. If we allow CSPs to send the shipborne data to the ASP based upon any "format" or protocol than the ASP will have to absorb the cost of supporting multiple "formats" and communication protocols. The extra expense, of course, would likely be pushed back to the customers (contracting governments). This topic affects only ASPs and CSPs wishing to form the communication path to the International Data Centre (not national or regional data centers). Based upon e-mails written on this reflector and the discussion in the Hamburg meeting, the document will be aligned with the "consensus" view. Regards, Craig Hayley System Engineer Canadian Coast Guard ________________________________ From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Brian Mullan Sent: Friday, June 01, 2007 10:37 AM To: Hayley, Craig Cc: ccglrit-gcclrit(a)lists.ncf.ca Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Thanks, Craig Good clarification on the data format from the ships. However, you now infer that CSPs will perhaps be asked to format messages from ships - but not all CSPs have signed up to do this (I know of only one). It is the understanding of many CSPs that the manipulation of the "raw" data from ships starts at the ASP level. Also, the LRIT coordinator has said in the past that coordination ("oversight") starts at the ASP level. The CSP has largely been seen (until now) as purely the comms pipe that provides the LRIT data from ships to the ASP and to start involving CSPs in manipulating LRIT data would extend the oversight role. Writing in specifications for all CSPs would therefore appear to be premature! Kind regards Brian Brian Mullan Head, Maritime Safety Services Inmarsat, 99 City Road, London EC1Y 1AX, UK Tel: +44 (0)20 7728 1464 Fax: +44 (0)20 7728 1689 Mob: +44 (0)7711 495836 www.inmarsat.com ________________________________ From: Hayley, Craig [mailto:HayleyCR@DFO-MPO.GC.CA] Sent: 01 June 2007 13:52 To: Brian Mullan Cc: ccglrit-gcclrit(a)lists.ncf.ca Subject: RE: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Hi All, I'm please to see a good discussion has developed around this topic. Hopefully, more discussion on other topics in the documents will be initiated over the coming week before we meet in Hamburg. Given the e-mails on this topic, the text (including wording in the table) should be altered to eliminate any confusion. I agree that the specific data elements (latititude, longitude, year, month, day, hour, minute, unique equipment identifier) that the shipborne equipment transmits is the important information. The "format" of how those elements are displayed is accomplished by land based software (not shipborne equipment software). Essentially, an application piece of software will take those data elements, process them and display them in a given "format". It has been decided that SOAP messages (using XML format) will be the back bone of the LRIT communication system. Thus, the various data elements contained in a given LRIT message will have to be "formatted" as such. The question of whether application software residing at the CSP or ASP (not software on the shipborne equipment) begins to format the data elements into an LRIT message (SOAP using XML) as defined in the communications document is another issue. Currently, the document is written such that the CSP (for the International Data Centre case) begins to build SOAP messages and pass them to the ASP. We have to define an interface between the ASP and the CSP for the International Data Centre case. If we allowed CSPs to transmit information to the ASP using different formats, protocols, etc than it wouldn't be fair to the ASP. This would add an extra cost burden on the ASPs given that they would have to support multiple formats, protocols, etc. Please note that national data centers and regional data centers are free to define and allow different formats, protocols, etc from the CSP to the ASP. The intention of the LRIT communications document shall be to specify the data elements transmitted by the shipborne equipment as stated in Brian's previous e-mail: Shipborne Data Elements: Latitude -> degrees, minutes and decimal minutes to two decimal places N / S Longitude ->degrees, minutes and decimal minutes to two decimal places E / W Unique equipment ID -> number Year -> 4 digit year number Month -> 2 digit month number Day -> 2 digit day number Hour -> 2 digit hour number Minute -> 2 digit minute number Regards, Craig Hayley ________________________________ From: Brian Mullan [mailto:Brian_Mullan@inmarsat.com] Sent: Friday, June 01, 2007 6:18 AM To: Hayley, Craig Cc: ccglrit-gcclrit(a)lists.ncf.ca Subject: RE: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Hi, Hayley Many thanks for your email. I can agree that the text of the document is clear; but that the wording in the table is not consistent and appears even to contradict the text you quote. My copy of the document shows wording for 1.1.1.1 that is different: "The intent of this document is to outline the technical specifications for communication within the international Long-Range Identification and Tracking (LRIT) system as stated in the terms of reference of resolution MSC.211(81)." Your reference is new text in 2.2.2.4 in the copy that I received (15-02-2007 LRIT ad hoc WG) In Table 2, the heading indicates "Parameter provided by LRIT Shipborne Equipment" and then describes the various elements, including specifying the format. It is clear to me and others that this method of presenting the information in the table means that the information transmitted by the shipborne equipment *must* follow the format written in the table. This is where the difficulty lies - the wording is over-prescriptive and does not accord with the wording in 2.2.2.4. My original email showed how, in Inmarsat C position reporting at least, the way the information is transmitted. Other shipborne systems probably will have their own format for presenting data to the ASP. May I suggest, please, that we stick to requiring that the specific data elements (unique identifier, latitude/longitude and date/time of the position) are transmitted from the ship and then only start to prescribe the format for onward transmission from the ASP? In other words, as long as the shipborne equipment transmits, as a minimum, the required elements, any format is acceptable. This allows for all approved shipborne LRIT systems to be offered, no matter in which order or format the data is presented. This approach will also allow the table to be in accord with the new wording in 2.2.2.4 I hope that this is clear. Your hard work is very much appreciated and it is clearly understood that the document remains a "work in progress". Please don't take my input as criticism - it is not! All I seek is clarity of the wording for all. With best wishes Brian Brian Mullan Head, Maritime Safety Services Inmarsat, 99 City Road, London EC1Y 1AX, UK Tel: +44 (0)20 7728 1464 Fax: +44 (0)20 7728 1689 Mob: +44 (0)7711 495836 www.inmarsat.com ________________________________ From: Hayley, Craig [mailto:HayleyCR@DFO-MPO.GC.CA] Sent: 31 May 2007 19:05 To: ccglrit-gcclrit(a)lists.ncf.ca Cc: Brian Mullan Subject: RE: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Hi Brian, Thanks for the e-mail. I hope more people will take the time to read the documents and provide comments. I assume you are referring to the LRIT communication document. Please note the following text in the LRIT communications document: 1.1.1.1 The parameters added by the LRIT shipborne equipment include the latitude, longitude, Time Stamp when the position was generated, and the shipborne equipment identifier. The "Format" of these parameters as outlined in table 2 indicates how the parameters shall be formatted while the information is contained within the LRIT message and does not specify the format of how the shipborne equipment transmits the information. Regarding your concerns with the format of the date/time... The only difference that I can detect between the date/time you state and what is in Table 2 of the LRIT communications document is the separators ("-" versus ":") for the year, month, day, hour and minute. The separator used to separate the year, month, etc in the date stated in table 2 is not important and in no way linked to the format coming out of the shipborne equipment. The format is with respect to SOAP messages communicated along the various LRIT communication segments. CSPs for the IDC shall have to "build" SOAP messages complying with table 2 in the communications document using the format from the ship borne equipment. The important thing with the time stamp is that seconds are not transmitted. Regarding your concerns with the format for latitude... We had a discussion on your e-mail and the intention was to implement your recommendation. I can't recall why the "seconds" component of the latitude didn't change to decimal minutes with a precision of 2 decimal places. The most likely reason is that I forgot to incorporate this change in the document due to the numerous requests. My apologies on this topic. I will make the change for latitude to decimal minutes unless someone raises a compelling reason not to change. Any body from the Communications group recall if there was a specific reason why we didn't make the change (Jilian, Guy, etc.)??? I would like to high light to everyone that these documents are in constant flux as a result of many requests from different inputs at the Ad Hoc meeting. Thus, it is important to fully read the documents that come out of each meeting to ensure that any particular topic of interest is addressed in a satisfactory manner. Thanks, Craig Hayley System Engineer Canadian Coast Guard 709-772-7740 ________________________________ From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Brian Mullan Sent: Thursday, May 31, 2007 12:35 PM To: ccglrit-gcclrit(a)lists.ncf.ca Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Thanks, Tracy In table 2 I note that the format of date/time is still shown as YYYY-MM-DD-HH-MM. My earlier email (attached) made comment on this. Also in Table 2, note appears to have been taken of my comments regarding latitude/longitude position for Longitude only, but ignores Latitude. We must not start requiring reformatting for transmitted data that is already designed into existing shipboard equipment - PLEASE! Many thanks Brian Brian Mullan Head, Maritime Safety Services Inmarsat, 99 City Road, London EC1Y 1AX, UK Tel: +44 (0)20 7728 1464 Fax: +44 (0)20 7728 1689 Mob: +44 (0)7711 495836 www.inmarsat.com ________________________________ From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Peverett, Tracy Sent: 29 May 2007 22:27 To: ccglrit-gcclrit(a)lists.ncf.ca Subject: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Second of two e-mails As promised, attached please find the updated LRIT Communications specification. Best regards Tracy Tracy Peverett Senior Policy Analyst Canadian Coast Guard Tel: 1-613-990-4046 Fax: 1-613-998-3255 e-mail: peverettT(a)dfo-mpo.gc.ca This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. In accordance with Inmarsat Information Security Policy and Guidelines on Computer use, emails sent or received may be monitored. Inmarsat plc, Registered No 4886072 and Inmarsat Global Limited, Registered No. 3675885. Both Registered in England and Wales with Registered Office at 99 City Road, London EC1Y 1AX. _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk

Craig I agree with Jeff and Ralf. We should keep well out of specifying any formats or procedures for the CSP. To do so will slow down and damage development of the system. Andy Andy Fuller Head of Operations International Mobile Satellite Organization 99 City Road, London EC1Y 1AX, UK Tel. + 44 (0) 207 728 1378 Fax + 44 (0) 207 728 1172 E-mail: andy_fuller(a)imso.org www.imso.org -----Original Message----- From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Ralf-Dieter Preuss Sent: 04 June 2007 13:40 To: ccglrit-gcclrit(a)lists.ncf.ca Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Craig, I agree with Jeff: and everything beyond the DC is up to the contracting government; it is not necessary and maybe even not helpful if we specified the interface between CSP and ASP. The format used between ASP and DC could be quite the same as described in the COMMs paper; at least that is what is beeing discussed here with companies interested in the CSP/ASP services. Best regards Ralf --------------------------------------------------------- Bundesamt fuer Seeschifffahrt und Hydrographie (BSH) Ralf-Dieter Preuss (S3) Bernhard-Nocht-Str. 78 Tel: +49 (0) 40 3190-7300 20359 Hamburg Fax: +49 (0) 40 3190-5000 http://www.bsh.de/ email: ralf-dieter.preuss(a)bsh.de --------------------------------------------------------- Jeff Douglas schrieb: Infrastructure not, LRIT). technically data - limit to ASP. through of in example land with LRIT ------------------------------------------------------------------------ Craig (such their cost extra communication view. ------------------------------------------------------------------------ Mullan said The CSPs ------------------------------------------------------------------------ "format" application messages (for ASP ------------------------------------------------------------------------ is specifications and resolution Shipborne is probably data prescribe long format in progress". ------------------------------------------------------------------------ the these be and the ("-" the equipment. transmitted. decimal the interest ------------------------------------------------------------------------ Mullan Also ------------------------------------------------------------------------ Tracy are Policy ------------------------------------------------------------------------ _______________________________________________ Ccglrit-gcclrit mailing list Ccglrit-gcclrit(a)lists.ncf.ca http://lists.ncf.ca/mailman/listinfo/ccglrit-gcclrit _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk

Thanks, Craig There may be a slight disconnect in the definition of a CSP. A CSP can only be the likes of Inmarsat and Iridium, as satellite communications service providers. No other entity, other than perhaps Globe Wireless as an HF radio communications service provider, can be a CSP in the LRIT system Regards Brian Brian Mullan Head, Maritime Safety Services Inmarsat, 99 City Road, London EC1Y 1AX, UK Tel: +44 (0)20 7728 1464 Fax: +44 (0)20 7728 1689 Mob: +44 (0)7711 495836 www.inmarsat.com -----Original Message----- From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Hayley, Craig Sent: 04 June 2007 15:18 To: ccglrit-gcclrit(a)lists.ncf.ca Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany All, If we do not specify the interface between the CSP and the ASP than the ASP will have to accept any deliver mechanism (or payload format for that matter) that any CSP outputs. Thus, ASPs will be responsible for accepting quite a variety of interface protocols. This will include not only standard commercial interfaces that are being used by commercial ASPs and CSPs today, but potentially also interfaces from contracting governments "entities" that are acting as CSPs. Consider the following scenario... A contract government with some sort of Vessel Monitoring system (VMS) that is not interested in LRIT but understands it has to comply with IMO regulation. It chooses to call a subsection of its VMS system a CSP and informs the LRIT Co-ordinator that its CSP (and its flag ships) will connect to an ASP connected to the International Data Centre. Given that the CSP to ASP interface is not specified in the LRIT communications document, the ASP is compelled to accept a potentially non commercially available unique interface from the contract government's CSP. If this scenario repeats itself with other contracting governments than the ASPs could be in for an expensive design process. Based upon the text in the LRIT performance standards, it would seem that a contracting government could define an internal "entity" as a CSP and wish it to connect to an ASP connected to the International Data Centre. Given the various views and the desire to protect the ASPs from having to accept "any" interface, I will suggest the following to the group. Text will be added such that ASPs and CSPs can form an "informal" partnership if both entities agree to each others terms. An "informal" partnership could be as simple as exchanging letters. The communication interface between the CSP and ASP in such a situation will be deemed an internal communication link and will not be subject to "specific" communication protocols and formats. The communication link, of course, would have to adhere to the LRIT performance standards and "generic" functional standards described in the Communications document. The communications document will continue to provide some boundaries and specific specifications to the CSP to ASP interface for ASPs and CSPs that do not have "informal" partnerships. We can discuss in Hamburg next week. I may touch base via phone with some members to discuss this issue. Regards, Craig Hayley System Engineer 709-772-7740 -----Original Message----- From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Andy Fuller Sent: Monday, June 04, 2007 10:30 AM To: ccglrit-gcclrit(a)lists.ncf.ca Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Craig I agree with Jeff and Ralf. We should keep well out of specifying any formats or procedures for the CSP. To do so will slow down and damage development of the system. Andy Andy Fuller Head of Operations International Mobile Satellite Organization 99 City Road, London EC1Y 1AX, UK Tel. + 44 (0) 207 728 1378 Fax + 44 (0) 207 728 1172 E-mail: andy_fuller(a)imso.org www.imso.org -----Original Message----- From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Ralf-Dieter Preuss Sent: 04 June 2007 13:40 To: ccglrit-gcclrit(a)lists.ncf.ca Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Craig, I agree with Jeff: and LRIT is deployed. everything beyond the DC is up to the contracting government; it is not necessary and maybe even not helpful if we specified the interface between CSP and ASP. The format used between ASP and DC could be quite the same as described in the COMMs paper; at least that is what is beeing discussed here with companies interested in the CSP/ASP services. Best regards Ralf --------------------------------------------------------- Bundesamt fuer Seeschifffahrt und Hydrographie (BSH) Ralf-Dieter Preuss (S3) Bernhard-Nocht-Str. 78 Tel: +49 (0) 40 3190-7300 20359 Hamburg Fax: +49 (0) 40 3190-5000 http://www.bsh.de/ email: ralf-dieter.preuss(a)bsh.de --------------------------------------------------------- Jeff Douglas schrieb: Infrastructure not, LRIT). technically data - limit to ASP. through of in example land with LRIT ------------------------------------------------------------------------ Craig (such their cost extra communication view. ------------------------------------------------------------------------ Mullan said The CSPs ------------------------------------------------------------------------ "format" application messages (for ASP ------------------------------------------------------------------------ is specifications and resolution Shipborne is probably data prescribe long format in progress". ------------------------------------------------------------------------ the these be and the ("-" the equipment. transmitted. decimal the interest ------------------------------------------------------------------------ Mullan Also ------------------------------------------------------------------------ Tracy are Policy ------------------------------------------------------------------------ _______________________________________________ Ccglrit-gcclrit mailing list Ccglrit-gcclrit(a)lists.ncf.ca http://lists.ncf.ca/mailman/listinfo/ccglrit-gcclrit _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk _______________________________________________ Ccglrit-gcclrit mailing list Ccglrit-gcclrit(a)lists.ncf.ca http://lists.ncf.ca/mailman/listinfo/ccglrit-gcclrit _______________________________________________ Ccglrit-gcclrit mailing list Ccglrit-gcclrit(a)lists.ncf.ca http://lists.ncf.ca/mailman/listinfo/ccglrit-gcclrit _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk

Craig The scenario you raise is worth considering further - as it raises important issues outside the direct scope of the CSP/ASP data formats. If I understand correctly, you describe a flag state with vessels participating in LRIT on the following basis: 1) The flag state elects to use the IDC. 2) The flag state specifies the CSP(s) (or) Has its own CSP (i.e. a state telecommunications provider) 3) Step (2) inherently restricts the selection/configuration of shipboard equipment for vessels of that flag who must participate in LRIT. In such circumstances we believe the flag state should be certified as an ASP. If the flag state wishes to manage the Vessel Based Equipment Configuration and the CSP(s) it inherently takes on the dual role of CSP+ASP. Such a process is specifically allowed within the LRIT Performance Standard. Looking through your e-mail, I believe the key aspect on which our interpretation differs is the Flag State and ASP responsibilities. We don't see flag states being able to *compel* all ASPs to support all CSPs (and by extension all variations of Vessel Based Equipment). Specifically; our view differs in respect of the following points from your e-mail: for that matter) that any CSP outputs" unique interface from the contract government's CSP" To allow such an approach would pose open ended technical and contractual obligations on ASPs. Also, standardizing the header formats or delivery mechanisms would not resolve those issues as there remain technical (vessel equipment configurations), commercial and contractual barriers (as Andy Fuller pointed out). It seems to us that each flag state should determine how it participates within LRIT - and take responsibility for that process. The first decision is whether to participate as a Data Center (DC) or through the International Data Center (IDC). If using the IDC then we understand each flag state would nominate the list of approved ASP(s) to register vessels under that flag. For example; a flag state may wish to provide its own ASP. Alternatively; the flag state may wish certify one or more approved ASP(s) to act on its behalf in registering and tracking vessels. However, it's important to note that an ASP should not be able to register vessels against a flag state *without prior permission* from that flag state. Otherwise we would run into a thicket of regulatory and security issues with the LRIT system. So, in that regard, we see the IDC as needing to maintain a list of approved ASP(s) on a per-flag basis and maintaining system security on that basis. Best Regards Jeff Douglas -----Original Message----- From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Hayley, Craig Sent: Monday, June 04, 2007 10:18 To: ccglrit-gcclrit(a)lists.ncf.ca Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany All, If we do not specify the interface between the CSP and the ASP than the ASP will have to accept any deliver mechanism (or payload format for that matter) that any CSP outputs. Thus, ASPs will be responsible for accepting quite a variety of interface protocols. This will include not only standard commercial interfaces that are being used by commercial ASPs and CSPs today, but potentially also interfaces from contracting governments "entities" that are acting as CSPs. Consider the following scenario... A contract government with some sort of Vessel Monitoring system (VMS) that is not interested in LRIT but understands it has to comply with IMO regulation. It chooses to call a subsection of its VMS system a CSP and informs the LRIT Co-ordinator that its CSP (and its flag ships) will connect to an ASP connected to the International Data Centre. Given that the CSP to ASP interface is not specified in the LRIT communications document, the ASP is compelled to accept a potentially non commercially available unique interface from the contract government's CSP. If this scenario repeats itself with other contracting governments than the ASPs could be in for an expensive design process. Based upon the text in the LRIT performance standards, it would seem that a contracting government could define an internal "entity" as a CSP and wish it to connect to an ASP connected to the International Data Centre. Given the various views and the desire to protect the ASPs from having to accept "any" interface, I will suggest the following to the group. Text will be added such that ASPs and CSPs can form an "informal" partnership if both entities agree to each others terms. An "informal" partnership could be as simple as exchanging letters. The communication interface between the CSP and ASP in such a situation will be deemed an internal communication link and will not be subject to "specific" communication protocols and formats. The communication link, of course, would have to adhere to the LRIT performance standards and "generic" functional standards described in the Communications document. The communications document will continue to provide some boundaries and specific specifications to the CSP to ASP interface for ASPs and CSPs that do not have "informal" partnerships. We can discuss in Hamburg next week. I may touch base via phone with some members to discuss this issue. Regards, Craig Hayley System Engineer 709-772-7740 -----Original Message----- From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Andy Fuller Sent: Monday, June 04, 2007 10:30 AM To: ccglrit-gcclrit(a)lists.ncf.ca Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Craig I agree with Jeff and Ralf. We should keep well out of specifying any formats or procedures for the CSP. To do so will slow down and damage development of the system. Andy Andy Fuller Head of Operations International Mobile Satellite Organization 99 City Road, London EC1Y 1AX, UK Tel. + 44 (0) 207 728 1378 Fax + 44 (0) 207 728 1172 E-mail: andy_fuller(a)imso.org www.imso.org -----Original Message----- From: ccglrit-gcclrit-bounces(a)lists.ncf.ca [mailto:ccglrit-gcclrit-bounces@lists.ncf.ca] On Behalf Of Ralf-Dieter Preuss Sent: 04 June 2007 13:40 To: ccglrit-gcclrit(a)lists.ncf.ca Subject: Re: [Ccglrit-gcclrit] June 12-14 meeting of the Ad hoc Working Group onEngineering Aspects of LRIT, Hamburg Germany Craig, I agree with Jeff: and LRIT is deployed. everything beyond the DC is up to the contracting government; it is not necessary and maybe even not helpful if we specified the interface between CSP and ASP. The format used between ASP and DC could be quite the same as described in the COMMs paper; at least that is what is beeing discussed here with companies interested in the CSP/ASP services. Best regards Ralf --------------------------------------------------------- Bundesamt fuer Seeschifffahrt und Hydrographie (BSH) Ralf-Dieter Preuss (S3) Bernhard-Nocht-Str. 78 Tel: +49 (0) 40 3190-7300 20359 Hamburg Fax: +49 (0) 40 3190-5000 http://www.bsh.de/ email: ralf-dieter.preuss(a)bsh.de --------------------------------------------------------- Jeff Douglas schrieb: Infrastructure not, LRIT). technically data - limit to ASP. through of in example land with LRIT ------------------------------------------------------------------------ Craig (such their cost extra communication view. ------------------------------------------------------------------------ Mullan said The CSPs ------------------------------------------------------------------------ "format" application messages (for ASP ------------------------------------------------------------------------ is specifications and resolution Shipborne is probably data prescribe long format in progress". ------------------------------------------------------------------------ the these be and the ("-" the equipment. transmitted. decimal the interest ------------------------------------------------------------------------ Mullan Also ------------------------------------------------------------------------ Tracy are Policy ------------------------------------------------------------------------ _______________________________________________ Ccglrit-gcclrit mailing list Ccglrit-gcclrit(a)lists.ncf.ca http://lists.ncf.ca/mailman/listinfo/ccglrit-gcclrit _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk _______________________________________________ Ccglrit-gcclrit mailing list Ccglrit-gcclrit(a)lists.ncf.ca http://lists.ncf.ca/mailman/listinfo/ccglrit-gcclrit _______________________________________________ Ccglrit-gcclrit mailing list Ccglrit-gcclrit(a)lists.ncf.ca http://lists.ncf.ca/mailman/listinfo/ccglrit-gcclrit