RE: AW: [Enum] enumservices in new version of 2916bis

[Richard Shockey <[e-mail]>]

>
>
>If used in this order, I have to admit, that I cannot reject this
>proposal, because it is in principle the combination of the "3.1 Simple
>URI Scheme" and "3.2 Combined URI Schemes and Services" from my
>draft-stastny-enum-services-analysis-00.txt
>
>The difference is that I proposed to use +telvoice, +telfax, +sipvoice,
>etc., but this is obviously the same as +tel:voice, +tel:fax,
>+sip:voice.
>
>I only have the following requirements for the definition of
>"E2U+URI:svc+addinfo":

Speaking for myself I don't see a problem with this and that could be added 
to the EBNF syntax proposed by Bob


    enum-service : "E2U" ( "+" URI/protocol [ ":" service] )+
    URI/protocol  [mandatory]   : | "tel"  |"mailto" | "H323"  | "sip"  | other
    service   [optional]   : "voice" | "video" | "email" | "im" |  "sms" |other
    info        [optional]      : <TOKEN>

In a private note Mike Mealling remarked to me his definition of terms:

"IMHO, a service is an action that can be expressed via multiple protocols.
A protocol is profile of some set of semantics and an on the wire
protocol that is used to accomplish the task expressed by the service...

A protocol is seperate from a URI scheme because URI identify endpoints
and many protocols can handle multiple URI schemes..."

What I'm trying to resolve here is the definition of terms .........




>1. The "svc" SHALL be the same as defined with the URI Scheme used, and
>SHALL be defined with the URI Scheme. Only defined svc shall be used.
>The idea behind this is that it shall be possible (and shall be the same
>for the application-SW) to use a URI equivalent to the one used in the
>NAPTR also stand-alone on a webpage.
>
>2. An "svc" SHALL be defined (used) consistently over all URI Schemes,
>if used in more than one URI Scheme. So e.g. svc=voice has the same
>meaning in tel:, sip:, etc.

can we just call it "service" ?  its verbose and easily understandable


>3. A NAPTR containing "E2U+tel:voice+tel:fax"
>"...tel:+431xxx;svc=voice,fax!" is equivalent to
>"E2U+tel:voice+tel:fax" "...tel:+431...!" or should two NAPTRs be used
>in that case?

Ok now I'm getting confused again... I'm assuming that if you are assuming 
a T.30 capable fax terminal device that is PSTN addressable that 
"E2U+tel:fax" IMHO is sufficient with a tel URL.


>4. Only the URI Scheme is mandatory, but only if there is a "u" flag, to
>keep Lawrence happy;-)
>
>5. There is a definition necessary, what it means, if only the URI
>scheme is used:
>A. Define a default (e.g. mailto defaults to email) (BTW: is vmail
>defined?)

It will be .... I'm very wary of defining things like this at this time 
since I'm assuming the VPIM WG will want to address those issues separately 
in their own drafts.

I've personally briefed both the VPIM and FAX WG on the progress of the 
ENUM WG at several IETF meetings and I'm assuming they will use our 
guidance to construct appropriate ENUM service fields for their respective 
protocols.

>B. void svc means either "all", "any" or "negotiate" (or is "neg" an svc
>on ist own?)
>
>The "all" now leads to the question how to deal with the categories
>proposed in draft-brandner-enum-categorical-enumservices-00.txt?
>
>"all" may come in handy with the enum: URI and also others, for a
>detailed discussion see section 7.1 of the above mentioned draft.
>
>The other categories may go to the "+addinfo", provided at courtesy of
>the ENUM End User. So he may provide additional info, e.g. this is the
>preferred NAPTR for talk, msg, etc, but also "home", "office", "mobile",
>etc may be convinient.

I think its best all around if we look at this info field as being 
ambiguous .. your examples make my nervous since it defines a lot more 
information than I think some folks want to disclose in the DNS as you 
correctly point out .  If we start to suggest things like this in 2916bis 
the assumption will be made that its "official" and that will trigger some 
serious misconceptions on the part of the privacy community.

I don't dbout there may be users that want to do this ..its just that we 
will have to be very careful in the language to point out that uses like 
this are purely optional at the discretion of the End User.


>An open issue is categories like presence, location, certificate, etc.
>If we use it together with the URI Scheme as "svc" (e.g. ldap:cert),
>they need to be defined in the URI Scheme.

Sure ..but the ENUM WG itself may not be the appropriate WG to create those 
drafts. I think we need to have a bit more outreach to other communities of 
interest here.


>My proposal here is to agree on the principal format as stated above, of
>course correctly defined and to include this in RFC2916bis. This
>together with a rough consensus could also serve as a basis for the
>format used at the trials (we will start with the simple and obvious
>URIs and services anyway).

Yes and I think we know what those are the question is what is the document 
instrument we use to define those initial trial fields.  We have a process 
issue to deal with ... first we need to see 2916bis and the IANA 
registration procedures associated with it.


>The details could be worked out in a separate draft (e.g. along the
>lines of my draft-stastny-enum-services-analysis), also resolving the
>above mentioned open issues on the list between Yokohama and Atlanta.
>There could also be some first feedback from the trials.

I think this is a very very good idea. A specific ID on a limited series of 
enumservice constructs for the purposes of global trials. ..we can create a 
simple matrix with verbose explanations along the lines of your 
"Catagoricial enumservices" document and Bob Walters syntax.

enum-service : "E2U" ( "+" URI/protocol [ ":" service] )+
    URI/protocol  [mandatory]   : | "tel"  |"mailto" | "H323"  | "sip"  | other
    service   [optional]   : "voice" | "video" | "email" | "im" |  "sms" |other
    info        [optional]      : <TOKEN>

The purpose of the document would be to explain the current state of ENUM 
development perhaps highlight the agreement made with SG2 etc and note that 
several nation-states have committed to developing trials etc. This new ID 
is offered to "facilitate" these trials under way blah blah etc.

Now in addition, putting my WG chair hat on, I think it would be a good 
idea for both you , Rudolf, and Larry to collaborate with Bob Walter and 
Doug Ranalli on this.

Bob and Doug have put a lot of thought into this and their original draft 
suggested many of the concepts here so it only seems reasonable to combine 
efforts.

You all could have something ready shortly after Yokohama and put it on 
track to "Experimental" in conjunction with 2916bis itself.

Is this a plan?



>Best regards
>
>Richard STASTNY
>OeFEG/Telekom Austria
>Box 147, A-1103 Vienna, Austria
>tel:[phone]
>fax:[phone]
>mailto:[e-mail]


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: [phone]
<mailto: [e-mail]> or
<mailto: [e-mail]>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/enum