idnits 2.17.00 (12 Aug 2021) /tmp/idnits15093/draft-cuellar-geopriv-lo-ml-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 45 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 30 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 6914 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0-9' on line 1485 -- Looks like a reference, but probably isn't: '0-2' on line 1485 -- Looks like a reference, but probably isn't: '0-5' on line 1485 == Outdated reference: draft-ietf-geopriv-reqs has been published as RFC 3693 ** Downref: Normative reference to an Informational draft: draft-ietf-geopriv-reqs (ref. '3') Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. Cuellar 3 Document: draft-cuellar-geopriv-lo-ml-01.txt C. Guenther 4 Siemens AG 6 Expires in six months June 2003 8 Geopriv Location Object Markup Language 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2003). All Rights Reserved. 34 Abstract 36 This draft presents and illustrates a foundational version of an 37 markup language suitable for representing the Geopriv Location 38 Object. This language is defined by means of an XML schema. In 39 addition, we compile a list of open issues that the Geopriv Working 40 Group must solve in order to allow for precise definitions of 41 Location Object data formats. 43 Conventions used in this document 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC-2119 [2]. 49 Cuellar, Guenther Expires - December 2003 1 50 Table of Contents 52 1. Introduction...................................................2 53 2. Geopriv LO Markup Language.....................................3 54 2.1. Overview..................................................3 55 2.2. Schema Element Start Tag..................................4 56 2.3. LO Element................................................4 57 2.4. Target Element............................................5 58 2.5. Device Element............................................6 59 2.6. RM Element................................................8 60 2.7. LR Element................................................9 61 2.8. LR Credential Element....................................10 62 2.9. LR PoP Element...........................................11 63 2.10. Rule Element............................................12 64 2.11. Location Element........................................13 65 2.11.1. Latitude, Longitude, Altitude and Precision........15 66 2.11.2. Civil..............................................16 67 2.11.3. Time Zone..........................................17 68 2.11.4. Sighting Time......................................18 69 2.11.5. Motion and Direction Vectors.......................18 70 2.12. Time to Live Element....................................18 71 3. XML Schema Listing............................................18 72 4. XML LO Instance...............................................28 73 5. Note on Validation............................................31 74 6. References....................................................31 75 7. Author's Addresses............................................31 76 8. Full Copyright Statement......................................32 78 1. Introduction 80 This draft aims at providing a foundation of a markup language 81 suitable for representing all data fields of the Geopriv Location 82 Object (LO) as required in [3]. We present and illustrate an XML 83 schema defining such a markup language. Up to now, we have 84 concentrated on the question of how to represent the required data by 85 means of an XML language, only touching the security and privacy 86 issues concerning the Location Object. 88 Even at this early stage of developing a suitable Geopriv Location 89 Object (LO) data format, it has become very clear that the Geopriv 90 Working Group has to arrive at more explicit descriptions of the 91 content of required data fields in order to allow for precise 92 definitions of appropriate LO data formats. To give just one example, 93 the Geopriv Working Group should explicitly determine which types of 94 Location Recipient (LR) Credentials are to be supported. Therefore, 95 we shall also utilize this draft to compile a list of general open 96 issues that must be solved by the Geopriv Working Group in order to 97 be able to complete its work successfully. These general open issues 98 are entirely independent of a particular LO data format (such as XML 100 Cuellar, Guenther Expires - December 2003 2 101 in case of this draft), but their solution is simply a prerequisite 102 to any sensible definition of such a data format. Additionally, we 103 shall collect some open issues that are related to the definition of 104 an XML LO. 106 Based on the solutions of the general and XML related open issues, 107 future versions of this draft will make the Location Object (LO) 108 markup language introduced in this draft more precise in terms of 109 representing identity, privacy policy and location information. We 110 will investigate how security and privacy requirements on the 111 Location Object can be satisfied by means of, for instance, the XML 112 Signature and XML Encryption languages, the XML Access Control Markup 113 Language (XACML) and the XML Key Management Specification (XKMS). In 114 addition, we will make proposals how this XML LO can be bound to 115 different Using Protocols. 117 2. Geopriv LO Markup Language 119 2.1. Overview 121 The XML schema listed completely in chapter 3 specifies an XML 122 language that allows for the following top-level XML elements: 124 - LO (Location Object): 125 comprises all of the subsequent elements, the only mandatory of 126 which is the Target element while all other elements are optional. 127 - Target: 128 contains an identifier for the Target which can be of non- 129 anonymous, anonymous or of indeterminate type. 130 - Device: 131 contains an identifier for the Device which can be a phone number, 132 an IP address, or of anonymous or indeterminate type. 133 - RM (Rule Maker): 134 contains an identifier for the Rule Maker (RM) which can be of 135 non-anonymous, anonymous or of indeterminate type. 136 - LR (Location Recipient): 137 contains an identifier for the LR which can be of non-anonymous, 138 anonymous or of indeterminate type; can also provide the 139 information whether this identifier is a single or multi cast 140 identifier. 141 - LR Credential (Location Recipient Credential): 142 contains credentials of the Location Recipient. 143 - LR PoP (Location Recipient Proof of Possession of Credential): 144 contains the data that allows for verifying that the LR is in fact 145 in possession of a certain credential. 146 - Rule: 147 contains an URI of an Applicable Rule, a Limited Rule or both. 148 - Location: 149 contains one or more Location Information child elements each of 150 which can be composed of one or more Location Representation child 151 elements and a Sighting Time element. Motion and Direction Vector 152 as well as Precision and Confidence elements are also included 153 here. 155 Cuellar, Guenther Expires - December 2003 3 156 - Time to Live: 157 contains the point of time until when Location Information can be 158 considered current. 160 Subsequent paragraphs illustrate the corresponding LO markup language 161 in greater detail. 163 2.2. Schema Element Start Tag 165 As usual, the schema element start tag defines basic properties of 166 the corresponding XML language (the line numbers are, of course, not 167 part of the XML schema, but merely for easier referencing): 169 1: 177 In line 4, the W3C schema language namespace ôhttp://www.w3.org/2001/ 178 XMLSchema" is linked to the prefix ôxsö. In line 3, the prefix 179 ôgploö, which stands for ôgeopriv LOö, is associated to the namespace 180 ôurn:ietf:geopriv:lo:0.0.4ö. This URI also defines the target 181 namespace of this schema (line 2). The value of the attribute 182 ôversionö indicates a (up to now, fictive) version number of this 183 schema and the corresponding XML language. 185 2.3. LO Element 187 The LO element is the element of highest level within the LO markup 188 language. It is defined as follows: 190 8: 193 9: 194 10: 195 11: 196 12: 197 13: 198 14: 199 15: 201 16: 203 17: 204 18: 205 19: 206 20: 207 21: 209 Cuellar, Guenther Expires - December 2003 4 210 Thus, each valid LocationObject element can be composed of the child 211 elements ôTargetö (line 11), ..., and ôTimeToLiveö (line 19). The 212 Target element is the only child element of the LocationObject 213 element that is mandatory. Each other child element is optional and 214 can occur at most once; the order of occurrence is arbitrary (xs:all, 215 line 10). 217 Open Issue 1 (general): 218 Which of the required LO data fields listed in [3] shall be 219 mandatory to the LO? 221 2.4. Target Element 223 In line 11, the definition of the Target element is referenced to the 224 one given below. In essence, the Target element has a child element 225 TargetIdentity and a grandchild element TargetIdentifier whose 226 content is of type ôxs:stringö, and which can be equipped with the 227 optional attributes ôIdentifierTypeö and ôNameSpaceö. Permitted 228 values of the IdentifierType attribute are ôNonAnonymousö, 229 ôAnonymousö and ôAnyö. The latter attribute value might indicate an 230 indeterminate or unknown or concealed type of Target identifier. 232 22: 234 23: 235 24: 236 25: 237 26: 238 27: 239 28: 241 29: 242 30: 243 31: 244 32: 245 33: 246 34: 248 35: 249 36: 250 37: 251 38: 252 39: 253 40: 254 41: 256 42: 257 43: 258 44: 259 45: 260 46: 261 47: 263 Cuellar, Guenther Expires - December 2003 5 264 48: 265 49: 266 50: 267 51: 268 52: 270 53: 271 54: 273 A simple instance of the Target element definition could look like as 274 follows: 276 277 278 279 ginefohcsT sennaH 280 281 282 284 Line 52 defines the attribute NameSpace which is optional to the 285 TargetIdentifier element, and whose value must be an URI. In 286 conjunction with an IdentifierType attribute value ôAnonymousö, this 287 attribute could be used to point to a set of identifiers from which 288 the anonymous Target identifier, i.e. the content of the 289 TargetIdentifier element, had been taken. 291 Open Issue 2 (XML): 292 Pointing to a set of identifiers by means of an URI - is this 293 an appropriate mechanism for handling anonymous identifiers? 295 Line 29 in combination with line 27 allows the TargetIdentifier 296 element to be substituted by any other element defined within a 297 namespace different from the namespace of this schema. The purpose of 298 this mechanism is to support other identity providing data formats 299 such as specified by the Liberty Alliance Project, for example. 301 Open Issue 3 (general): 302 Which identity providing data formats shall be supported by the 303 Geopriv LO? 305 2.5. Device Element 307 The definition of the Device element is quite similar to the 308 definition of the Target element û of course with the exception that 309 the IdentifierType attribute of the DeviceIdentifier element can have 310 the values ôPhoneNumberö, ôIPAddressö, ôAnonymousö and ôAnyö: 312 55: 314 56: 315 57: 317 Cuellar, Guenther Expires - December 2003 6 318 58: 319 59: 320 60: 321 61: 323 62: 324 63: 325 64: 326 65: 327 66: 328 67: 330 68: 331 69: 332 70: 333 71: 334 72: 335 73: 336 74: 338 75: 339 76: 340 77: 341 78: 342 79: 343 80: 344 81: 345 82: 346 83: 347 84: 348 85: 349 86: 351 87: 352 88: 354 An example of an Device element complying with this syntax is: 356 357 358 359 017167239870 360 361 362 364 Open Issue 4 (general): 365 Which types of Devices and Device identifiers shall be supported 366 by the LO? (phone numbers, IP addresses, anonymous ones and 367 ...?) 369 Cuellar, Guenther Expires - December 2003 7 370 2.6. RM Element 372 Up to now, the RM element is defined in a way that allows for 373 representing a non-anonymous, anonymous or indeterminate RM 374 identifier, similar to the Target element. This, of course, will not 375 be sufficient in a final version of this markup language: additional 376 features will have to be specified in order to be able to satisfy the 377 privacy requirements on the LO. 379 89: 381 90: 382 91: 383 92: 384 93: 385 94: 386 95: 388 96: 389 97: 390 98: 391 99: 392 100: 393 101: 395 102: 396 103: 397 104: 398 105: 400 106: 401 107: 402 108: 404 109: 405 110: 406 111: 407 112: 408 113: 409 114: 410 115: 411 116: 412 117: 413 118: 414 119: 416 120: 417 121: 419 An example of a RuleMaker element could be: 421 422 424 Cuellar, Guenther Expires - December 2003 8 425 426 Siemens AG 427 428 429 431 2.7. LR Element 433 The LR element is the last of the identifier storing child elements 434 of the Location Object element. Its definition is modeled on the 435 syntax of the Target, Device and RM elements. Its 436 LocationRecipientIdentifier grandchild element can be of type 437 ôNonAnonymousö, ôAnonymousö and ôAnyö. The optional attribute 438 ôCastTypeö of the LocationRecipientIdentifier element can indicate 439 whether the identifier is a single or a multi cast identifier: 441 122: 444 123: 445 124: 446 125: 447 126: 448 127: 449 128: 451 129: 452 130: 453 131: 454 132: 455 133: 456 134: 458 135: 459 136: 460 137: 461 138: 463 139: 464 140: 465 141: 467 142: 468 143: 469 144: 470 145: 471 146: 472 147: 473 148: 474 149: 475 150: 476 151: 478 Cuellar, Guenther Expires - December 2003 9 479 152: 480 153: 481 154: 482 155: 483 156: 484 157: 485 158: 486 159: 487 160: 489 161: 490 162: 492 Example: 494 495 496 499 CT IC 3 Mobile Security Team 500 501 502 504 Open Issue 5 (general): 505 Which types of data sub-fields shall the LR data 506 field support? (For example, data sub-fields for phone numbers 507 or IP addresses of LRs?) 509 2.8. LR Credential Element 511 Up to now, the Geopriv Working Group has not determined which types 512 of Credentials are to be supported by the LR Credential data field. 513 Thus, for now, we have specified in the definition of the 514 LocationRecipientCredential element that credentials are of 515 unspecific type ôxs:stringö (line 166-170). The element names 516 ôPKIXCertificateö, ..., ôIDandSharedSecretö indicate some credential 517 types that could be supported by the LR Credential data field. Line 518 165 (maxOccurs= öunboundedö) allows several credentials to be 519 included in the LocationRecipientCredential element: 521 163: 524 164: 525 165: 526 166: 527 167: 528 168: 530 169: 532 Cuellar, Guenther Expires - December 2003 10 533 170: 534 171: 535 172: 537 A vacuous example of a LocationRecipientCredential element: 539 540 ... 541 543 Open Issue 6 (general): 544 Which credential types shall be supported by the LR Credential 545 data field? 547 2.9. LR PoP Element 549 The Geopriv Working Group should define explicitly the types of PoP 550 (Proof of Possession of Credential) that shall be supported in the 551 corresponding data field. The simplest way of providing such a PoP 552 may be signing an appropriate statement on the result of a 553 successfully executed challenge-response procedure. We indicate this 554 possibility rudimentarily in the current definition of the 555 LocationRecipientPoPofCredential element: 557 173: 558 174: 559 175: 560 176: 561 177: 562 178: 563 179: 565 For adding an XML digital signature to the statement contained in 566 line 176, the schema definition could be modified as follows: 568 M01: 577 M09: 582 M10: ....... 584 M11: 585 M12: 587 Cuellar, Guenther Expires - December 2003 11 588 M13: 589 M14: 591 M15: 592 M16: 593 M17: 594 M18: 596 M19: ....... 598 In line M04, the W3C XML Signature namespace is assigned to the 599 prefix ôdsö. The place at which an XML validator can find the XML 600 Signature language definitions is identified in line M09. Finally, 601 line M15 makes a ds:Signature element mandatory. 603 Open Issue 7 (general): 604 Which types of LR PoP data fields shall be supported? 605 (Signatures on Challenge-Response procedures? However, we also 606 need ...?) 608 2.10. Rule Element 610 As described in the Geopriv Requirements draft [3], the Rule Field of 611 the LO ôMAY be a referral to an applicable Rule (for instance, an URI 612 to a full Rule), or it MAY contain a Limited Rule, or bothö. In the 613 current version of the LO markup language, this requirement is 614 implemented as follows: 616 180: 618 181: 619 182: 620 183: 622 184: 624 185: 625 186: 626 187: 627 188: 630 191: 633 194: 634 195: 635 196: 636 197: 637 198: 639 199: 640 200: 642 Cuellar, Guenther Expires - December 2003 12 643 201: 644 202: 645 203: 647 204: 648 205: 649 206: 650 207: 651 208: 653 A Rule element could therefore look like as follows: 655 656 657 658 Dirk Kroeselberg has no permission to see my location. 659 660 661 663 (And this is a Rule language that is in fact ôlimitedö ...) 665 Open Issue 8 (general and XML): 666 Geopriv must specify or adopt at least one Rule language. 667 Furthermore, the mechanism of pointing to an applicable Rule 668 must be described explicitly. In case of an XML LO data format, 669 the XML Access Control Markup Language (XACML) seems to be a 670 natural Rule language candidate - at least with respect to a 671 full Rule language. - With regard to what exactly is a Limited 672 Rule language supposed to be ôlimitedö? 674 2.11. Location Element 676 The Location element carries the actual location information. It 677 consists of an unbounded number of LocationInformation elements; the 678 number of these elements can be zero (line 212). Each 679 LocationInformation element allows for arbitrarily many 680 LocationRepresentation child elements, and optional child elements 681 ôSightingTimeö, ôMotionVectorö and ôDirectionVectorö (line 217-220). 682 The LocationRepresentation elements can contain representations of 683 location information that are of type ôLatLonAltö (Altitude is 684 optional), ôCivilö, or ôTimeZoneö (lines 226-228), as well as of an 685 type defined outside the namespace of the LO markup language (for 686 instance, developed by OpenGIS), see line 229. In addition, the 687 LocationRepresentation element has an optional child element 688 ôConfidenceö (line 231), whose content is a decimal number between 689 0.0 and 100.0 indicating a level of reliability associated with a 690 given Location Representation: 692 209: 694 210: 695 211: 697 Cuellar, Guenther Expires - December 2003 13 698 212: 702 213: 703 214: 705 215: 706 216: 707 217: 711 218: 713 219: 715 220: 717 221: 718 222: 720 223: 721 224: 722 225: 723 226: 724 227: 725 228: 726 229: 727 230: 728 231: 730 232: 731 233: 733 The overall structure of an instance of the Location element can be 734 seen from the following example, which uses the ôLatLonAltö, ôCivilö 735 and ôTimeZoneö types of location representations: 737 738 739 740 ..... 741 ..... 742 743 744 ..... 745 746 747 ..... 748 749 ..... 750 ..... 752 Cuellar, Guenther Expires - December 2003 14 753 ...... 754 755 ..... 756 758 2.11.1. Latitude, Longitude, Altitude and Precision 760 Line 226 above points to the following definition of the ôLatLonAltö 761 type of location representation: The LatLonAlt element consists of 762 the mandatory Latitude and Longitude elements, an optional Altitude 763 element and an optional Precision element: 765 234: 766 235: 767 236: 769 237: 771 238: 773 239: 776 240: 777 241: 779 Real-world latitude and longitude representations come in (at least) 780 three different styles: 782 - Example: - 11— 13Æ 57ÆÆ: 783 This means: degree, minute and second are represented separately 784 by integers contained in certain intervals. We have introduced an 785 equivalent XML representation which is abbreviated by 786 DegIntMinIntSecInt. 788 - Example: 48.1234—: 789 This means: degree, minute and second are represented by one 790 decimal number contained in a certain interval. We have specified 791 an equivalent XML representation abbreviated by DegMinSecDec. 793 - Example: - 19— 21.123Æ: 794 This means: the degree is represented by an integer, while minute 795 and second are represented by one decimal number. We have also 796 introduced an equivalent XML representation which is abbreviated 797 by DegIntMinSecDec. 799 The optional Altitude element whose type is referenced in line 238 800 above consists of a positive or negative decimal number representing 801 the altitude value with respect to a unit that must be indicated by 802 the value of the attribute Unit. The permitted values of the Unit 803 attribute are ôMeterö, ôKilometerö, ôFootö, ôYardö and ôMileö. 805 Cuellar, Guenther Expires - December 2003 15 806 The content of the optional element Precision (see line 239) is a 807 positive decimal number indicating an area within which the Target is 808 located. The Precision element has two mandatory attributes at its 809 disposal: Area and Unit. The permitted values of the Area attribute 810 are ôCircleö, ôSphereö, ôRectangleö and ôCuboidö indicating the shape 811 of area, while the permitted values of the Unit attribute are as 812 described above. In case the Altitude element is present, the 813 semantics of a Precision element of the form 815 58.3, 817 for instance, could be that the location of the Target is known to be 818 contained in a sphere of 58.3 cubic meters around the position 819 specified by means of the content of the Latitude, Longitude and 820 Altitude elements. There are, of course, many other ways of 821 indicating precision, which immediately leads to 823 Open Issue 9 (general): 824 Which types of precision indications shall be supported within 825 the Location Field? Which is the exact semantics of these 826 precision indications? 828 Instead of listing the schema definitions illustrated in this 829 paragraph, we give an example of a full LatLonAlt element: 831 832 833 834 -48 835 8 836 23 837 838 839 840 841 11 842 34.4667 843 844 845 521.27 846 58.3 847 849 2.11.2. Civil 851 There has been a long discussion within Geopriv on how the civil type 852 of location representation should look like. Location domains such as 853 ôstateö and ôdistrictö are not appropriate for all countries. Since 854 we are not sure whether that discussion can be seen as finished, we 855 include this problem in the list of open issues: 857 Cuellar, Guenther Expires - December 2003 16 858 Open Issue 10 (general): 859 How exactly should civil location representations look like? 861 In order to circumvent some of the problems, we have defined the 862 civil type of location representation as follows: 864 242: 865 243: 866 244: 867 245: 868 246: 869 247: 870 248: 871 249: 872 250: 873 251: 874 252: 875 253: 876 254: 877 255: 879 Thus, the Civil element introduced in line 227 above consists of an 880 unbounded sequence of Domain elements, whose content is of type 881 ôxs:stringö, and which are equipped with a mandatory but not 882 explicitly specified attribute. The intention here is to allow for a 883 type of civil location representation that is universal as far as 884 possible: The Civil element 886 887 Germany 888 Bavaria 889 Munich 890 Leopoldstrasse 891 6 892 894 complies with its schema definition as well as 896 897 ... 898 ... 899 ... 900 902 does. 904 2.11.3. Time Zone 906 Time zones are a further type of location representation supported by 907 the schema definition: 909 256: 910 257: 912 Cuellar, Guenther Expires - December 2003 17 913 258: 914 259: 915 260: 917 Therefore, -08:00, +11:36 and Z (standing for Zulu, i.e. Greenwich 918 Mean Time) are valid content of TimeZone elements which have been 919 introduced in line 228 above. 921 2.11.4. Sighting Time 923 The W3C schema language specifications provide the data type 924 ôxs:dateTimeö which is suitable for indicating when the location 925 information was accurate. So 927 2003-07-14T20:12:34+01:00 929 is a valid SightingTime child element of the LocationInformation 930 element. 932 2.11.5. Motion and Direction Vectors 934 The MotionVector and DirectionVector elements are optional child 935 elements of the LocationInformation element and are defined in lines 936 219 and 220 as follows: 938 940 943 These definitions are nothing else than place holders since we have 944 the following 946 Open Issue 11 (general): 947 How exactly shall the motion and direction vectors look like and 948 what is their semantics? 950 2.12. Time to Live Element 952 The data type ôxs:dateTimeö is also suitable for indicating until 953 when location information can be considered current: 955 261: 957 Example: 2003-07-14T20:17:34+01:00. 959 3. XML Schema Listing 961 Cuellar, Guenther Expires - December 2003 18 962 This section contains a complete listing of the XML schema that has 963 been illustrated in previous sections. The next section provides a 964 simple XML LO instance document that is valid with respect to this 965 schema. 967 968 976 978 980 981 982 983 984 985 986 988 990 991 992 993 994 996 998 1000 1002 1003 1004 1005 1006 1007 1009 1010 1011 1012 1013 1015 Cuellar, Guenther Expires - December 2003 19 1016 1018 1019 1020 1021 1022 1023 1024 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1040 1042 1044 1046 1047 1048 1049 1050 1051 1053 1054 1055 1056 1057 1058 1060 1061 1062 1063 1064 1065 1066 1068 1070 Cuellar, Guenther Expires - December 2003 20 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1085 1087 1089 1091 1092 1093 1094 1095 1096 1098 1099 1100 1101 1102 1103 1105 1106 1107 1108 1109 1110 1111 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1125 Cuellar, Guenther Expires - December 2003 21 1126 1127 1129 1131 1133 1136 1137 1138 1139 1140 1141 1143 1144 1145 1146 1147 1148 1150 1151 1152 1153 1155 1156 1157 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1180 Cuellar, Guenther Expires - December 2003 22 1181 1183 1185 1187 1190 1191 1192 1193 1194 1196 1197 1198 1199 1201 1203 1205 1206 1207 1208 1209 1210 1211 1213 1215 1217 1219 1220 1221 1223 1224 1225 1226 1227 1230 1233 1235 Cuellar, Guenther Expires - December 2003 23 1236 1237 1238 1239 1241 1242 1243 1244 1245 1247 1248 1249 1250 1251 1253 1255 1257 1259 1260 1261 1265 1266 1268 1269 1270 1274 1276 1278 1280 1281 1283 1284 1285 1286 1287 1288 1290 Cuellar, Guenther Expires - December 2003 24 1291 1292 1293 1295 1296 1298 1299 1300 1301 1302 1303 1305 1307 1308 1309 1311 1313 1315 1318 1319 1321 1322 1323 1325 1327 1329 1330 1332 1333 1334 1336 1338 1340 1341 1343 1345 Cuellar, Guenther Expires - December 2003 25 1346 1347 1348 1349 1350 1351 1353 1354 1355 1356 1357 1358 1359 1360 1362 1363 1364 1365 1366 1367 1368 1370 1371 1372 1373 1374 1375 1376 1378 1379 1380 1381 1382 1383 1385 1386 1387 1388 1389 1390 1392 1393 1394 1395 1396 1397 1399 Cuellar, Guenther Expires - December 2003 26 1400 1401 1402 1403 1404 1405 1407 1408 1409 1410 1411 1412 1414 1415 1416 1417 1418 1419 1421 1422 1423 1424 1425 1427 1428 1429 1430 1431 1432 1434 1435 1436 1437 1438 1439 1440 1441 1443 1444 1445 1446 1447 1448 1449 1450 1451 1453 Cuellar, Guenther Expires - December 2003 27 1454 1455 1456 1457 1458 1460 1462 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1479 1481 1483 1484 1485 1486 1487 1489 1491 1493 1495 1497 1499 1501 4. XML LO Instance 1503 To give a preliminary impression of how an XML LO complying with the 1504 schema listed in section 3 could look like, this section provides 1506 Cuellar, Guenther Expires - December 2003 28 1507 such an XML instance document. It can be validated against this 1508 schema (see section 5). 1510 1511 1516 1517 1518 1519 ginefohcsT sennaH 1520 1521 1522 1524 1525 1526 1527 017167239870 1528 1529 1530 1532 1533 1534 1535 Siemens AG 1536 1537 1538 1540 1541 1542 1545 CT IC 3 Mobile Security Team 1546 1547 1548 1550 1551 ... 1552 1554 1555 1556 Challenge-Response executed successfully 1557 1558 1560 Cuellar, Guenther Expires - December 2003 29 1561 1562 1563 1564 Dirk Kroeselberg has no permission to see my location. 1565 (Limited Rule Language needs to be defined.) 1566 1567 1568 1570 1571 1572 1573 1574 1575 1576 -48 1577 8 1578 23 1579 1580 1581 1582 1583 11 1584 34.4667 1585 1586 1587 521.27 1588 58.3 1589 1590 95.0 1591 1592 1593 1594 Germany 1595 Bavaria 1596 Munich 1597 Leopoldstrasse 1598 6 1599 1600 1601 1602 +01:00 1603 1604 2003-07-14T20:12:34+01:00 1605 ... 1606 ... 1607 1608 1610 2003-07-14T20:17:34+01:00 1612 1614 Cuellar, Guenther Expires - December 2003 30 1615 5. Note on Validation 1617 We have validated the XML LO listed in section 4 and other instance 1618 documents against the schema listed in section 3 using the XML Schema 1619 Validator (XSV) and the Apache XML projectÆs Xerces2-J parser. XSV 1620 and Xerces2-J are available at 1622 http://www.ltg.ed.ac.uk/~ht/xsv-status.html 1624 and 1626 http://xml.apache.org/xerces2-j/index.html, 1628 respectively. If you store the schema as ôgploml004.xsdö and the XML 1629 LO as (say) ôgploml004.xmlö in the same directory, then the commands 1631 xsv gploml004.xml gploml004.xsd 1633 and 1635 java dom.Writer ûv ûs gploml004.xml, 1637 respectively, should not produce any error messages. 1639 6. References 1641 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1642 9, RFC 2026, October 1996. 1644 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1645 Levels", BCP 14, RFC 2119, March 1997 1647 [3] Cuellar, J., Morris, J.B., Mulligan D., Peterson, J., Polk, J., 1648 "Geopriv requirements", Internet Draft, draft-ietf-geopriv- 1649 reqs-03.txt, March 2003. 1651 7. Author's Addresses 1653 Jorge R Cuellar 1654 Siemens AG 1655 Corporate Technology 1656 CT IC 3 1657 81730 Munich Email: jorge.cuellar@siemens.com 1658 Germany 1660 Christian Guenther 1661 Siemens AG 1662 Corporate Technology 1664 Cuellar, Guenther Expires - December 2003 31 1665 CT IC 3 1666 81730 Munich Email: christian.guenther@siemens.com 1667 Germany 1669 8. Full Copyright Statement 1671 Copyright (C) The Internet Society (2003). All Rights Reserved. 1673 This document and translations of it may be copied and furnished to 1674 others, and derivative works that comment on or otherwise explain it 1675 or assist in its implementation may be prepared, copied, published 1676 and distributed, in whole or in part, without restriction of any 1677 kind, provided that the above copyright notice and this paragraph are 1678 included on all such copies and derivative works. However, this 1679 document itself may not be modified in any way, such as by removing 1680 the copyright notice or references to the Internet Society or other 1681 Internet organizations, except as needed for the purpose of 1682 developing Internet standards in which case the procedures for 1683 copyrights defined in the Internet Standards process must be 1684 followed, or as required to translate it into languages other than 1685 English. 1687 The limited permissions granted above are perpetual and will not be 1688 revoked by the Internet Society or its successors or assigns. 1690 This document and the information contained herein is provided on an 1691 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1692 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1693 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1694 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1695 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1697 Cuellar, Guenther Expires - December 2003 32