Re: [Ecrit] Service URN IANA Policy & the Geocoding ID

["James M. Polk" <[e-mail]>]

At 01:31 AM 10/2/2009, Hannes Tschofenig wrote:
>Hi James,
>
> >Chairs
> >
> >With respect to
> >http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-geoco
> >ding-00.txt
> >and forte's draft, I assume they keep -ecrit- in their
> >filename, and are individually submitted to the RFC-Editor
> >when the author feels they are ready?
>
>Andrea has worked on a few documents, namely:
>http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy
>http://tools.ietf.org/html/draft-forte-ecrit-service-classification
>http://tools.ietf.org/html/draft-forte-ecrit-lost-extensions
>
>So, which one do you mean?

I meant each of them (I think)


>Regarding your document draft-polk-ecrit-lost-geocoding-00.txt
>
> From what I could hear at the last IETF meeting (via my remote
>participation) a couple of folks had suggestions regarding your document and
>they roughly proposed the following approach:
>
>* Define a protocol for geocoding (not based on LoST)
>* Define a discovery mechanism (based on LoST) for discovering the server
>that does the geocoding

There were these two suggestions, but there were others as well - 
notably from Andy, who said we need to be conscious of the user 
experience in making this solution have to have more round-trips (or 
contact more servers) than is necessary - when the information might 
(I'd argue probably) be in/at the first server contacted (i.e., the 
first LoST server) -- which is where the initial -00 was thinking.

My next rev plans on addressing what Andy offered.

Additionally, when looking at the two bullets above, if one looks at 
them in a reverse order to which they are currently in, that makes 
for a two-step solution.  That's fair, but why do a solution in two 
steps when one can accomplish this in one step?  I believe the best 
solution is to do both what you suggested and what I'm suggesting above.

In other words, use LoST to ask for geocoding. If that server knows 
the answer, it gives it; if it doesn't know the answer, but knows a 
server that can solve the geocoding query, it gives the URI of that 
server (which is more like what LoST is defined to do now).

Also, there was a suggestion by Brian that wanted me to move the 
geocoding URN underneath a new top level URN called 
"transformation".  I've been thinking about this, feeling it probably 
is a good idea, though I haven't spent enough time on this rev to 
figure out exactly how I'm going to write it in.


>Regarding the overall approach of working on non-emergency services I have
>not spoken to Cullen/Robert about this particular document. I plan to post a
>separate mail about our very recent chat with them.

look forward to that update!


> >
> >I don't mean this to be nefarious sounding, as I plan on
> >working within the WG until this doc has consensus of at least
> >those that care about it (knowing that because this isn't
> >going to be a WG item, the whole WG doesn't necessarily need
> >to have reached consensus.
> >
> >Is this the general plan of action for these types of IDs?
> >
> >Of should each of these IDs have -ecrit- removed from the
> >filenames because there is no hope of them ever being WG items now?
> >
> >Looking for clarification and guidance
>
>Thanks for raising this issue.

np -- always here to help

;-)

James


>Ciao
>Hannes
>
> >
> >James
> >
> >At 08:36 AM 9/30/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> >>Hi all,
> >>
> >>we discussed the need to change the IANA allocation policy for the
> >>definition of new top-level services within this working group a few
> >>times. With the
> >>http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy-00
> >>proposal Henning and Andrea have describe the modification. We would
> >>change the allocation policy of top-level services from "Standards
> >>Action" to "Expert Review".
> >>
> >>The policy for assigning labels to sub-services is left unchanged and
> >>may differ for each top-level service designation and must be defined
> >>by the document describing the top-level service. For the Service URN
> >>RFC (RFC 5031) two sub-services are defined, namely 'sos' and
> >'counseling'.
> >>The policy for adding sub-services to the 'sos' and the 'counseling'
> >>services, as defined in RFC 5031, is "Expert Review".
> >>
> >>In order to progress draft-forte-ecrit-service-urn-policy-00 we would
> >>like to know whether someone has problems with this allocation policy
> >>change.
> >>
> >>Ciao
> >>Hannes & Marc
> >>_______________________________________________
> >>Ecrit mailing list
> >>[e-mail]
> >>https://www.ietf.org/mailman/listinfo/ecrit
> >
> >_______________________________________________
> >Ecrit mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/ecrit
> >