draft-mayrhofer-geopriv-geo-uri-00
While reading through this ID: A Uniform Resource Identifier for Geographic
Locations ('geo' URI), I found several minor issues.
Section 2. Introduction
[use of WGS84 reference system]
I wonder if it might be more forward thinking to allow for the optional
specification of the reference system being used. Perhaps this could be one
of the URI parameters mentioned in section 4.7
Section 4.4.1 Component Description
The number of decimal places indicates the precision of the value.
One degree equals 111.319,45m at the equator (40.075,004km / 360
degree). Five decimal places (0.1 degree) seem to imply a for
civil use sufficient accuracy.
To my American eye the decimal notation (partially) used here was jaring.
Searching (briefly) for some sort of presentation standard in an RFC or
other technical document was unsuccessful. Is the use of . and ,
standardized in the representation of real numbers in RFCs?
Section 6. GML Mappings
There seems to be no explanation of what GML is, not even a Reference
document.
Section 9.1. Invalid Locations
Is there a recommended way to represent the poles? Dare I suggest geo:90
and geo:-90? If that is too much of a special case, should the longitude
always be zero or can it be anything between -180.0 and 180.0?
Section 9.2. Location Privcay
Typo: .Privacy
--
Bill McQuillan [EMAIL PROTECTED]
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ISSN for RFC Series under Consideration
The IETF Trust is considering applying to the U.S. Library of Congress to obtain an International Standard Serial Number (ISSN) for the RFC Series and would like community input to inform its decision. The Trust may take up this matter on June 11th. An ISSN is applied to serials - print or non-print publications issued in parts. A serial is expected to continue indefinitely. Serials include magazines, newspapers, annuals, journals, proceedings, transactions of societies, and monographic series. Other SDOs, such as the IEEE, have obtained ISSNs for their publications. A single ISSN uniquely identifies a title regardless of language or country in which published, without the burden of a complex bibliographic description. The ISSN itself has no significance other than the unique identification of a serial. The Trust believes there are advantages to indentifying the RFC Series with an ISSN. Among them, 1. Make reference to the series compact and globally unique; 2. Make the series, and individual RFCs, easier to reference in some contexts; 3. Results in accurate citing of serials by scholars, researchers, abstracters, and librarians; 4. ISSN registrations are maintained in an international data base and are made available in the ISSN Register online According to the Library of Congress, www.loc.gov/issn/, for serials available only in online versions, the ISSN should appear on the title screen or home page and/or in the masthead or other areas where information about publisher, frequency, subscribing, copyright, etc. is given. There is no cost associated with obtaining ISSNs. Ray Pelletier IAD Trustee ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ISSN for RFC Series under Consideration
Great idea, and I don't see a downside. Sent from my Verizon Wireless BlackBerry -Original Message- From: Ray Pelletier [EMAIL PROTECTED] Date: Wed, 21 May 2008 13:52:09 To:IETF Discussion ietf@ietf.org, IAOC [EMAIL PROTECTED], The IESG [EMAIL PROTECTED],RFC Editor [EMAIL PROTECTED], IAB [EMAIL PROTECTED], Working Group Chairs [EMAIL PROTECTED] Subject: ISSN for RFC Series under Consideration The IETF Trust is considering applying to the U.S. Library of Congress to obtain an International Standard Serial Number (ISSN) for the RFC Series and would like community input to inform its decision. The Trust may take up this matter on June 11th. An ISSN is applied to serials - print or non-print publications issued in parts. A serial is expected to continue indefinitely. Serials include magazines, newspapers, annuals, journals, proceedings, transactions of societies, and monographic series. Other SDOs, such as the IEEE, have obtained ISSNs for their publications. A single ISSN uniquely identifies a title regardless of language or country in which published, without the burden of a complex bibliographic description. The ISSN itself has no significance other than the unique identification of a serial. The Trust believes there are advantages to indentifying the RFC Series with an ISSN. Among them, 1. Make reference to the series compact and globally unique; 2. Make the series, and individual RFCs, easier to reference in some contexts; 3. Results in accurate citing of serials by scholars, researchers, abstracters, and librarians; 4. ISSN registrations are maintained in an international data base and are made available in the ISSN Register online According to the Library of Congress, www.loc.gov/issn/, for serials available only in online versions, the ISSN should appear on the title screen or home page and/or in the masthead or other areas where information about publisher, frequency, subscribing, copyright, etc. is given. There is no cost associated with obtaining ISSNs. Ray Pelletier IAD Trustee ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ISSN for RFC Series under Consideration
On 5/21/08 2:06 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Great idea, and I don't see a downside. The only possible disadvantage I can see is if they're then cataloged as a serial rather than having individual call numbers and individual catalog entries, but since the Library of Congress doesn't seem to be cataloging them today I guess to have them cataloged at all would be an improvement. Melinda ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: ISSN for RFC Series under Consideration
Hi, The Trust has analyzed the advantages, and you included the advantages in your post. Has the Trust also analyzed any potential disadvantages? Can you tell us those as well? David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Pelletier Sent: Wednesday, May 21, 2008 1:52 PM To: IETF Discussion; IAOC; The IESG; RFC Editor; IAB; Working Group Chairs Subject: ISSN for RFC Series under Consideration The IETF Trust is considering applying to the U.S. Library of Congress to obtain an International Standard Serial Number (ISSN) for the RFC Series and would like community input to inform its decision. The Trust may take up this matter on June 11th. An ISSN is applied to serials - print or non-print publications issued in parts. A serial is expected to continue indefinitely. Serials include magazines, newspapers, annuals, journals, proceedings, transactions of societies, and monographic series. Other SDOs, such as the IEEE, have obtained ISSNs for their publications. A single ISSN uniquely identifies a title regardless of language or country in which published, without the burden of a complex bibliographic description. The ISSN itself has no significance other than the unique identification of a serial. The Trust believes there are advantages to indentifying the RFC Series with an ISSN. Among them, 1. Make reference to the series compact and globally unique; 2. Make the series, and individual RFCs, easier to reference in some contexts; 3. Results in accurate citing of serials by scholars, researchers, abstracters, and librarians; 4. ISSN registrations are maintained in an international data base and are made available in the ISSN Register online According to the Library of Congress, www.loc.gov/issn/, for serials available only in online versions, the ISSN should appear on the title screen or home page and/or in the masthead or other areas where information about publisher, frequency, subscribing, copyright, etc. is given. There is no cost associated with obtaining ISSNs. Ray Pelletier IAD Trustee ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ISSN for RFC Series under Consideration
Hi - From: Melinda Shore [EMAIL PROTECTED] To: IETF Discussion ietf@ietf.org Sent: Wednesday, May 21, 2008 11:16 AM Subject: Re: ISSN for RFC Series under Consideration ... The only possible disadvantage I can see is if they're then cataloged as a serial rather than having individual call numbers and individual catalog entries, but since the Library of Congress doesn't seem to be cataloging them today I guess to have them cataloged at all would be an improvement. ... What would it take to get them cataloged individually? Randy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ISSN for RFC Series under Consideration
On 5/21/08 at 1:52 PM -0400, Ray Pelletier wrote: The Trust believes there are advantages to indentifying the RFC Series with an ISSN. OK, maybe I'm getting suspicious in my (still slowly) advancing years: Nowhere in the message did I see words like, The Trust has consulted with lawyers/doctors/priests/old-crusty-IETFers and have found no disadvantages to identifying the RFC Series with an ISSN. Did the Trust actually find no potential problems (in which case it would be nice to hear that), have they not looked into it yet, or did they find problems and you're not saying because you don't want to have a big public discussion (in which case you're being dopey, because it's gonna happen anyway)? (For the record, had you said that the Trust did in fact consult the tea leaves and everything looked on the up-and-up and they were simply confirming this with the community, I would have immediately said, Fine with me. I'm happy to have people to whom such things can be delegated, but I do want to hear the words We've done our due diligence.) pr -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Incorporated ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Vacation reply
salutcomment vas-tu,la famille aussi?rentre vite dans le site: www.bicoeur.com inscris toi sur ((butineo)) c'est une bannière jaunetu recevras un code pour appeler et envoyer des sms gratuitement dans le monde entier ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAOC] ISSN for RFC Series under Consideration
Pete Resnick wrote: On 5/21/08 at 1:52 PM -0400, Ray Pelletier wrote: The Trust believes there are advantages to indentifying the RFC Series with an ISSN. OK, maybe I'm getting suspicious in my (still slowly) advancing years: Nowhere in the message did I see words like, The Trust has consulted with lawyers/doctors/priests/old-crusty-IETFers and have found no disadvantages to identifying the RFC Series with an ISSN. The Trust did consult with lawyers, old-crusty-IETFers, RFC Editor, and found no disadvantages to indentifying the RFC Series with an ISSN. Did the Trust actually find no potential problems (in which case it would be nice to hear that), have they not looked into it yet, or did they find problems and you're not saying because you don't want to have a big public discussion (in which case you're being dopey, because it's gonna happen anyway)? That we know! (For the record, had you said that the Trust did in fact consult the tea leaves and everything looked on the up-and-up and they were simply confirming this with the community, I would have immediately said, Fine with me. I'm happy to have people to whom such things can be delegated, but I do want to hear the words We've done our due diligence.) We've done our due diligence, but we respect the community and the process, and seek its guidance. Ray pr ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ISSN for RFC Series under Consideration
On 5/21/08 2:19 PM, Randy Presuhn [EMAIL PROTECTED] wrote: What would it take to get them cataloged individually? Interest in having them cataloged individually. I believe LC catalogs everything it receives. I've been out of librarianship long enough not to know how they receive electronic-only material. There are a couple of RFCs in the OCLC database but not a lot, and they seem to under the subject heading Computer networks-- standards. Cataloging helps solve the problem of finding the document. Subject headers and classification help solve the problem of finding the information in the document. As university libraries are apparently currently classifying RFCs the subject classification is so broad as to be useless and I would guess that there's not currently a problem with locating the documents (for reasonable people, anyway). I think the answer to the question of how easy it is to locate the *information* in the documents (i.e. information retrieval) is a lot less clear but I'm not sure the necessarily broad categories in the LC subject classifications would help with that problem at all (in fact, I'm pretty sure it wouldn't). But more information is usually better than less information, so what the heck. Melinda ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAOC] ISSN for RFC Series under Consideration
On 5/21/08 at 2:36 PM -0400, Ray Pelletier wrote: The Trust did consult with lawyers, old-crusty-IETFers, RFC Editor, and found no disadvantages to indentifying the RFC Series with an ISSN. [...] We've done our due diligence, but we respect the community and the process, and seek its guidance. Gotta love that! ;-) Sounds like a fine idea to me. pr -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ISSN for RFC Series under Consideration
Mostly sounds fine, with one small glitch. At 1:52 PM -0400 5/21/08, Ray Pelletier wrote: According to the Library of Congress, www.loc.gov/issn/, for serials available only in online versions, the ISSN should appear on the title screen or home page and/or in the masthead or other areas where information about publisher, frequency, subscribing, copyright, etc. is given. The value of adding ISSN: 12345678 to each RFC seems small, particularly relative to the cost of everyone having to update their tools and so on. Also, we would have to tell people *not* to put the ISSN designation in their Internet Drafts (which are not part of the RFC series), but then switch it on for the RFC, and so on. The cost of putting ISSN: 12345678 on a few pages at rfc-editor.org and ietf.org is tiny and hopefully sufficient for the statement above. --Paul Hoffman ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ISSN for RFC Series under Consideration
Naw. The ISSN has to be on the document itself. As you point out, this isn't something to be done with Internet Drafts, so it falls naturally to the RFC Editor, not to the individual authors. Steve On May 22, 2008, at 3:14 AM, Paul Hoffman wrote: Mostly sounds fine, with one small glitch. At 1:52 PM -0400 5/21/08, Ray Pelletier wrote: According to the Library of Congress, www.loc.gov/issn/, for serials available only in online versions, the ISSN should appear on the title screen or home page and/or in the masthead or other areas where information about publisher, frequency, subscribing, copyright, etc. is given. The value of adding ISSN: 12345678 to each RFC seems small, particularly relative to the cost of everyone having to update their tools and so on. Also, we would have to tell people *not* to put the ISSN designation in their Internet Drafts (which are not part of the RFC series), but then switch it on for the RFC, and so on. The cost of putting ISSN: 12345678 on a few pages at rfc-editor.org and ietf.org is tiny and hopefully sufficient for the statement above. --Paul Hoffman ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ISSN for RFC Series under Consideration
On Wed, May 21, 2008 at 12:14:35PM -0700, Paul Hoffman [EMAIL PROTECTED] wrote a message of 23 lines which said: The value of adding ISSN: 12345678 ISSN: 12345678? I hope we will eat our own dog food and use RFC 3044. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ISSN for RFC Series under Consideration
Steve Crocker wrote: Naw. The ISSN has to be on the document itself. As you point out, this isn't something to be done with Internet Drafts, so it falls naturally to the RFC Editor, not to the individual authors. The benefit of the new number requires that folk know about it, which means we need to make sure it is as visible as possible. So, I agree it has to be on individual documents. The burden of providing pro forma details in an RFC has increasingly fallen to authors in recent years, with the RFC Editor having to do less editing (and, on could argue, should continue in that direction.) Happily, xml2rfc makes this a highly tolerable burden. So Paul is correct that author tools need to be updated, but since registration with the US LoC is of long-term benefit, and the change is small, it's difficult to view that rather burden as onerous. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ISSN for RFC Series under Consideration
I think there is a bigger issue with encumbering the people of the US for paying for creating an indexing system for the IETF to prevent the Chair/Trust from doing its job. I suggest that this is another stupid idea from the Trust to keep them from actually answering the question as to what they are going to do to 1)Protect IETF IP's 2)Market those IP's Todd Glassey - Original Message - From: Steve Crocker [EMAIL PROTECTED] To: IETF Discussion ietf@ietf.org Cc: IAOC [EMAIL PROTECTED] Sent: Wednesday, May 21, 2008 12:17 PM Subject: Re: ISSN for RFC Series under Consideration Naw. The ISSN has to be on the document itself. As you point out, this isn't something to be done with Internet Drafts, so it falls naturally to the RFC Editor, not to the individual authors. Steve On May 22, 2008, at 3:14 AM, Paul Hoffman wrote: Mostly sounds fine, with one small glitch. At 1:52 PM -0400 5/21/08, Ray Pelletier wrote: According to the Library of Congress, www.loc.gov/issn/, for serials available only in online versions, the ISSN should appear on the title screen or home page and/or in the masthead or other areas where information about publisher, frequency, subscribing, copyright, etc. is given. The value of adding ISSN: 12345678 to each RFC seems small, particularly relative to the cost of everyone having to update their tools and so on. Also, we would have to tell people *not* to put the ISSN designation in their Internet Drafts (which are not part of the RFC series), but then switch it on for the RFC, and so on. The cost of putting ISSN: 12345678 on a few pages at rfc-editor.org and ietf.org is tiny and hopefully sufficient for the statement above. --Paul Hoffman ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ISSN for RFC Series under Consideration
On 5/21/08 3:36 PM, Dave Crocker [EMAIL PROTECTED] wrote: The benefit of the new number requires that folk know about it, I actually don't think that's the case. I mean, I think it should be on the documents (otherwise there's some small point to having one, but not a lot) but I think it's real value is to the people who organize information. The value to users of information is probably indirect at best - I'm having a hard time imagining a circumstance in which having the ISSN on the document is of immediate value to someone using the document. Melinda ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ISSN for RFC Series under Consideration
Ray Pelletier wrote: ... The Trust believes there are advantages to indentifying the RFC Series with an ISSN. Among them, 1. Make reference to the series compact and globally unique; ... More compact than urn:ietf:rfc:? BR, Julian ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: ISSN for RFC Series under Consideration
Yes, this seems like a good idea and I don't see why anyone would have to do any work other than the RFC Editor. Are the tools we use really so brittle that adding a line with ISSN - or urn:ISSN:- or whatever somewhere in the upper left corner of the first page of an RFC will break them? Donald -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Crocker Sent: Wednesday, May 21, 2008 3:18 PM To: IETF Discussion Cc: IAOC Subject: Re: ISSN for RFC Series under Consideration Naw. The ISSN has to be on the document itself. As you point out, this isn't something to be done with Internet Drafts, so it falls naturally to the RFC Editor, not to the individual authors. Steve On May 22, 2008, at 3:14 AM, Paul Hoffman wrote: Mostly sounds fine, with one small glitch. At 1:52 PM -0400 5/21/08, Ray Pelletier wrote: According to the Library of Congress, www.loc.gov/issn/, for serials available only in online versions, the ISSN should appear on the title screen or home page and/or in the masthead or other areas where information about publisher, frequency, subscribing, copyright, etc. is given. The value of adding ISSN: 12345678 to each RFC seems small, particularly relative to the cost of everyone having to update their tools and so on. Also, we would have to tell people *not* to put the ISSN designation in their Internet Drafts (which are not part of the RFC series), but then switch it on for the RFC, and so on. The cost of putting ISSN: 12345678 on a few pages at rfc-editor.org and ietf.org is tiny and hopefully sufficient for the statement above. --Paul Hoffman ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: ISSN for RFC Series under Consideration
On Wed May 21 20:49:19 2008, Eastlake III Donald-LDE008 wrote: Yes, this seems like a good idea and I don't see why anyone would have to do any work other than the RFC Editor. Are the tools we use really so brittle that adding a line with ISSN - or urn:ISSN:- or whatever somewhere in the upper left corner of the first page of an RFC will break them? Speaking on behalf of the famous A. Address and Mr Editor, I can categorically state that our tools are fine. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Random Network Endpoint Technology (RNET)
The following is an explanation of how to accomplish setting up a path of communication between two RNET Hosts. Some of you may have already figured this out... now you have the definitive answer.Consider this; You have two RNET Hosts, host A and host B. Both hosts wish to communicate with each other. Since both used un-advertised IP addresses, this seems impossible. The solution is to setup a route path between them so that the routers between them will forward packets destined for each of the two hosts. The operator of host A must contact the operator of host B through some other means of communication. The operator of host A need only acquire the, advertised, IP address of host B's gateway. Once this is done, host A sends an RNET Route Request specifying the host B's address as the target address and directs this request to the gateway of host B. The result is that all the routers in between host A and host B will have setup an RNET Route entry for host A as the RNET Host and with host B as the Target Host. At this point either host may initiate contact with the other as the routers between them will know where to forward their packet(s).I hope this clears up any confusion or misunderstanding (or lack thereof.)If you have any suggestions or comments, please feel free to email me directly at mailto:[EMAIL PROTECTED] Sincerely, Chad Christopher Giffin T-Net Information Systems (a.k.a. typo) _ If you like crossword puzzles, then you'll love Flexicon, a game which combines four overlapping crossword puzzles into one! http://g.msn.ca/ca55/208___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [IAOC] ISSN for RFC Series under Consideration
+1 no brainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete Resnick Sent: Wednesday, May 21, 2008 3:06 PM To: Ray Pelletier Cc: Working Group Chairs; IAB; IETF Discussion; IAOC; The IESG; RFC Editor Subject: Re: [IAOC] ISSN for RFC Series under Consideration On 5/21/08 at 2:36 PM -0400, Ray Pelletier wrote: The Trust did consult with lawyers, old-crusty-IETFers, RFC Editor, and found no disadvantages to indentifying the RFC Series with an ISSN. [...] We've done our due diligence, but we respect the community and the process, and seek its guidance. Gotta love that! ;-) Sounds like a fine idea to me. pr -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651- 1102 ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ISSN for RFC Series under Consideration
On 2008-05-22 07:20, Julian Reschke wrote: Ray Pelletier wrote: ... The Trust believes there are advantages to indentifying the RFC Series with an ISSN. Among them, 1. Make reference to the series compact and globally unique; ... More compact than urn:ietf:rfc:? Possibly not, but there is still a crusty old world of academic publications with traditional reference styles out there, and an ISSN will make it much more straightforward to cite RFCs in peer-reviewed publications. +1 that it's a no-brainer. Regards Brian Carpenter University of Auckland ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Random Network Endpoint Technology (RNET)
So we have reinvented STUN? Sent from my Verizon Wireless BlackBerry -Original Message- From: Chad Giffin [EMAIL PROTECTED] Date: Wed, 21 May 2008 17:09:54 To:ietf@ietf.org Cc:[EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Random Network Endpoint Technology (RNET) The following is an explanation of how to accomplish setting up a path of communication between two RNET Hosts. Some of you may have already figured this out... now you have the definitive answer. Consider this; You have two RNET Hosts, host A and host B. Both hosts wish to communicate with each other. Since both used un-advertised IP addresses, this seems impossible. The solution is to setup a route path between them so that the routers between them will forward packets destined for each of the two hosts. The operator of host A must contact the operator of host B through some other means of communication. The operator of host A need only acquire the, advertised, IP address of host B's gateway. Once this is done, host A sends an RNET Route Request specifying the host B's address as the target address and directs this request to the gateway of host B. The result is that all the routers in between host A and host B will have setup an RNET Route entry for host A as the RNET Host and with host B as the Target Host. At this point either host may initiate contact with the other as the routers between them will know where to forward their packet(s). I hope this clears up any confusion or misunderstanding (or lack thereof.) If you have any suggestions or comments, please feel free to email me directly at mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] . Sincerely, Chad Christopher Giffin T-Net Information Systems (a.k.a. typo) ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ISSN for RFC Series under Consideration
On 5/21/08 5:39 PM, Brian E Carpenter [EMAIL PROTECTED] wrote: Possibly not, but there is still a crusty old world of academic publications with traditional reference styles out there, and an ISSN will make it much more straightforward to cite RFCs in peer-reviewed publications. +1 that it's a no-brainer. Hi - I'm really not trying to be a contrarian, just trying to sort through the actual issues here. I don't think I've ever seen a reference that included an ISSN. I've also never seen one used as a subject header (index term) in cataloging. The only time I've personally seen them used is as *descriptive* information in a catalog (library catalog, publisher's catalog, etc.). I'm sure someone will be happy to dig up a counterexample but I do think they're pretty unusual. Really, what are the odds that someone knows the ISSN but not the title or the author or the publisher or ... ? The practical benefit I see here is getting the Library of Congress (and who knows? maybe the British Library, etc.) to catalog the series as a series, but again I'm unclear on the practical benefit, since RFCs are incredibly easy to find *as* RFCs; that is to say, by the information by which the series will be cataloged and classified. I don't see any disadvantage to doing it, it's just that I can't see much advantage, either. I figure we should just go ahead and do it and not have any expectations that the RFCs will be any more accessible, any more searchable, etc. More like a change in status than a change in substance. Melinda ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Random Network Endpoint Technology (RNET)
On 5/21/08 5:49 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: So we have reinvented STUN? This is probably closer to Paul Francis's NUTSS stuff without the cool crankback and especially without resolving the location problem. Melinda ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ISSN for RFC Series under Consideration
The practical benefit I see here is getting the Library of Congress (and who knows? maybe the British Library, etc.) to catalog the series as a series, but again I'm unclear on the practical benefit, since RFCs are incredibly easy to find *as* RFCs; that is to say, by the information by which the series will be cataloged and classified. I used to publish an actual paper magazine with paid subscriptions. (The Journal of C Language Translation, ISSN 1042-7521) The ISSN made it much easier for my subscribers, who were mostly libraries who used subscription agents like Ebsco, to order the magazine, because the ISSN let them find the price and where to send the order. In this regard, it is similar to the ISBN that everyone uses to order books. But, of course, this is all irrelevant for RFCs which are distributed online for free. I don't see any disadvantage to getting an ISSN other than the tiny effort to update the publishing tools to put it in a header line, but I also don't see any benefit. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor More Wiener schnitzel, please, said Tom, revealingly. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ISSN for RFC Series under Consideration
At Wed, 21 May 2008 17:52:55 -0400, Melinda Shore wrote: On 5/21/08 5:39 PM, Brian E Carpenter [EMAIL PROTECTED] wrote: Possibly not, but there is still a crusty old world of academic publications with traditional reference styles out there, and an ISSN will make it much more straightforward to cite RFCs in peer-reviewed publications. +1 that it's a no-brainer. Hi - I'm really not trying to be a contrarian, just trying to sort through the actual issues here. I don't think I've ever seen a reference that included an ISSN. I've also never seen one used as a subject header (index term) in cataloging. The only time I've personally seen them used is as *descriptive* information in a catalog (library catalog, publisher's catalog, etc.). I'm sure someone will be happy to dig up a counterexample but I do think they're pretty unusual. Really, what are the odds that someone knows the ISSN but not the title or the author or the publisher or ... ? I agree with Melinda here. I can't remember ever seeing anything like an ISBN or an ISSN used as a citation in an academic paper. -Ekr ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ISSN for RFC Series under Consideration
So? The rules of academic citation are broken. Take a look at their idiotic criteria for citing web pages. Unfortunately the folk who designed the reference manager for office 2008 made the mistake of taking them seriously. It is not possible to cite urls for articles as a result. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Eric Rescorla [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 21, 2008 04:06 PM Pacific Standard Time To: Melinda Shore Cc: Working Group Chairs; IAB; IETF Discussion; Julian Reschke; IAOC; RFC Editor Subject:Re: ISSN for RFC Series under Consideration At Wed, 21 May 2008 17:52:55 -0400, Melinda Shore wrote: On 5/21/08 5:39 PM, Brian E Carpenter [EMAIL PROTECTED] wrote: Possibly not, but there is still a crusty old world of academic publications with traditional reference styles out there, and an ISSN will make it much more straightforward to cite RFCs in peer-reviewed publications. +1 that it's a no-brainer. Hi - I'm really not trying to be a contrarian, just trying to sort through the actual issues here. I don't think I've ever seen a reference that included an ISSN. I've also never seen one used as a subject header (index term) in cataloging. The only time I've personally seen them used is as *descriptive* information in a catalog (library catalog, publisher's catalog, etc.). I'm sure someone will be happy to dig up a counterexample but I do think they're pretty unusual. Really, what are the odds that someone knows the ISSN but not the title or the author or the publisher or ... ? I agree with Melinda here. I can't remember ever seeing anything like an ISBN or an ISSN used as a citation in an academic paper. -Ekr ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ISSN for RFC Series under Consideration
I agree with Melinda here. I can't remember ever seeing anything like an ISBN or an ISSN used as a citation in an academic paper. Correct, but I have seen a wide variety of ways to cite RFCs and tying them all back to an ISSN number would be a step forward IMHO. In any case: at worst, harmless. Brian ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Random Network Endpoint Technology (RNET)
On May 21, 2008, at 4:49 PM, [EMAIL PROTECTED] wrote: So we have reinvented STUN? No, we've moved the state of STUN into each of the routers between the two hosts, and have to hope we don't have a route flap somewhere. It's sort of like RSVP. -- Dean ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sipping-overload-reqs (Requirements for Management of Overload in the Session Initiation Protocol) to Informational RFC
thanks for the comments, Matt. Responses below: Matt Mathis wrote: I reviewed draft-ietf-sipping-overload-reqs-02 at the request of the transport area directors. Note that my area of expertise is TCP, congestion control and bulk data transport. I am not a SIP expert, and have not been following the SIP documents. I have serious concerns about this document because it explicitly excludes the only approach for coping with overload that is guaranteed to be robust under all conditions. Although I know it is considered bad form to describe solutions while debating requirements, I think a sketch of a solution will greatly clarify the discussion of the requirements. The only robust overload signal is the natural implicit signal - silently discarding excess requests. Explicit overload messages (code 503) should be optional, and must have an explicit rate limit. Agree. Our intention for the solution was exactly that; we have an explicit feedback mechanism (like ECN provides) that can be used, in addition to treating lack of any signal as a sign of congestion as well. Sending additional messages to explicitly indicate overload is intrinsically fragile. Agree too. SIP requests normally generate responses, and so the plan is to have a response code which can be used to clearly say I'm overloaded. This is not an additional message - its the normal SIP message that is sent - but with clear meaning. And of course, lack of any response at all needs to be treated as a sign of congestion too. My specific objections to the document are as follows: Requirement 6 calls for explicit overload messages and forbids silently discarding requests, since they are not unambiguous in their meaning. That was not the intent of the requirement. The requirement is meant to say that, any explicit message used to signal overload must be used solely for that purpose, and not to signal other, non-overload related events. I've reworded to say: t hangText=REQ 6:When overload is signaled by means of a specific message, the message must clearly indicate that it is being sent because of overload, as opposed to other, non-overload based failure conditions. This requirement is meant to avoid some of the problems that have arisen from the reuse of the 503 response code for multiple purposes. Of course, overload is also signaled by lack of response to requests. This requirement applies only to explicit overload signals. /t Requirement 15 seems to provide a loophole (allowing complete failures) but seems to forbid using it as the preferred mechanism. Per above, the intention all along was to treat lack of a response as an indication of congestion. The requirement most certainly does not limit itself to complete failures; it calls out overload as the first cause of this problem. Neither does the requirement forbid lack of a response from being the preferred mechanism. The requirement reads: t hangText=REQ 15: In cases where a network element fails, is so overloaded that it cannot process messages, or cannot communicate due to a network failure or network partition, it will not be able to provide explicit indications of its levels of congestion. The mechanism should properly function in these cases. /t I think this is pretty clear and it directly addresses your concern - the solution has to work in cases where there is no response whatsoever. Can you suggest alternate text that would improve here? Requirement 8 does not make sense without explicit notification. Reworded to: t hangText=REQ 8: The mechanism shall ensure that, when a request was not processed successfully due to overload (or failure) of a downstream element, the request will not be retried on another element which is also overloaded or whose status is unknown. This requirement derives from REQ 1. /t which handles both explicit and implicit overload signals. Requirements 7, 8 and 9 should note that they can be (are already?) equivalently satisfied by properly structured exponential retransmission backoff timers in SIP itself. Requirements 8 and 9 deal with sending requests to other elements, besides the one which was overloaded. That case is not handled by the structured exponential backoff timers in SIP, which handle retransmissions of a request within a single transaction to a single server. These requirements are dealing with behavior across different servers and different transactions. Requirement 7 is partly addressed by SIPs retransmit behavior. However, those timers apply independently to each transaction, and in cases of a large number of transactions between a pair of servers, is not sufficient to prevent overload. This requirement is meant to improve on this situation. I would like to point out that TCP, IP and several other transport protocols have evolved in the same direction as I am advocating for SIP: the only robust indication that an error has occurred
Re: Last Call: draft-resnick-2822upd (Internet Message Format) toDraft Standard
Lisa, Could you let us see your summary of the discussion about (not) documenting the X-headers? I haven't seen any further comments since Dave's message below, and it appears that the IESG is ballotting on the document now. Regards Brian On 2008-04-08 06:34, Dave Crocker wrote: Pete Resnick wrote: (1) Partially restore the 822 text, stressing private use, rather than experiental. I don't think we'll be able to do this; see (3) below. ... (3) Encourage X-headers for strictly private use, i.e., they SHOULD NOT be used in any context in which interchange or communication about independent systems is anticipated and therefore SHOULD NOT be registered under 3683. I think this is DOA. There are many folks (myself included) who think this should not be encouraged in any way, shape, or form. Folks, One of the lessons of the community's 30+ years of protocol work is that specification details which are actually usage guidance, rather than concrete interoperability details, often have little impact on a global community. The community formulates its own preferences. When X- as original proposed, I thought it was marvelously clever. I still do. But it doesn't work. While it does protect a privately-developed header field label from being preempted by a standards process, it creates a much more serious problem of moving from private-use to public standards and having to (try to) re-label the field. This is a highly disruptive impact./ In other words, if the model is true that existing practices get standardized -- and in this realm they often are, I think -- then we need to design things to make the transition from private-to-public be comfortable. Defining a private-use naming space runs counter to that goal. Valuable lesson. We should learn it. d/ ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Random Network Endpoint Technology (RNET)
Excerpts from Melinda Shore at 17:55:57 -0400 on Wed 21 May 2008: On 5/21/08 5:49 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: So we have reinvented STUN? This is probably closer to Paul Francis's NUTSS stuff without the cool crankback and especially without resolving the location problem. With NUTSS the destination is (probably) seen in routing from the start, but signaling is required to set up a desirable path. Here the problem is that neither source nor destination is globally routed. I'm concerned about scaling. That's a lot of dynamic state in the core routers, precisely where we don't want it. He's probably better off source-routing. See NIMROD http://ana-3.lcs.mit.edu/~jnc/nimrod/docs.html and remember what it stands for! :-) He should also see the proposals in the Routing Research Group http://www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup swb ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-mayrhofer-geopriv-geo-uri-00
While I cannot comment specifically about RFC style, I can say (from my
study of the use of language globally) that there are several conventions in
use for numerical notation using the numerals 0-9, depending on usage.
- The point/period/full stop may be used to separate whole numbers from
values smaller than 1; alternatively, the comma may be.
- Then comes the possible issue of separation on either side of the decimal,
whether every second, every third, or every fourth place.
- If the decimal point is used, to use your terminology, then one may find a
space or a comma as a separator on either or both sides of the decimal.
- If the decimal comma is used, then one may find a space or point as a
separator on either or both sides of the decimal.
By the way, the word is jarring, not jaring, according to laws governing
regular English spelling conventions worldwide. Jaring implies a verb jare,
the way I understand the use of English, regardless of location.
/Kim.
- Original Message -
From: Bill McQuillan [EMAIL PROTECTED]
To: IETF Discussion ietf@ietf.org
Cc: Christian Spanring [EMAIL PROTECTED]
Sent: Wednesday, May 21, 2008 11:32 AM
Subject: draft-mayrhofer-geopriv-geo-uri-00
While reading through this ID: A Uniform Resource Identifier for
Geographic
Locations ('geo' URI), I found several minor issues.
Section 2. Introduction
[use of WGS84 reference system]
I wonder if it might be more forward thinking to allow for the optional
specification of the reference system being used. Perhaps this could be
one
of the URI parameters mentioned in section 4.7
Section 4.4.1 Component Description
The number of decimal places indicates the precision of the value.
One degree equals 111.319,45m at the equator (40.075,004km / 360
degree). Five decimal places (0.1 degree) seem to imply a for
civil use sufficient accuracy.
To my American eye the decimal notation (partially) used here was jaring.
Searching (briefly) for some sort of presentation standard in an RFC or
other technical document was unsuccessful. Is the use of . and ,
standardized in the representation of real numbers in RFCs?
Section 6. GML Mappings
There seems to be no explanation of what GML is, not even a Reference
document.
Section 9.1. Invalid Locations
Is there a recommended way to represent the poles? Dare I suggest geo:90
and geo:-90? If that is too much of a special case, should the longitude
always be zero or can it be anything between -180.0 and 180.0?
Section 9.2. Location Privcay
Typo: .Privacy
--
Bill McQuillan [EMAIL PROTECTED]
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
72nd IETF - Hotel Reservations
72nd IETF Meeting Dublin, Ireland July 27-August 1, 2008 Host: Alcatel-Lucent Registration numbers for Dublin are currently exceeding Paris! Be sure to make your hotel reservation, there are a limited number of rooms at the Citywest Hotel. More information on the hotel and how to make your reservation can be found at: http://www.ietf.org/meetings/72/72-hotels.html Only 66 days until the Dublin IETF! Online registration for the IETF meeting is at: http://www.ietf.org/meetings/72/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
