Hi,
We are working on SNMP Agent implementation. We have a query regarding
the encoding of Octet string within a response PDU whether the Octet
string should be encoded as ascii or as hex & what should be the size of
the variable binding within the PDU?
If a MIB object is defined as of
encoding
>
> Hi,
>
> We are working on SNMP Agent implementation. We have a query regarding
> the encoding of Octet string within a response PDU whether the Octet
> string should be encoded as ascii or as hex & what should be the size of
> the variable binding withi
t;> From: Puja Singh[SMTP:[EMAIL PROTECTED]]
>> Sent: Friday, April 13, 2001 3:55 PM
>> To: [EMAIL PROTECTED]
>> Cc: [EMAIL PROTECTED]; Shivendra Kumar; Abhishek Bagchi; Puja
>> Singh
>> Subject: Octet string encoding
>>
>> Hi
ed ), then it is
> | copied directly
>
> Do you mean "is allowed in the given part of the URI" here?
> What I have in mind are, e.g., %x5B and %x5D in a query or
> fragment. By definition in 2.1 these are "literals", but
> have to be percent-encoded n STD
a prefixed length
"text" field in the RDATA but do set the string
the URI is to the full length of the RDATA, i.e.
without any 255 byte limitation.
4. DNS is by design (as pointed out in RFC 5507)
created with a tuple consisting of owner, type
and class for selection by the c
ferenced.
How do I know whether the default applies or not? The URI doesn't tell
you. Deducing from context is a bad idea.
Section 3: "Thus to ensure interoperability, implementations SHOULD NOT
generate URIs that employ URI character escaping": This is wrong and
needs to be fix
lds. For instance the domain name “company.com.ki” could be mapped to “dc=company,dc=com,dc=ki”.So if each certificate contains in its subject this string, then it is easy to query the right entry in the DNS infrastructure. In reverse each DNS must be able to point to a PKI repositery. This is done
>which defaults to the object bytes that are expected to be returned
>when the URI is dereferenced.
> How do I know whether the default applies or not? The URI doesn't tell
> you. Deducing from context is a bad idea.
I agree that deducing the input from context alone could
in
>> RFC 4408 that collisions as described in RFC 5507 might happen.
>>
>> 3. It is also pointed out that there might be size issues with the records,
>> and experience from use of NAPTR show that selecting a preferred mechanism
>> that potentially blows the size
the URI.
{ I might have the "meaning" phrasing wrong. }
As the Abstract of [RFC2915] says, "This allows the DNS to be used to
lookup services for a wide variety of resource names (including URIs)
which are not in domain name syntax." Any sort of hierarchical
nlight-05
>>
>> substantive comments (in somewhat arbitrary order)
>> --
>>
[ I demoted the comments wrt "JSON object" terminology and put them down at the
end of this msg ]
>> Also, the syntax for GETS isn't fully specified. Are th
ro, then it is ASCII and needs
case-independent comparison". It seems to me that a statement
of that general nature would be needed to justify your assertion
above. I note with interest that even 2181 doesn't seem to
include such a statement as a clarification of what is an "ascii
la
ry order)
>>> --
>>>
>
> [ I demoted the comments wrt "JSON object" terminology and put them down at
> the end of this msg ]
>
>
>>> Also, the syntax for GETS isn't fully specified. Are the
(without the quotes).
We hope interested parties will participate in the discussion on this list
to establish a more formal version of this protocol.
Welcome!
Johan Hjelm
Chair, CC/PP working group, W3C
(apologies for multiple postings!)
For more information:
CC/PP Exchange Protoco
14 matches
Mail list logo
