Subject: RE: [Enum] enumservice names

From: "Stastny, Richard" <[email-masked]>
Date: Thu, 23 May 2002 17:21:20 +0200

> -----Original Message-----
> From: Clive D.W. Feather [mailto:[email-masked]] 
> Sent: Thursday, May 23, 2002 5:10 PM
> To: Stastny, Richard
> Cc: 'Patrik Fältström'; Michael Mealling; Lawrence Conroy; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Enum] enumservice names
> 
> 
> Stastny, Richard said:
> > So we may need something like "E2U-enumservice+scheme?svc"
> > 
> > E.g:
> > E2U-message+tel?sms
> 
> By which time I've duplicated half of the NAPTR record. And what if I
> *don't* duplicate it accurately ? Which wins ? Far better to 
> parse the NAPTR record for these fields.
> 
> Come on: this is basic software engineering. Don't duplicate 
> data without good reason.
> 

Fully agree!
That was originally my understanding.
I also have not seen any feasable use of the regexp, so in most cases it
will be "Throw away and replace by" anyway.

Please lets keep it simple (at least for the trials).

Regards
Richard

 -- 
> Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:  +44 
> 20 8371 1138
> Internet Expert     | Home:  <[email-masked]>  | Fax:  +44 
> 870 051 9937
> Demon Internet      | WWW: http://www.davros.org | Mobile: 
> +44 7973 377646
> Thus plc            |                            | NOTE: fax 
> number change
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
> 

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

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Thu, 23 May 2002 14:39:41 -0600

Patrik wrote:

> This is _exactly_ why I suggested separate documents which 
> specify each one of the enumservices. In those documents 
> it can be written exactly what the client can expect given
> a specific enumservicefield. Regardless of if it is
> "sip" or "voice".

And I support this decision 100% because it makes the most sense. My *only* worry is that the overall enumservice schema is still sufficiently cloudy that we will end up with both 'voice' and 'sipgipstotexttranscoding' enumservices in the same schema. Perhaps a strawman of what the 10-12 enumservices might be would help immensely to that end.

--Andy

---

From: Richard Shockey <[email-masked]>
Date: Thu, 23 May 2002 17:11:29 -0400

At 02:39 PM 5/23/2002 -0600, Zmolek, Andrew (Andrew) wrote:
>And I support this decision 100% because it makes the most sense. My 
>*only* worry is that the overall enumservice schema is still sufficiently 
>cloudy that we will end up with both 'voice' and 
>'sipgipstotexttranscoding' enumservices in the same schema. Perhaps a 
>strawman of what the 10-12 enumservices might be would help immensely to 
>that end.

and I totally concur ... Patrik will be writing the rules in 2916bis for 
the appropriate documentation that constitute a request for a IANA 
registration which will include what we had noted before.

 > It could be foofoo for all it matters so long as  the applicability
 > statement in requesting the appropriate enumservice registration defines
 > 1. the reason for the registration 2. defines the service 3. the URI
 > scheme 4. anticipated context/behavior that the C/UA needs to understand.
5. Appropriate security considerations section

but rather than 10 -12 maybe 5-6 to start with ...
well I can almost see

E2U+protocol+service as a general syntax ...but only in very very specific 
cases such as SMTP where E2U+SMPT+FAX might seem reasonable.

but I continue to submit that in the case of SIP it looks like   E2U+SIP .. 
and that is it.

In the sprit of a tired old scratchy broken record, I continue to insist 
there are real dangers in exposing too much information in the global DNS 
..especially when it is clearly linked to personal communications 
capabilities and preferences.

I continue to submit we should take a very minimalist approach to this and 
that the justification for exposing the capability of an enumservice 
endpoint should meet a very stringent test of applicability.

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: +1 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<